![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 115 | ← | Archive 118 | Archive 119 | Archive 120 | Archive 121 | Archive 122 | → | Archive 125 |
Somebody kindly brought my attention to Wikipedia:Manual_of_Style_(dates_and_numbers)#Conventions that says:
I propose deleting this guideline. I suspect the motivation for the guideline is that it resolves a potential ambiguity when the reader could mistake each value. For example, a glass door might be 8 millimetres thick, 2 metres high and 1 metre wide. Therefore it needs to be presented as "8 mm x 2 m x 1 m". However, I would like to be able to describe a painting as having dimensions of:
This seems to me to be perfectly reasonable but the guideline would require.
It is unlikely that the height of a painting will be 100 times the width. But if it were, any reasonable editor would add the unit labels without needing to be told i.e. "4 cm x 4 m". The guideline requires an additional eight characters (four metric, four non-metric) for two dimensional applications and sixteen characters for three dimensional applications. It adds no value but adds a burden. I propose that it is simply deleted. Does anyone support the proposal? Lightmouse ( talk) 11:31, 27 January 2009 (UTC)
70 × 90 cm can be interpreted as seventy times 90 cm, e.g. something composed by 70 pieces, each 90 cm wide and of unspecified height, placed side-by-side. -- Army1987 – Deeds, not words. 12:09, 27 January 2009 (UTC)
Milkbreath said "you yourself display so little proficiency in matters typographical". I am always seeking to improve but sweeping criticism isn't something that I can work with. Can you provide an example of a typographical error that I made? Lightmouse ( talk) 12:51, 27 January 2009 (UTC)
I was uneasy about the insistence on the repetition from the start. The guideline should be changed to allow what is almost always an unnecessary repetition to be dropped. Tony (talk) 14:01, 27 January 2009 (UTC)
Problem: "70 × 90 cm" could be mistaken for 6300 cm, whereas in fact it's 6300 cm2. In some contexts that is crucial. Michael Hardy ( talk) 20:20, 27 January 2009 (UTC)
This would be a perfect example for giving advice: When giving the dimensions of an object, "70 × 90 cm" is more natural and idiomatic; in some contexts, however, it may be ambiguous, in which case use "70 cm × 90 cm". This is what rational editors would do if we were silent; can we either say something like this, or leave the point alone?
If we can agree, we can use {{ editprotected}}. Septentrionalis PMAnderson 01:15, 28 January 2009 (UTC)
If you want to ban this popular format, you have to tell us that you think it is confusing in real articles. Please look at Mona Lisa and tell us if you think you are confused by how it describes its dimensions. Seriously. Lightmouse ( talk) 11:58, 28 January 2009 (UTC)
Question: Is it actually true that "70 × 90 cm" is "idiomatic" as has been claimed above? Is it common in publications? In my anecdotal experience, while "70 cm × 90 cm" and "70-by-90" (with no units) are common in everyday speech, "70 × 90 cm" is not. Shreevatsa ( talk) 17:19, 28 January 2009 (UTC)
I've often come across several IPs ( here, here, here, and several more) that change regular date format to something like this. These IPs (probably all the same person) continually make these edits and often go on unreverted. I usually make it my job to go and revert all the edits the IP makes. These IPs have been repeated been warned, explained to, blocked, and sometimes, just get away with it. It's become real tiresome to continually revert these edits and I don't know how to deal with it. Thought their edits are easily detected (they use the name of the article as the edit summary), they often go by for minutes to hours without the edits being reverted, and I can only do so much with limited time. I really can't think of a possible solution, considering the range of these IPs and I can't fix it all alone. So basically, what I'm asking, is there any possibles solutions do this, or will other editors and I have to just revert each edit? Diverse Mentality 07:08, 3 February 2009 (UTC)
Maybe reverting is the wrong answer. Some of the edits that they have done have substituted a date for a year. If the date is correct, and can be verified, then substituting a date is good. It is a pity they use an ambiguous mm-dd-yyyy format, since some readers will think it is dd-mm-yyyy. The best thing to do is to convert to a normal dd mmmmmm yyyy format, and to add {fact} by it, to indicate that no source is quoted. Simply reverting is unhelpful when the user has added information.
Some of the edits have delinked dates - a bit like Lightbot - only they have used a mm-dd-yyyy format. The best thing to do is not to revert but to change to the normal dd mmmmmm yyyy format.
I am sure whoever is doing this means no harm. They should not be treated as a vandal. If you are an unregistered user of wikipedia (or a registered one using a computer where it would be inappropriate to log in) it is really annoying and unhelpful if someone treats you as a vandal just because you change content that is wrong.-- Toddy1 ( talk) 08:42, 3 February 2009 (UTC)
Toddy, I'm sure the user(s) mean no harm, but the fact that the IPs, such as the first one I linked (among others), have been directed to WP:DATE several times and have ignored these warnings, they continue to make such edits. Their edits start to become disruptive. Diverse Mentality 20:27, 3 February 2009 (UTC)
Regarding this page: 17 Kids and Counting, the tags to show birth date and age in the chart for the children keeps getting removed by anonymous IP editors. The few explanations given for the removals are that we don't know the ages of the children (which makes zero sense considering we know their exact birth dates) and that figuring out the age is basic math (despite the fact that this tag was created for the sole purpose of identifying the age, simple math or not).
I was iffy on whether to include the tagged dates when I merged the articles, but decided to since all the birth dates are known and I don't see any reason why the ages should not be included, if the birthday is included (especially given the subject matter). The second time the tags were removed, it was identified as vandalism by another long-time, established user, which prompted me to continue reverting the changes...but now I'm not so sure since it keeps getting changed by IPs (yet explanations are no longer being offered in the edit summaries and no one changing it is bothering to discuss this on the talk page). Are the tags appropriate in this case? Should they be removed? I don't care either way, but it's getting a bit ridiculous. Can someone give me some help here? Thanks. -- 13 2 18:29, 3 February 2009 (UTC)
Over at Krupp Diamond the text was changed from:
to
on the grounds that the metric units make things less legible. I re-added them but I don't want to get into a revert war with what appears to be a genuine concern by an editor that may be more familiar with 'carats' than I am. Can people take a look and see if metric units cause any legibility problems in that article? Lightmouse ( talk) 11:48, 8 February 2009 (UTC)
All we’re doing in these examples is following current literature (FCL), which varies from discipline to discipline. If a record-setting diamond like the Hope Diamond is particularly notable because it’s so damn big, it would be rather nice to know how many grams it is and to state as much right in the article without requiring readers click on a link and do some math. But for regular, pedestrian purposes, a 0.5-carat diamond is a 0.5-carat diamond and there is simply no point to cluttering up Wikipedia with conversions to units of measure that are unused in the discipline—even if its the splendorific SI by the French. It’s not like we’re preparing to get earth ready to join the United Federation of Planets. Also, we are really and truly not “heading down some path” or “opening the door” to any practices to rid Wikipedia of the SI when we do this; we are simply embracing Follow Current Literature, which best prepares our readership to be conversant in the art and best readies them for their continuing studies elsewhere. Also…
This is, after all, an electronic encyclopedia; let’s exploit the true power of links. For pedestrian purposes, all we need is a first-time link to carat, which explains that a carat is 200 mg. Or, at most, a one-time conversion or explanation right in a given article that one carat is 200 milligrams will certainly do no harm.
And no, an 81 mg diamond or a 200 mg diamond is not the same weight as an 81 or 200 mg medicine tablet. All tablets have “excipients” (non-active tableting ingredients) like microcrystalline cellulose as a binding agent, and flow agents and other excipients. These inactive additives contribute significantly to the mass of tablets. I know, since I’ve formulated tableting formulas before. I went through 32 iterations on my last effort until I had one that had all the right properties, which is now called “Formula #33.” Greg L ( talk) 05:28, 10 February 2009 (UTC)
I agree with Gerry. The world of oil might think in terms of the 42-US-gallon barrel but I don't, nor do I have any burning need to be prepared to be conversant in the art nor readied for continuing studies. They've got their wacky units and they can keep them, let me read an article without having to multiply every number I run across by 0.2. JIMp talk· cont 07:34, 10 February 2009 (UTC)
If you have any unit used fifteen time in one sentence, you probably should do a rewrite. Clutter for one is useful information for another. JIMp talk· cont 20:55, 10 February 2009 (UTC)
I am sorry if I asked the question in the wrong place. Lightmouse ( talk) 09:07, 11 February 2009 (UTC)
Thanks. There is also a debate going on at Template_talk:Convert#Excessive_use_of_double_output about whether carat conversion should continue to be unusual. Lightmouse ( talk) 11:55, 11 February 2009 (UTC)
{{
editprotected}}
Will some admin please make two, uncontroversial updates to MOSNUM, as outlined above at
Val is now fixed?
Greg L (
talk) 05:34, 10 February 2009 (UTC)
I don't see this addressed in the style: commas after dates. In standard written English, this sentence has the comma after the year: "His popularity fell after his arrest on June 12, 1987, became known." Many Wikipedia pages render this incorrectly, leaving out the comma after the year. Should this standard rule be included in the manual on dates and numbers? Is this addressed by any of the bots that fix dates? BlackberryHacks ( talk) —Preceding undated comment was added at 22:00, 10 February 2009 (UTC).
The comma following the year is required because the year is parenthetical. It's required for the same reason that a comma is required in the sentence: I believe that Jack Smith, my brother, is a good man. It's just a different way of writing: His popularity fell after his arrest on June 12 (in the year 1987) became known. By the same reasoning, the year should actually be made parenthetical even when using DMY format, although I've not seen any style guides that recommend that. -- UC_Bill ( talk) 16:35, 12 February 2009 (UTC)
It would solve the problems of {{
val}} with numbers with many digits, although users would have to specify breaks by hand. For example {{User:A. di M./margins|−2.002|319|304|3622(15)}}
would yield −2.0023193043622(15).
It could also have other uses, too. See more examples on User:A. di M.#Testing /margins. The template itself is at User:A. di M./margins. I've put it in my userspace rather than in the template space because I'm not sure about how to name it.
(I haven't included support for automatic handling of exponential notation, uncertainty, etc. yet, but I might add it later. As for the margin size, I've used 0.25em for consistency with what {{ val}} does, but personally I would use smaller margins, e.g. 0.2em.) -- A. di M. ( talk) 11:02, 5 February 2009 (UTC)
As for the em-width, it is a tradeoff; different editors see different widths on their hardware/software platforms.
Are you going to be doing the scientific notation aspect too? Greg L ( talk) 23:22, 6 February 2009 (UTC)
Now that I’ve done my prima dona-bashing on developers, one of them, Robert Rohde, fixed some behind-the-scenes math business that {val} relies upon so it no longer suffers from its seemingly random rounding errors. In other words: {val} now works!
By “fixed”, I mean that {val} now is perfectly predictable. And, though predictable, {val} is not perfect. According to Robert, {val} is good only up to 10 significant digits. I haven’t done elaborate experiments, but I see that it can do twelve-digit tasks like this:
Note that {{ val}} will not work with values that end with a zero (which can happen when uncertainty is expressed), and may not properly work beyond about 10 to 12 significant digits.
{{ val}} is meant to be used to automatically handle all of this. Note that {{val}} can not handle digits with more than about 10 to 12 significant digits and can not properly display signficands that end with a zero. Thus, if you have a value that should display like 1.452800(25) × 10−23, {{val}} will generate 1.452800(25)×10−23.
I don't know what is the optimal solution, but, depending on your screen, resolution, text size and sidebars, you may see the line that includes the dozen significant digits and breaks go over the right end of your screen. (I use the "mini-browser" sidebar in Netscape Navigator 9.0.0.6 for my Watchlist.) It's possible that the "nowrap" required by the example means that this problem isn't fixable, but perhaps some administrator (since the page is fully protected) could insert an appropriate break, unwrap or blockquote to keep the text within the margins. Thanks. —— Shakescene ( talk) 01:06, 11 February 2009 (UTC)
?action=purge
as a suffix to the end of the URL and hit [enter]. This occurs when the server that fed the request has math settings that can only handle up to 12 digits. If you purge/refresh and the error flags go away, then your request was served by a 14-digit-capable server. Eventually, as they replace old servers in Wikipedia’s server farm, the percentage of time that this happens will go to zero (a matter of weeks). Then, only the 15-digit numbers on the page should produce error flags.If you want to speed up the purge iteration time, you can try using Val microsandbox Greg L ( talk) 03:36, 18 February 2009 (UTC)
Readers of this thread may be interested in examining the documentation for {{ start-date}}. This is an example of a date-time template that imposes fewer restrictions described by opposing camps in previous date formatting debates. It addresses the numerical accuracy interests such as those of the microformat / metadata camp interested in accurate ISO8601 dates, and those interested in readability, imposing far fewer restrictions concerning formating or using templates such as for Julian dates precisely. Examples:
Start-date & End-date usage (colors for emphasis only): |
Sample below displays 7 December 1941, and microformat date: 1941-12-07TZ
|
Sample below demonstrating how days, timezones and hours, minutes and seconds can be shown. (Order often not important). Displays 5:43PM HST, December 7, 1941, and microformat date (corrected for UTC): 1941-12-08T03:43Z
|
Sample below demonstrating use of links with dates. Displays links to day of month and year pages.
December 7,
1941, and microformat date: 1941-12-07Z
|
Sample below demonstrating use of Julian calendar dates. Displays 9 June [
O.S. 30 May] 1672, and microformat date: 1692-06-09Z
|
I have proposed that the old way of specifying dates in wonky error prone forms be deprecated. Specifically, this sort of template is completely unnecessary: Eg:{{Start date|1941|12|7|18|Z|df=yes}} might seem to be the correct syntax for the december 7 example above, but the user must do their own conversion to UTC, and they can't format the way they like to. They also may run into bugs. The above example displays as:
I propose that a new family of templates that allow contributors total freedom in formatting dates, using links or templates, which simultaneously allowing the precision folks such at the microformats/ ISO8601 crowd to express dates in their gregorian oriented with the accuracy they desire. This particular template correctly generates ISO8601 date/times between -6999 BC to 6999 AD in natural language and properly handles time zones and date arithmetic in natural forms (eg "february 08, 2009 next sunday" delivers 2009-02-15). Most of the magic is not in the template but an underlying wikitext function, but the point is that in many if not most cases there is no longer any technical need to use wonkey templates requiring separate parameters for year month and days as many have advocated in the past. If anyone is interested in a customized form of this free form template or have ideas for it being even more simplified or able to perform additional functions, please contact me.
Users interested in verifying the ISO values emitted by these examples may see them by turning off CSS in their browsers, (eg: in Opera, use the view Author versus user mode and set one mode to no style sheets). - J JMesserly ( talk) 08:50, 9 February 2009 (UTC)
18:0Z, 7 December 1941
" is not in one of the formats listed on {{
Start date}}'s documentation. "GIGO" applies.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 19:09, 9 February 2009 (UTC)
18:00, 7 December 1941 (-10:00)
. If you have an issue with that, I can only reiterate, once again, that you have been invited to raise them on that template's talk page. You appear to still not have done so.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 13:08, 10 February 2009 (UTC)(undent) The issue I raised here is obvious from your example. The syntax is needlessly unintelligible and complex. I propose that the Manual of style state that human readable templates are preferred to that are less human readable. - J JMesserly ( talk) 17:45, 10 February 2009 (UTC)
{{Convert|one and three-quarter inches|cm}}
work.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 18:42, 10 February 2009 (UTC)
Andy, the
Hudson's Bay Company article contains the {{
Infobox Company}} template, which the proposed bot would act upon. Please explain what the result would be, both in terms of the new parameter, and in terms of the microtext that would be emitted, for the parameter foundation = May 2, 1670
. --
Gerry Ashton (
talk) 20:33, 10 February 2009 (UTC)
foundation = [[Santiago de Cuba]], [[Cuba]] ([[February 4]], [[1862]])
May 2, 1670<span style="display:none"> (<span class="bday dtstart updated">1670-05-02</span>)</span>
George Washington's family bible recorded his birth as the "11th Day of February 1731 / 2". [4] We now state the first President's birth date as February 22, 1732. The old style dates were often expressed as "1731 / 2" because the New Year could be March 25 or January 1. Happy birthday George. -- SWTPC6800 ( talk) 05:39, 11 February 2009 (UTC)
{{Start date|1963|11|22|19|00||-07:00
renders as 19:00, November 22, 1963 (-07:00) and emits 1963-11-22T19:00-07:00
; alternatively {{Start date|1963|11|22|13|00||}}
renders as 13:00, November 22, 1963 and emits 1963-11-22T13:00
. is currently transcluded around 10,000 times, and has been in use - without any significant complaints - since July 2007.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 19:39, 11 February 2009 (UTC)
wikitext | display | microformat | |
---|---|---|---|
old | {{Start date|1963|11|22|19|00||-07:00}} |
19:00, November 22, 1963 (-07:00) | (1963-11-22T19:00-07:00) |
new | {{start-date|November 22, 1963 1pm CST}} |
November 22, 1963 1pm CST | (1963-11-22 T19Z) |
Given the example that even one of the authors of the template {{ start date}} forgot how to use it (see above example on date of JFK death) due to its obscure rules, I propose that there be an indefinite moratorium on any future bot runs converting articles from use of intelligible dates to the far less human readable form that {{ start date}} uses. Unnecessarily complex encodings present obstacles to contributors to Wikipedia. As shown, they can present obstacles even to those who are expert in their use. 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. - J JMesserly ( talk) 15:39, 12 February 2009 (UTC)
You oppose the moratorium? The argument at BOTREQ was that the bot run was uncontroversial. Clearly that is not the case. What is your argument in favor of the old {{ start date}}? I think it is fair to represent opinion here that it needlessly complicates wikitext representation of dates. Your response? - J JMesserly ( talk) 23:25, 15 February 2009 (UTC)
(Quote Copied from BOTREQ by J JMesserly)::There is no controversy. Please avoid unnecessary drama. There is no obscurity and the template is not "error prone"; unlike the supposed alternative. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:06, 13 February 2009 (UTC)
{{
editprotected}}
After a couple days of troubleshooting and e-mailing back and forth with the developers, it turns out that {{
val}} has inconsistent results with 13 and 14-digit significands because roughly 20% of Wikipedia’s servers are old ones running Fedora. In a matter of weeks, those outdated servers will all be replaced so all are like the new ones, which are running Ubuntu. Once that happens, {val} will reliably handle 14-digit numbers. In the mean time, it can only properly generate 12-digit numbers 100% of the time.
User:Dragons flight, who is a developer, has volunteered his efforts and done a fabulous job revising the number-crunching engine that {val} uses. Val now requires ten times less processor cycles (overhead) to render numbers than it previously did, and it now handles significands that end with zeros. Thus, values with uncertainty, such as 1.2345678900(32)×10−23 kg properly display without dropping off the (seemingly) non-significant digits.
In the mean time, MOSNUM needs to be updated with the proper advise regarding {val}…
At Decimal points, please replace the last paragraph with this:
At Notations, add this bullet point at the top:
At Uncertainty, replace the last paragraph with this:
I can see that this entire section covering big numbers, decimal points, delimiting, etc., needs to be revised and harmonized. That is for later after MOSNUM is no longer locked down. Though editors will have to hunt for relevant information, at least what they find will be correct.
Greg L (
talk) 01:25, 12 February 2009 (UTC)
{{
editprotected}}
{{
val|0.1234567}}
generates 0.1234567 (with a four-digit group at the end); but due to server-related issues, {{
val}} can reliably handle no more than 12 significant digits. In cases where {{
val}} fails, the template {{
gaps}} can be used, but the position of the gaps has to be specified by hand.P.S. Here at leŭksman: Your donations at work: new servers for Wikipedia, is something that relates to how {val} will one day soon work consistently at 14 digit resolution. Greg L ( talk) 22:04, 12 February 2009 (UTC)
The [percent] symbol is unspaced (71%, not 71 %).
According to the BIPM’s SI Brochure– 5.3.7 Stating values of dimensionless quantities, or quantities of dimension one, the BIPM is clear about the SI writing style with regard to the “%” symbol; it states as follows: “When it [the percent symbol] is used, a space separates the number and the symbol %.” This calls for 75 %, not 75%. However, it customary to not do so.
I agreed with your proposed wording regarding {val} and digit grouping. I think your wording is better by being more accurate without opening up Wikipedia to an unnecessary hodgepodge of number formats.
If you are trying to make a broader point about the purpose of MOSNUM and the extent to which editors should (or must) comply, I don’t feel I can contribute to this tangent. Perhaps this discussion belongs on one (or both) of our talk pages. I think, as a practical matter, MOS and MOSNUM are style guides that must have flexibility on certain points and be more specific and definitive for others. Greg L ( talk) 00:40, 13 February 2009 (UTC)
-- A. di M. ( talk) 10:50, 13 February 2009 (UTC)
I’ve taken the liberty of borrowing heavily from A. di M.’s proposed wording (particularly the “it is customary” language) and added more detailed guidance in several places for the benefit of less experienced editors. The two bullet points below would replace the last bullet point in
Decimal points. It also clarifies a distinguishing point about 12 digits to the right of the decimal point v.s. 12 digits total in the signficand. Per Jimp’s suggestion below, I’ve also revised ‘manual’ delimiting to the use of {{
gaps}}, which I see is now in article-space.
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the
significand. For significands greater than this, editors should delimit high-precision values using the {{
gaps}} template; e.g. {{gaps|1.234|567|890|123|45}}
→ 1.23456789012345.If someone finds a mistake or has some other improvement, please consider the above two paragraphs between the rules as a group-product worksheet to which anyone may contribute. Just leave a short note below stating your edit summary. Greg L ( talk) 01:06, 18 February 2009 (UTC)
In a sentence such as
The latitude of New Zealand, from approximately 34 to 47° S, corresponds closely to that of Italy in the Northern Hemisphere.
should there be any space between the degree and the S for south? MOS:NUM isn't consistent with itself: the section "Non-breaking spaces" uses one in "5° 24′ 21.12″ N" uses one; the 'Quick "how-to"' in "Geographical coordinate doesn't, the output of the templates mentioned there doesn't, the example about Oslo does.
Does that mean that both formats are acceptable? (FWIW, I did use a space in that sentence, [6] as I think it is more legible with the space.)
(BTW, sometimes the double prime ″ sign is replaced by a quotation mark " or by two prime signs ′′. Should that be fixed?)
A. di M. ( talk) 10:11, 15 February 2009 (UTC)
Within the US, the way to symbolize "degree Celsius" is officially decided. The Congress authorized the Secretary of Commerce to interpret the International System of Units (SI), and the Secretary of Commerce recognized the National Institute of Standards and Technology's Special Publication 330 as one of two documents interpreting SI for the US. That publication states
The numerical value always precedes the unit, and a space is always used to separate the unit from the number. Thus the value of the quantity is the product of the number and the unit, the space being regarded as a multiplication sign (just as a space between units implies multiplication). The only exceptions to this rule are for the unit symbols for degree, minute, and second for plane angle, °, ′, and ″, respectively, for which no space is left between the numerical value and the unit symbol.
This rule means that the symbol °C for the degree Celsius is preceded by a space when one expresses values of Celsius temperature t.
I believe the interpretation is the same in other countries, and that it would be reasonable to follow the same style for °F. -- Gerry Ashton ( talk) 20:20, 15 February 2009 (UTC)
There was no edit warring at the time of protection, the only reason given what "Oh noes, what about the vandals!" as if they would not be reverted in less than
5.39124(27)×10−44 s. (turns out there was edit warring ... back in november!) It's been nearly 3 months now. It's ridiculous that we have to ask permission to move a comma around. This is not kindergarten! Let experienced editors freely edit the page by default. If there's actually a problem, then lock the MOSNUM down, but don't lock it down for something silly like fear of vandals. The biggest level of protectiion that this pages warrants by default is edit=autoconfirmed and move=sysop.
Headbomb {
ταλκ
κοντριβς –
WP Physics} 11:25, 15 February 2009 (UTC)
Right now, there are some areas of MOSNUM, such as the entire Section 3 (Numbers), that needs to be harmonized and streamlined so there is less duplication and editors can find information where one would reasonably expect it. I see no need to have complete paralysis here while ArbCom tries to decide if their processes suffer from a serious hiccough, or are galactically dysfunctional.
BTW, some time ago, I saw a post on an admin hangout here on en.Wikipedia from an admin from the Persian (Iranian) Wikipedia. He had problems with editors putting death-to-Israel flags and pictures of SCUD missiles on their user pages. These editors were also editing articles with a strong, POV-pushing, anti-Israel bent. He came to en.Wikipedia for guidance as to what to do. The advise from our admins was along the lines of “WTF? Get some help, here’s the Wikipedia principle you adhere to, and get tough.” It seems to me that circumstances here on en.Wikipedia can sometimes spiral out of control to the point that even admins here question whether they can do anything about it. Greg L ( talk) 01:44, 18 February 2009 (UTC)
Most talk pages have links to all the archive pages in the archivebox. This one currently does not. Apparently there was an effort to keep DA discussions in separate archives? Sometime before Dec 7, >3000 edits ago, someone added the (mislabelled) links "118 (D12)" and "118 (D13)" and since then the archive index is untouched. The missing archive links 113-115, 119, 120 are basically all DA discussions.
So what is the scheme and what can be done to fix it? I can update the index easily enough, but is it also desired to strip out the non-DA threads into a separate archive? Franamax ( talk) 18:17, 16 February 2009 (UTC)
When this sentence occurs mid-paragraph and is the only occurrence in the article of a number which is the proper or preferred style? I can't seem to find a specific mention of this in the MoS. Also, is there an easy way to search the archives of all the MoS talk pages, and ONLY the MoS talk pages? -- OlEnglish ( Talk) 19:19, 16 February 2009 (UTC)
OlEnglish, the link and excerpt given by Gerry Ashton seem to answer your question. You have freedom of numeral! Use tact, poise and reason. And please ignore the sniping from the peanut gallery. These poor unfortunates have nothing better to do :D -- Goodmorningworld ( talk) 01:15, 18 February 2009 (UTC)
It's time to remove the bit about thin spaces. There was a discussion some time ago about the use of these and it was found that they were problematic because they don't render properly on all browsers (including the version of Internet Explorer I'm using right now). Greg's gaps (used by {{ val}} and {{ gaps}}) came to the rescue with the added advantages (or what some, including me, might consider essential features) that they are already non-breaking and vanish on copy & paste (allowing numbers to be directly input into spreadsheets or other calculational applications). JIMp talk· cont 23:37, 17 February 2009 (UTC)
BTW, I completely douched 3⁄4 of this page by accidentally coding {[tl|gaps}} (with a curly bracket followed by a square bracket) in the first paragraph of this post. [7] Man-oh-man, Wikipedia’s server engine doesn’t like that; it simply wouldn’t show the entire last three-quarters of the page, including my post with the goofed-up brackets—not even in edit view. I had to go to a pre-edit, historical page, grab all that pre-goof code, and completely replace the contents here. Maybe {[tl|gaps}} is a fluke, or maybe this is a purposeful code I didn’t know about that is intended to mess with spacetime so you can go back into history and make it so Hitler had never been born. Greg L ( talk) 01:11, 18 February 2009 (UTC)
{{
editprotected}}
The text in question is under
Large numbers and is as follows.
In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. "8,274,527". In scientific context, thin spaces can also be used (but using {{ nowrap}} to prevent line-breaking within numbers), e.g. "8 274 527" (
{{nowrap|8 274 527}}
, or using the thin space character instead of its HTML entity). Consistency within an article is desirable as always.
I'm proposing that the text be changed to the following,
In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. "8,274,527". In scientific and mathematical contexts, {{ gaps}} may be used to insert thin spaces, e.g. use {{
gaps|8|274|527
}} to produce "8274527" (note: the thin space character and its HTML entity, 
, do not render correctly on some browsers). Consistency within an article is desirable as always.
JIMp talk· cont 07:33, 26 February 2009 (UTC)
Paragraph 2 seems to be a valid argument for having at least two English Wikipedia versions. 84.9.125.170 ( talk) 23:09, 22 February 2009 (UTC)
As many of those who keep tabs here know, there has been an ongoing arbitration case on (de)linking chronological items. One of the clerks has started the framework for perhaps the most intricate RfC on the issue yet, which includes date autoformatting and other definitions of said feature. Please see User:Ryan Postlethwaite/Date linking RfC for the draft of the RfC and discuss its scope and questions at its corresponding discussion page. Opinions on the formatting of such an RfC are welcome here. Dabomb87 ( talk) 23:43, 23 February 2009 (UTC)
I don't see this addressed in the style: commas after dates. In standard written English, this sentence has the comma after the year: "His popularity fell after his arrest on June 12, 1987, became known." Many Wikipedia pages render this incorrectly, leaving out the comma after the year. Should this standard rule be included in the manual on dates and numbers? Is this addressed by any of the bots that fix dates? BlackberryHacks ( talk) —Preceding undated comment was added at 22:00, 10 February 2009 (UTC).
The comma following the year is required because the year is parenthetical. It's required for the same reason that a comma is required in the sentence: I believe that Jack Smith, my brother, is a good man. It's just a different way of writing: His popularity fell after his arrest on June 12 (in the year 1987) became known. By the same reasoning, the year should actually be made parenthetical even when using DMY format, although I've not seen any style guides that recommend that. -- UC_Bill ( talk) 16:35, 12 February 2009 (UTC)
I have recently seen the argument put that the line in #Strong national ties to a topic that says
means that WikiProjects are at liberty to adopt a particular format across the board, irrespective of national ties. For example, WikiProject Hats may adopt a convention of using US-style date formatting for all hat articles.
I think this is a misunderstanding of what was intended here. I believe "customary format" means what people customarily do out there in the real world, not what Wikipedia editors in the subject area customarily do. Can I get a clarification on this point, both here and in the guideline text?
Hesperian 04:52, 7 March 2009 (UTC)
{{
editprotected}}
There was a protected edit request in the
archive from 12 February, which I have just deactivated. Is this edit still needed? If so, please could you provide a clear and succinct instruction here, as there was a huge amount of text in that thread.
Martin
msgj 10:18, 25 February 2009 (UTC)
{{nowrap|299 792 458}}
and {{nowrap|149 014 769}}
in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate" in the "Large numbers" section with {{gaps|299|792|458}}
and {{gaps|149|014|769}}
respectively (the instruction was changed but the examples weren't; this one should be uncontroversial). There is a similar example in the last bullet point of the section "Decimal points", but there is no consensus about the precise wording to use (although there is consensus about what it should say). I'd go with replacing that bullet point with{{
val|0.1234567}}
generates 0.1234567 (with a four-digit group at the end); but due to server-related issues, {{
val}} can reliably handle no more than 12 significant digits. In cases where {{
val}} fails, the template {{
gaps}} can be used, but the position of the gaps has to be specified by hand.The above text (between the rules), replaces the last bullet point in WP:MOSNUM#Decimal points.
Alternatively, the wording I had in my last proposal (also archived) works for me. It is as follows:
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the
significand. For significands greater than this, editors should delimit high-precision values using the {{
gaps}} template; e.g. {{gaps|1.234|567|890|123|45}}
→ 1.23456789012345.{{
editprotected}}
You forgot fixing the examples. As I said above, “Now you should just replace {{nowrap|299 792 458}}
and {{nowrap|149 014 769}}
in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate" in the "Large numbers" section with {{gaps|299|792|458}}
and {{gaps|149|014|769}}
respectively (the instruction was changed but the examples weren't; this one should be uncontroversial).” --
A. di M. (
talk) 16:22, 6 March 2009 (UTC)
← In order not to confuse any admin going to address this: both I and Greg agree that the point above still applies, namely
Now you should just replace
{{nowrap|299 792 458}}
and{{nowrap|149 014 769}}
in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate.
-- A. di M. ( talk) 10:00, 8 March 2009 (UTC)
{{
editprotected}}
Under the heading "Scientific notation, engineering notation, and uncertainty" appears the bullet:
Since a region's measurement would be an area and not a length (and since the unit isn't the error/inconsistency being illustrated!), the first figure should be corrected to 2.23×102 m2. — Taper ( talk) 11:39, 6 March 2009 (UTC)
When writing the phrase "12 billion lightyears", which of the following is the best way to write it:
This issue does not seem to be clearly addressed in the MoS. Regardless of the correct answer, I suggest adding a statement explicitly explaining how to deal with compound numbers. -- Cryptic C62 · Talk 03:00, 28 February 2009 (UTC)
Lorem ipsum dolor sit amet, consectetuer adipiscing
12 billion lightyears sed diam nonummy nibh euismod.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit 12
billion lightyears sed diam nonummy nibh euismod dolore.
I’ve attended to these details in articles I work on. For instance, if it is a date like 8{{nbsp}}May
, I’ll keep such a short expression together. But if it is a longer date, like 27{{nbsp}}September
and it is next to a picture, where it might be in a very narrow column on some users’ 800 × 600 monitor (or worse), I manually drag my window width narrower to see how the word wrap flows in the paragraph and tweak if necessary.
These sort of issues crop up in more significant ways than dates; high-precision numerical equivalencies can be really nasty when word wrapping. For instance 0.45359237 kg appears in Kilogram right next to a picture. The extra two characters comprising kg don’t make it too much worse. Some editors like to keep the numeric value and the fully written-out unit of measure tied together; e.g. 0.45359237 kg. That’s quite a long sting to not allow to word-wrap so I try to use such an expression only very early in a new paragraph, where I am sure it won’t have to word-wrap (or check the word-wrap flow in variable window width). Of course, I don’t horse around with this level of detail on articles that are in a state of flux with many other contributors.
I would say a guideline could be as simple as “If it is just a two or three-digit numeric value next to a written-out named number, make it non-breaking since the extra word-wrap burden of the numeric value is minimal.” Or, alternatively…
Sinc their arr a lot uv edeters out their with a widde vareity of skeels, I woodnt bothre triing to git all of these into a guideline. I think I might just acknowledge that it is an acceptable practice and shouldn’t be reverted when done properly. Greg L ( talk) 04:14, 5 March 2009 (UTC)
• When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either
or{{nbsp}}
between the value and named number (e.g.12{{nbsp}}billion lightyears
). This will improve readability by preventing the expression from breaking at a line-end word-wrap.
<span style="margin-left:2.8em">
)12 billion
lightyears
99 billion
The unit “lightyears” actually takes up more room than both “12 billion” and “99 billion”. There is simply no problem when the practice of attaching digits to these named numbers is limited to two and three-digit numeric values; the combination ain’t that big of a character string. Greg L ( talk) 21:08, 9 March 2009 (UTC)
{{
editprotected}}
Considering we're
currently in arbitration over this, and given the willingness of those involved to continue to cite this fully protected page as if it were not in dispute, I propose adding {{
disputedtag}} with section=yes
(so {{disputedtag|section=yes}}
) to "
Linking and autoformatting of dates". —
Locke Cole •
t •
c 02:44, 8 March 2009 (UTC)
Please Locke; your disruption to Wikipedia, high and low and in every nook and cranny, started getting tedious quite some time ago. Greg L ( talk) 03:53, 8 March 2009 (UTC)
As someone with no stake in the date (de)linking dispute, I am going to disable the editprotected tag. Since there is disagreement about the requested edit, no admin is going to make the change that has been requested. However, I am certain that, even if there is not a "disputed" tag, it is well known that there is disagreement over the issue of date linking. And the protection template at the top of the page is a clear sign to any reader that there is a dispute. — Carl ( CBM · talk) 04:07, 8 March 2009 (UTC)
(*sigh*) Could it be that I recently quote MOSNUM in an ANI? Unable to change what MOSNUM says, you asked, above, to have a {disputed} tag slapped on the text with which you disagree. Someone then quotes “consensus”. WP:Consensus is not locked down so there you go, making edits to WP:Consensus to push a POV that, IMO, is A) self-serving in your crusade on date linking, B) amounted to editing against consensus on WP:Consensus; all of which is C) part of a crusade on an issue—date linking—which past RfCs clearly show the community has no stomach whatsoever for.
Please chill and let the ArbCom on all of this run its course. I know you won’t believe me, but what I say is true: your running around trying to change the foundation principles of Wikipedia’s guidelines and policies won’t feed into and influence the outcome of the ArbCom; if anything, it is the other way around.
As for “bullying”, well… Do you see me running around, insisting upon unwelcome changes to long-standing Wikipedia policy pages? Cow patties.
Greg L (
talk) 17:59, 8 March 2009 (UTC)
{{ editprotected}} Can someone please add the {{ disputed}} tag at the end of the sentence here reading "Dates (years, months, day and month, full dates) should not be linked, unless there is a reason to do so." This is still a matter of dispute, but I'm seeing this cited as an actual standing guideline by editors unfamiliar with the protected nature of the page. -- Kendrick7 talk 05:22, 8 March 2009 (UTC)
I am going to disable the editprotected banner. There is obviously a dispute, but the protection banner already indicates this. I strongly doubt that any admin would edit this page while it is protected to place a disputed tag on it, since it would never be feasible to get agreement about such an edit. — Carl ( CBM · talk) 13:57, 8 March 2009 (UTC)
{{
editprotected}}
The numerically oriented birth and death templates eg: {{
death date and age}}
have a number of problems as discussed last month in
MOSNUM discussions. Due to the needless complexity these older templates introduce, their error prone nature, their inflexibility with date display, as well as their inability to handle Julian dates, I suggest the following change to the guidance regarding their use. The new guidance steers contributors to the templates that accept plain text dates rather than the numeric dates:
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, thegregorian
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.
The current passage may be found in the birth and death dates section. Comments/ improvements? - J JMesserly ( talk) 19:55, 11 March 2009 (UTC)
Personally, I think the birth and death years should be linked for EVERY biography, as history is important and a person's life is lived in context. However, when it comes to articles on "oldest" or "last survivors," the year of birth becomes an imperative part of the story. That Henry Allingham was born in 1896 and is still living beggars the question: how has the world changed in 112+ years? Having a convenient link to the year 1896 makes sense in these cases. Therefore, an exception should be made even if a decision is made to not link birth and death dates. Ryoung122 10:50, 12 March 2009 (UTC)
I'll have to disagree with Ryoung & Anderson here. Trivia about the particular year that a person happens to have been born in has little connexion to a serious biography. By all means link to the century/centuries he lived in but not a particular year. JIMp talk· cont 18:49, 12 March 2009 (UTC)
All kinds of interesting things happened in 1896, such as the first modern Olympic Games, the 40-minute Anglo-Zanzibar War and a pivotal (realigning) U.S. Presidential Election. Whether they (or equally-important but completely-apolitical events) are properly featured is a matter of editing 1896. ¶ But that's really not the point, the editors working on Henry Allingham's article are those who should discuss and decide whether that particular article is interesting enough or relevant enough to their article to merit a link. Trying to establish a single policy in such matters for two million articles is far worse than madness. —— Shakescene ( talk) 22:03, 12 March 2009 (UTC)
This matter will be addressed in depth in an Arbcom-spawned RfC, I suggest that users direct opinions and input about the RfC here. Dabomb87 ( talk)
A while back I saw a discussion where many editors voiced opposition to any form of date autoformatting that caused registered users to see different content from unregistered users. Does anyone else remember this? Where is this discussion archived?
I'm wondering because there's now a proposal to open a new can of worms by creating a "formatdate" function that does exactly the same date autoformatting that was rejected before, just without the brackets. — Remember the dot ( talk) 01:10, 17 March 2009 (UTC)
Please add the shortcut WP:COMPUNITS for the discussion of how to represent binary/decimal values. Ham Pastrami ( talk) 03:11, 17 March 2009 (UTC)
It seems that cool heads, peace, and civility has broken out—completely unchecked—all over the place on the ArbCom and its related subpages. I have this proposal: Why not unlock MOSNUM with the proviso that anything related to date formats, autoformatting, and date linking be left alone. Greg L ( talk) 04:40, 17 March 2009 (UTC)
P.S. After MOSNUM is unlocked, maybe we might see that everyone standing around on Wikipedian street corners will have a confused, blank look, and say to their neighbor “Instead of running for our AK‑47s, wanna play a game of checkers or something?” Greg L ( talk) 04:47, 17 March 2009 (UTC)
Unlocking MOSNUM will help everyone settle into a feeling of normalcy, which has been sorely lacking for a while. Greg L ( talk) 03:34, 18 March 2009 (UTC)
Hallelujah. (I had proposed this on 15 February, but it was ignored.) -- A. di M. ( talk) 16:37, 20 March 2009 (UTC)
As previously discussed ( archive), would anyone object to my adding this as the fourth bullet point here on MOSNUM:
• When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either
or{{nbsp}}
between the value and named number (e.g.12{{nbsp}}billion lightyears
). This will improve readability by preventing the expression from breaking at a line-end word-wrap.
Greg L ( talk) 22:06, 19 March 2009 (UTC)
• When expressing large approximate numbers, it is preferable to write numbers in words, or partly in figures and part in words, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but It grossed $28,106,731 on its opening day (the exact number). When both a figure and a word are used in the same number, it is useful to use a non-breaking space, as in
128 million
, to prevent a line break from occurring between them.
(outdent)
I took the initiative and looked at the existing verbiage. I’ve revised the key nouns to be harmonious with adjacent text and added the following:
• When expressing large approximate quantities, it is preferable to write them spelled out, or partly in figures and part as a spelled‑out named number, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but The movie grossed $28,106,731 on its opening day (the exact quantity).
• When both a figure and spelled-out named number are used in a quantity, it is useful to use a non-breaking space, as in
128 million
or128{{nbsp}}million
to prevent a line break from occurring between them.
Be my guest to tweak and revise to your heart’s content; I’m not stuck on anything—just the basics here. Greg L ( talk) 04:31, 21 March 2009 (UTC)
An aside on browsers. Many of us have tweaked the appearance of our code with thinspaces and whatnot to make rendered pages appear better. This is just a reminder that if something doesn’t look quite right and you are using Internet Explorer 8, that it would be a good idea to try other browsers too. According to ChannelWeb, IE 8 rates a 20 out of 100 on The Web Standards Project’s Acid3 Browser Test, which “is the third in a series of test pages written to help browser vendors ensure proper support for web standards in their products.”
The ChannelWeb article mentioned also that “Apple's Safari 4 browser scores 100 on Acid 3”. Whereas Safari is only third in market share, with nearly 11% of Web activity, it will show you how pages are supposed to look. Greg L ( talk) 21:25, 21 March 2009 (UTC)
Many writers have converted the years under Buddhist Era (BE) to Christian Era (AD) in an incorrect way for they left one exception behind.
We should take notice that:
Article 3 is an exception usually left behind by many people, and this led to a great problem about inaccuracy of year counting or conversion in many Wikipedia articles as to Thailand, Thai persons, Thai stuffs, Buddhist stuffs and any others in connection with the said.
Therefore, I suggest us to lay down a project to check and rectify the said mistakes. I cannot say how to carry out the project, but I can say that checking whether this one is a correctly-converted year or not would be much difficult and we need to seek Thai Wikipedia for cooperation. Thai Wikipedia is also meeting with the same problem as us. —— PORtrait | chit~chat - 24 March BE 2552 (2009), 03:17 hours (GMT+7)
The above link leads to a community poll regarding date linking on Wikipedia. The poll has not yet opened, but the community is invited to review the format and make suggestions/comments on the talk page. We need as many neutral comments as we can get so the poll runs as smoothly as possible and is able to give a good idea of the communities expectations regarding date linking on the project. Ryan PostlethwaiteSee the mess I've created or let's have banter 19:43, 21 March 2009 (UTC)
Is there any standing on the abbreviation of months in an article? Is abbreviation ever acceptable? In what cases can they be accepted? or can not? Is it known as unacceptable in infoboxes? FireCrystal ( talk) 16:59, 27 March 2009 (UTC)
I don't think kcal is kilogram calorie but kilocalorie, which is different. -- SLi ( talk) 18:05, 24 March 2009 (UTC)
RockyMtnGuy exaggerates the case against using a hyphen. The source he(?) uses has this to say in another section:
9.4 Spelling unit names obtained by multiplication
When the name of a derived unit formed from other units by multiplication is spelled out, a space, which is preferred by Ref. [6] and this Guide, or a hyphen is used to separate the names of the individual units.
Example: pascal second or pascal-second
-- Jc3s5h ( talk) 17:49, 27 March 2009 (UTC)
I went ahead and removed the example. If no-one objects, I'm going to mention that spaces can also be used. -- A. di M. ( talk) 20:17, 27 March 2009 (UTC)
Hi. What do you do with articles that only use Islamic dating (A.H. - After Hejira) for reference in the English-speaking Wikipedia? Do we leave the dates alone? It renders the article essentially useless for English-speaking individuals accustomed to western ( Gregorian calendar) dating traditions. I can accept there being co-dating with Islamic dating along side Gregorian dates as it provides us with more information - although I don't know what Wikipedia's policy is for it - but it seems self-defeating (from an information perspective) to leave articles such as this, uncorrected. Is there a Tag/template located somewhere that we can post, urging the article to be converted to Gregorian dates and/or that any new dates be entered using Gregorian calendar dating? In particular, many of the scientific and scholarly Arabs do not have Gregorian dates assigned to their articles but instead use A.H. dating, such as Al-Juwayni... Stevenmitchell ( talk) 04:52, 29 March 2009 (UTC)
The date linking and formatting poll is now open. All users are invited to participate. Ryan PostlethwaiteSee the mess I've created or let's have banter 23:00, 29 March 2009 (UTC)
I've gotten a positive response at WT:MOS#Which is it (i.e.)? to my request to stop monthly updates of the WP:MOS page for the 4 reasons I gave there. This is the only other page that, conceivably, all 4 reasons apply to; it's too soon to tell. I'll ask for opinions at the end of the month. - Dan Dank55 ( push to talk) 22:42, 20 March 2009 (UTC)
What is the correct format to use if you know the range of years within which a person died? The problem occurs in Adam de Stratton, who was alive in 1292, but dead by 1294. Using a dash seems a bit silly, as if he spent two years dying. Some publications use an "x", as in 1292x94. Lampman ( talk) 19:09, 1 April 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.
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)
a 10-kilogram (22 pound) bag of potatoes and a 5-kg (11 lb) bag of carrots
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)
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)
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)
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)
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 [15] and the other can be found at [16]. 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)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 115 | ← | Archive 118 | Archive 119 | Archive 120 | Archive 121 | Archive 122 | → | Archive 125 |
Somebody kindly brought my attention to Wikipedia:Manual_of_Style_(dates_and_numbers)#Conventions that says:
I propose deleting this guideline. I suspect the motivation for the guideline is that it resolves a potential ambiguity when the reader could mistake each value. For example, a glass door might be 8 millimetres thick, 2 metres high and 1 metre wide. Therefore it needs to be presented as "8 mm x 2 m x 1 m". However, I would like to be able to describe a painting as having dimensions of:
This seems to me to be perfectly reasonable but the guideline would require.
It is unlikely that the height of a painting will be 100 times the width. But if it were, any reasonable editor would add the unit labels without needing to be told i.e. "4 cm x 4 m". The guideline requires an additional eight characters (four metric, four non-metric) for two dimensional applications and sixteen characters for three dimensional applications. It adds no value but adds a burden. I propose that it is simply deleted. Does anyone support the proposal? Lightmouse ( talk) 11:31, 27 January 2009 (UTC)
70 × 90 cm can be interpreted as seventy times 90 cm, e.g. something composed by 70 pieces, each 90 cm wide and of unspecified height, placed side-by-side. -- Army1987 – Deeds, not words. 12:09, 27 January 2009 (UTC)
Milkbreath said "you yourself display so little proficiency in matters typographical". I am always seeking to improve but sweeping criticism isn't something that I can work with. Can you provide an example of a typographical error that I made? Lightmouse ( talk) 12:51, 27 January 2009 (UTC)
I was uneasy about the insistence on the repetition from the start. The guideline should be changed to allow what is almost always an unnecessary repetition to be dropped. Tony (talk) 14:01, 27 January 2009 (UTC)
Problem: "70 × 90 cm" could be mistaken for 6300 cm, whereas in fact it's 6300 cm2. In some contexts that is crucial. Michael Hardy ( talk) 20:20, 27 January 2009 (UTC)
This would be a perfect example for giving advice: When giving the dimensions of an object, "70 × 90 cm" is more natural and idiomatic; in some contexts, however, it may be ambiguous, in which case use "70 cm × 90 cm". This is what rational editors would do if we were silent; can we either say something like this, or leave the point alone?
If we can agree, we can use {{ editprotected}}. Septentrionalis PMAnderson 01:15, 28 January 2009 (UTC)
If you want to ban this popular format, you have to tell us that you think it is confusing in real articles. Please look at Mona Lisa and tell us if you think you are confused by how it describes its dimensions. Seriously. Lightmouse ( talk) 11:58, 28 January 2009 (UTC)
Question: Is it actually true that "70 × 90 cm" is "idiomatic" as has been claimed above? Is it common in publications? In my anecdotal experience, while "70 cm × 90 cm" and "70-by-90" (with no units) are common in everyday speech, "70 × 90 cm" is not. Shreevatsa ( talk) 17:19, 28 January 2009 (UTC)
I've often come across several IPs ( here, here, here, and several more) that change regular date format to something like this. These IPs (probably all the same person) continually make these edits and often go on unreverted. I usually make it my job to go and revert all the edits the IP makes. These IPs have been repeated been warned, explained to, blocked, and sometimes, just get away with it. It's become real tiresome to continually revert these edits and I don't know how to deal with it. Thought their edits are easily detected (they use the name of the article as the edit summary), they often go by for minutes to hours without the edits being reverted, and I can only do so much with limited time. I really can't think of a possible solution, considering the range of these IPs and I can't fix it all alone. So basically, what I'm asking, is there any possibles solutions do this, or will other editors and I have to just revert each edit? Diverse Mentality 07:08, 3 February 2009 (UTC)
Maybe reverting is the wrong answer. Some of the edits that they have done have substituted a date for a year. If the date is correct, and can be verified, then substituting a date is good. It is a pity they use an ambiguous mm-dd-yyyy format, since some readers will think it is dd-mm-yyyy. The best thing to do is to convert to a normal dd mmmmmm yyyy format, and to add {fact} by it, to indicate that no source is quoted. Simply reverting is unhelpful when the user has added information.
Some of the edits have delinked dates - a bit like Lightbot - only they have used a mm-dd-yyyy format. The best thing to do is not to revert but to change to the normal dd mmmmmm yyyy format.
I am sure whoever is doing this means no harm. They should not be treated as a vandal. If you are an unregistered user of wikipedia (or a registered one using a computer where it would be inappropriate to log in) it is really annoying and unhelpful if someone treats you as a vandal just because you change content that is wrong.-- Toddy1 ( talk) 08:42, 3 February 2009 (UTC)
Toddy, I'm sure the user(s) mean no harm, but the fact that the IPs, such as the first one I linked (among others), have been directed to WP:DATE several times and have ignored these warnings, they continue to make such edits. Their edits start to become disruptive. Diverse Mentality 20:27, 3 February 2009 (UTC)
Regarding this page: 17 Kids and Counting, the tags to show birth date and age in the chart for the children keeps getting removed by anonymous IP editors. The few explanations given for the removals are that we don't know the ages of the children (which makes zero sense considering we know their exact birth dates) and that figuring out the age is basic math (despite the fact that this tag was created for the sole purpose of identifying the age, simple math or not).
I was iffy on whether to include the tagged dates when I merged the articles, but decided to since all the birth dates are known and I don't see any reason why the ages should not be included, if the birthday is included (especially given the subject matter). The second time the tags were removed, it was identified as vandalism by another long-time, established user, which prompted me to continue reverting the changes...but now I'm not so sure since it keeps getting changed by IPs (yet explanations are no longer being offered in the edit summaries and no one changing it is bothering to discuss this on the talk page). Are the tags appropriate in this case? Should they be removed? I don't care either way, but it's getting a bit ridiculous. Can someone give me some help here? Thanks. -- 13 2 18:29, 3 February 2009 (UTC)
Over at Krupp Diamond the text was changed from:
to
on the grounds that the metric units make things less legible. I re-added them but I don't want to get into a revert war with what appears to be a genuine concern by an editor that may be more familiar with 'carats' than I am. Can people take a look and see if metric units cause any legibility problems in that article? Lightmouse ( talk) 11:48, 8 February 2009 (UTC)
All we’re doing in these examples is following current literature (FCL), which varies from discipline to discipline. If a record-setting diamond like the Hope Diamond is particularly notable because it’s so damn big, it would be rather nice to know how many grams it is and to state as much right in the article without requiring readers click on a link and do some math. But for regular, pedestrian purposes, a 0.5-carat diamond is a 0.5-carat diamond and there is simply no point to cluttering up Wikipedia with conversions to units of measure that are unused in the discipline—even if its the splendorific SI by the French. It’s not like we’re preparing to get earth ready to join the United Federation of Planets. Also, we are really and truly not “heading down some path” or “opening the door” to any practices to rid Wikipedia of the SI when we do this; we are simply embracing Follow Current Literature, which best prepares our readership to be conversant in the art and best readies them for their continuing studies elsewhere. Also…
This is, after all, an electronic encyclopedia; let’s exploit the true power of links. For pedestrian purposes, all we need is a first-time link to carat, which explains that a carat is 200 mg. Or, at most, a one-time conversion or explanation right in a given article that one carat is 200 milligrams will certainly do no harm.
And no, an 81 mg diamond or a 200 mg diamond is not the same weight as an 81 or 200 mg medicine tablet. All tablets have “excipients” (non-active tableting ingredients) like microcrystalline cellulose as a binding agent, and flow agents and other excipients. These inactive additives contribute significantly to the mass of tablets. I know, since I’ve formulated tableting formulas before. I went through 32 iterations on my last effort until I had one that had all the right properties, which is now called “Formula #33.” Greg L ( talk) 05:28, 10 February 2009 (UTC)
I agree with Gerry. The world of oil might think in terms of the 42-US-gallon barrel but I don't, nor do I have any burning need to be prepared to be conversant in the art nor readied for continuing studies. They've got their wacky units and they can keep them, let me read an article without having to multiply every number I run across by 0.2. JIMp talk· cont 07:34, 10 February 2009 (UTC)
If you have any unit used fifteen time in one sentence, you probably should do a rewrite. Clutter for one is useful information for another. JIMp talk· cont 20:55, 10 February 2009 (UTC)
I am sorry if I asked the question in the wrong place. Lightmouse ( talk) 09:07, 11 February 2009 (UTC)
Thanks. There is also a debate going on at Template_talk:Convert#Excessive_use_of_double_output about whether carat conversion should continue to be unusual. Lightmouse ( talk) 11:55, 11 February 2009 (UTC)
{{
editprotected}}
Will some admin please make two, uncontroversial updates to MOSNUM, as outlined above at
Val is now fixed?
Greg L (
talk) 05:34, 10 February 2009 (UTC)
I don't see this addressed in the style: commas after dates. In standard written English, this sentence has the comma after the year: "His popularity fell after his arrest on June 12, 1987, became known." Many Wikipedia pages render this incorrectly, leaving out the comma after the year. Should this standard rule be included in the manual on dates and numbers? Is this addressed by any of the bots that fix dates? BlackberryHacks ( talk) —Preceding undated comment was added at 22:00, 10 February 2009 (UTC).
The comma following the year is required because the year is parenthetical. It's required for the same reason that a comma is required in the sentence: I believe that Jack Smith, my brother, is a good man. It's just a different way of writing: His popularity fell after his arrest on June 12 (in the year 1987) became known. By the same reasoning, the year should actually be made parenthetical even when using DMY format, although I've not seen any style guides that recommend that. -- UC_Bill ( talk) 16:35, 12 February 2009 (UTC)
It would solve the problems of {{
val}} with numbers with many digits, although users would have to specify breaks by hand. For example {{User:A. di M./margins|−2.002|319|304|3622(15)}}
would yield −2.0023193043622(15).
It could also have other uses, too. See more examples on User:A. di M.#Testing /margins. The template itself is at User:A. di M./margins. I've put it in my userspace rather than in the template space because I'm not sure about how to name it.
(I haven't included support for automatic handling of exponential notation, uncertainty, etc. yet, but I might add it later. As for the margin size, I've used 0.25em for consistency with what {{ val}} does, but personally I would use smaller margins, e.g. 0.2em.) -- A. di M. ( talk) 11:02, 5 February 2009 (UTC)
As for the em-width, it is a tradeoff; different editors see different widths on their hardware/software platforms.
Are you going to be doing the scientific notation aspect too? Greg L ( talk) 23:22, 6 February 2009 (UTC)
Now that I’ve done my prima dona-bashing on developers, one of them, Robert Rohde, fixed some behind-the-scenes math business that {val} relies upon so it no longer suffers from its seemingly random rounding errors. In other words: {val} now works!
By “fixed”, I mean that {val} now is perfectly predictable. And, though predictable, {val} is not perfect. According to Robert, {val} is good only up to 10 significant digits. I haven’t done elaborate experiments, but I see that it can do twelve-digit tasks like this:
Note that {{ val}} will not work with values that end with a zero (which can happen when uncertainty is expressed), and may not properly work beyond about 10 to 12 significant digits.
{{ val}} is meant to be used to automatically handle all of this. Note that {{val}} can not handle digits with more than about 10 to 12 significant digits and can not properly display signficands that end with a zero. Thus, if you have a value that should display like 1.452800(25) × 10−23, {{val}} will generate 1.452800(25)×10−23.
I don't know what is the optimal solution, but, depending on your screen, resolution, text size and sidebars, you may see the line that includes the dozen significant digits and breaks go over the right end of your screen. (I use the "mini-browser" sidebar in Netscape Navigator 9.0.0.6 for my Watchlist.) It's possible that the "nowrap" required by the example means that this problem isn't fixable, but perhaps some administrator (since the page is fully protected) could insert an appropriate break, unwrap or blockquote to keep the text within the margins. Thanks. —— Shakescene ( talk) 01:06, 11 February 2009 (UTC)
?action=purge
as a suffix to the end of the URL and hit [enter]. This occurs when the server that fed the request has math settings that can only handle up to 12 digits. If you purge/refresh and the error flags go away, then your request was served by a 14-digit-capable server. Eventually, as they replace old servers in Wikipedia’s server farm, the percentage of time that this happens will go to zero (a matter of weeks). Then, only the 15-digit numbers on the page should produce error flags.If you want to speed up the purge iteration time, you can try using Val microsandbox Greg L ( talk) 03:36, 18 February 2009 (UTC)
Readers of this thread may be interested in examining the documentation for {{ start-date}}. This is an example of a date-time template that imposes fewer restrictions described by opposing camps in previous date formatting debates. It addresses the numerical accuracy interests such as those of the microformat / metadata camp interested in accurate ISO8601 dates, and those interested in readability, imposing far fewer restrictions concerning formating or using templates such as for Julian dates precisely. Examples:
Start-date & End-date usage (colors for emphasis only): |
Sample below displays 7 December 1941, and microformat date: 1941-12-07TZ
|
Sample below demonstrating how days, timezones and hours, minutes and seconds can be shown. (Order often not important). Displays 5:43PM HST, December 7, 1941, and microformat date (corrected for UTC): 1941-12-08T03:43Z
|
Sample below demonstrating use of links with dates. Displays links to day of month and year pages.
December 7,
1941, and microformat date: 1941-12-07Z
|
Sample below demonstrating use of Julian calendar dates. Displays 9 June [
O.S. 30 May] 1672, and microformat date: 1692-06-09Z
|
I have proposed that the old way of specifying dates in wonky error prone forms be deprecated. Specifically, this sort of template is completely unnecessary: Eg:{{Start date|1941|12|7|18|Z|df=yes}} might seem to be the correct syntax for the december 7 example above, but the user must do their own conversion to UTC, and they can't format the way they like to. They also may run into bugs. The above example displays as:
I propose that a new family of templates that allow contributors total freedom in formatting dates, using links or templates, which simultaneously allowing the precision folks such at the microformats/ ISO8601 crowd to express dates in their gregorian oriented with the accuracy they desire. This particular template correctly generates ISO8601 date/times between -6999 BC to 6999 AD in natural language and properly handles time zones and date arithmetic in natural forms (eg "february 08, 2009 next sunday" delivers 2009-02-15). Most of the magic is not in the template but an underlying wikitext function, but the point is that in many if not most cases there is no longer any technical need to use wonkey templates requiring separate parameters for year month and days as many have advocated in the past. If anyone is interested in a customized form of this free form template or have ideas for it being even more simplified or able to perform additional functions, please contact me.
Users interested in verifying the ISO values emitted by these examples may see them by turning off CSS in their browsers, (eg: in Opera, use the view Author versus user mode and set one mode to no style sheets). - J JMesserly ( talk) 08:50, 9 February 2009 (UTC)
18:0Z, 7 December 1941
" is not in one of the formats listed on {{
Start date}}'s documentation. "GIGO" applies.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 19:09, 9 February 2009 (UTC)
18:00, 7 December 1941 (-10:00)
. If you have an issue with that, I can only reiterate, once again, that you have been invited to raise them on that template's talk page. You appear to still not have done so.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 13:08, 10 February 2009 (UTC)(undent) The issue I raised here is obvious from your example. The syntax is needlessly unintelligible and complex. I propose that the Manual of style state that human readable templates are preferred to that are less human readable. - J JMesserly ( talk) 17:45, 10 February 2009 (UTC)
{{Convert|one and three-quarter inches|cm}}
work.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 18:42, 10 February 2009 (UTC)
Andy, the
Hudson's Bay Company article contains the {{
Infobox Company}} template, which the proposed bot would act upon. Please explain what the result would be, both in terms of the new parameter, and in terms of the microtext that would be emitted, for the parameter foundation = May 2, 1670
. --
Gerry Ashton (
talk) 20:33, 10 February 2009 (UTC)
foundation = [[Santiago de Cuba]], [[Cuba]] ([[February 4]], [[1862]])
May 2, 1670<span style="display:none"> (<span class="bday dtstart updated">1670-05-02</span>)</span>
George Washington's family bible recorded his birth as the "11th Day of February 1731 / 2". [4] We now state the first President's birth date as February 22, 1732. The old style dates were often expressed as "1731 / 2" because the New Year could be March 25 or January 1. Happy birthday George. -- SWTPC6800 ( talk) 05:39, 11 February 2009 (UTC)
{{Start date|1963|11|22|19|00||-07:00
renders as 19:00, November 22, 1963 (-07:00) and emits 1963-11-22T19:00-07:00
; alternatively {{Start date|1963|11|22|13|00||}}
renders as 13:00, November 22, 1963 and emits 1963-11-22T13:00
. is currently transcluded around 10,000 times, and has been in use - without any significant complaints - since July 2007.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 19:39, 11 February 2009 (UTC)
wikitext | display | microformat | |
---|---|---|---|
old | {{Start date|1963|11|22|19|00||-07:00}} |
19:00, November 22, 1963 (-07:00) | (1963-11-22T19:00-07:00) |
new | {{start-date|November 22, 1963 1pm CST}} |
November 22, 1963 1pm CST | (1963-11-22 T19Z) |
Given the example that even one of the authors of the template {{ start date}} forgot how to use it (see above example on date of JFK death) due to its obscure rules, I propose that there be an indefinite moratorium on any future bot runs converting articles from use of intelligible dates to the far less human readable form that {{ start date}} uses. Unnecessarily complex encodings present obstacles to contributors to Wikipedia. As shown, they can present obstacles even to those who are expert in their use. 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. - J JMesserly ( talk) 15:39, 12 February 2009 (UTC)
You oppose the moratorium? The argument at BOTREQ was that the bot run was uncontroversial. Clearly that is not the case. What is your argument in favor of the old {{ start date}}? I think it is fair to represent opinion here that it needlessly complicates wikitext representation of dates. Your response? - J JMesserly ( talk) 23:25, 15 February 2009 (UTC)
(Quote Copied from BOTREQ by J JMesserly)::There is no controversy. Please avoid unnecessary drama. There is no obscurity and the template is not "error prone"; unlike the supposed alternative. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:06, 13 February 2009 (UTC)
{{
editprotected}}
After a couple days of troubleshooting and e-mailing back and forth with the developers, it turns out that {{
val}} has inconsistent results with 13 and 14-digit significands because roughly 20% of Wikipedia’s servers are old ones running Fedora. In a matter of weeks, those outdated servers will all be replaced so all are like the new ones, which are running Ubuntu. Once that happens, {val} will reliably handle 14-digit numbers. In the mean time, it can only properly generate 12-digit numbers 100% of the time.
User:Dragons flight, who is a developer, has volunteered his efforts and done a fabulous job revising the number-crunching engine that {val} uses. Val now requires ten times less processor cycles (overhead) to render numbers than it previously did, and it now handles significands that end with zeros. Thus, values with uncertainty, such as 1.2345678900(32)×10−23 kg properly display without dropping off the (seemingly) non-significant digits.
In the mean time, MOSNUM needs to be updated with the proper advise regarding {val}…
At Decimal points, please replace the last paragraph with this:
At Notations, add this bullet point at the top:
At Uncertainty, replace the last paragraph with this:
I can see that this entire section covering big numbers, decimal points, delimiting, etc., needs to be revised and harmonized. That is for later after MOSNUM is no longer locked down. Though editors will have to hunt for relevant information, at least what they find will be correct.
Greg L (
talk) 01:25, 12 February 2009 (UTC)
{{
editprotected}}
{{
val|0.1234567}}
generates 0.1234567 (with a four-digit group at the end); but due to server-related issues, {{
val}} can reliably handle no more than 12 significant digits. In cases where {{
val}} fails, the template {{
gaps}} can be used, but the position of the gaps has to be specified by hand.P.S. Here at leŭksman: Your donations at work: new servers for Wikipedia, is something that relates to how {val} will one day soon work consistently at 14 digit resolution. Greg L ( talk) 22:04, 12 February 2009 (UTC)
The [percent] symbol is unspaced (71%, not 71 %).
According to the BIPM’s SI Brochure– 5.3.7 Stating values of dimensionless quantities, or quantities of dimension one, the BIPM is clear about the SI writing style with regard to the “%” symbol; it states as follows: “When it [the percent symbol] is used, a space separates the number and the symbol %.” This calls for 75 %, not 75%. However, it customary to not do so.
I agreed with your proposed wording regarding {val} and digit grouping. I think your wording is better by being more accurate without opening up Wikipedia to an unnecessary hodgepodge of number formats.
If you are trying to make a broader point about the purpose of MOSNUM and the extent to which editors should (or must) comply, I don’t feel I can contribute to this tangent. Perhaps this discussion belongs on one (or both) of our talk pages. I think, as a practical matter, MOS and MOSNUM are style guides that must have flexibility on certain points and be more specific and definitive for others. Greg L ( talk) 00:40, 13 February 2009 (UTC)
-- A. di M. ( talk) 10:50, 13 February 2009 (UTC)
I’ve taken the liberty of borrowing heavily from A. di M.’s proposed wording (particularly the “it is customary” language) and added more detailed guidance in several places for the benefit of less experienced editors. The two bullet points below would replace the last bullet point in
Decimal points. It also clarifies a distinguishing point about 12 digits to the right of the decimal point v.s. 12 digits total in the signficand. Per Jimp’s suggestion below, I’ve also revised ‘manual’ delimiting to the use of {{
gaps}}, which I see is now in article-space.
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the
significand. For significands greater than this, editors should delimit high-precision values using the {{
gaps}} template; e.g. {{gaps|1.234|567|890|123|45}}
→ 1.23456789012345.If someone finds a mistake or has some other improvement, please consider the above two paragraphs between the rules as a group-product worksheet to which anyone may contribute. Just leave a short note below stating your edit summary. Greg L ( talk) 01:06, 18 February 2009 (UTC)
In a sentence such as
The latitude of New Zealand, from approximately 34 to 47° S, corresponds closely to that of Italy in the Northern Hemisphere.
should there be any space between the degree and the S for south? MOS:NUM isn't consistent with itself: the section "Non-breaking spaces" uses one in "5° 24′ 21.12″ N" uses one; the 'Quick "how-to"' in "Geographical coordinate doesn't, the output of the templates mentioned there doesn't, the example about Oslo does.
Does that mean that both formats are acceptable? (FWIW, I did use a space in that sentence, [6] as I think it is more legible with the space.)
(BTW, sometimes the double prime ″ sign is replaced by a quotation mark " or by two prime signs ′′. Should that be fixed?)
A. di M. ( talk) 10:11, 15 February 2009 (UTC)
Within the US, the way to symbolize "degree Celsius" is officially decided. The Congress authorized the Secretary of Commerce to interpret the International System of Units (SI), and the Secretary of Commerce recognized the National Institute of Standards and Technology's Special Publication 330 as one of two documents interpreting SI for the US. That publication states
The numerical value always precedes the unit, and a space is always used to separate the unit from the number. Thus the value of the quantity is the product of the number and the unit, the space being regarded as a multiplication sign (just as a space between units implies multiplication). The only exceptions to this rule are for the unit symbols for degree, minute, and second for plane angle, °, ′, and ″, respectively, for which no space is left between the numerical value and the unit symbol.
This rule means that the symbol °C for the degree Celsius is preceded by a space when one expresses values of Celsius temperature t.
I believe the interpretation is the same in other countries, and that it would be reasonable to follow the same style for °F. -- Gerry Ashton ( talk) 20:20, 15 February 2009 (UTC)
There was no edit warring at the time of protection, the only reason given what "Oh noes, what about the vandals!" as if they would not be reverted in less than
5.39124(27)×10−44 s. (turns out there was edit warring ... back in november!) It's been nearly 3 months now. It's ridiculous that we have to ask permission to move a comma around. This is not kindergarten! Let experienced editors freely edit the page by default. If there's actually a problem, then lock the MOSNUM down, but don't lock it down for something silly like fear of vandals. The biggest level of protectiion that this pages warrants by default is edit=autoconfirmed and move=sysop.
Headbomb {
ταλκ
κοντριβς –
WP Physics} 11:25, 15 February 2009 (UTC)
Right now, there are some areas of MOSNUM, such as the entire Section 3 (Numbers), that needs to be harmonized and streamlined so there is less duplication and editors can find information where one would reasonably expect it. I see no need to have complete paralysis here while ArbCom tries to decide if their processes suffer from a serious hiccough, or are galactically dysfunctional.
BTW, some time ago, I saw a post on an admin hangout here on en.Wikipedia from an admin from the Persian (Iranian) Wikipedia. He had problems with editors putting death-to-Israel flags and pictures of SCUD missiles on their user pages. These editors were also editing articles with a strong, POV-pushing, anti-Israel bent. He came to en.Wikipedia for guidance as to what to do. The advise from our admins was along the lines of “WTF? Get some help, here’s the Wikipedia principle you adhere to, and get tough.” It seems to me that circumstances here on en.Wikipedia can sometimes spiral out of control to the point that even admins here question whether they can do anything about it. Greg L ( talk) 01:44, 18 February 2009 (UTC)
Most talk pages have links to all the archive pages in the archivebox. This one currently does not. Apparently there was an effort to keep DA discussions in separate archives? Sometime before Dec 7, >3000 edits ago, someone added the (mislabelled) links "118 (D12)" and "118 (D13)" and since then the archive index is untouched. The missing archive links 113-115, 119, 120 are basically all DA discussions.
So what is the scheme and what can be done to fix it? I can update the index easily enough, but is it also desired to strip out the non-DA threads into a separate archive? Franamax ( talk) 18:17, 16 February 2009 (UTC)
When this sentence occurs mid-paragraph and is the only occurrence in the article of a number which is the proper or preferred style? I can't seem to find a specific mention of this in the MoS. Also, is there an easy way to search the archives of all the MoS talk pages, and ONLY the MoS talk pages? -- OlEnglish ( Talk) 19:19, 16 February 2009 (UTC)
OlEnglish, the link and excerpt given by Gerry Ashton seem to answer your question. You have freedom of numeral! Use tact, poise and reason. And please ignore the sniping from the peanut gallery. These poor unfortunates have nothing better to do :D -- Goodmorningworld ( talk) 01:15, 18 February 2009 (UTC)
It's time to remove the bit about thin spaces. There was a discussion some time ago about the use of these and it was found that they were problematic because they don't render properly on all browsers (including the version of Internet Explorer I'm using right now). Greg's gaps (used by {{ val}} and {{ gaps}}) came to the rescue with the added advantages (or what some, including me, might consider essential features) that they are already non-breaking and vanish on copy & paste (allowing numbers to be directly input into spreadsheets or other calculational applications). JIMp talk· cont 23:37, 17 February 2009 (UTC)
BTW, I completely douched 3⁄4 of this page by accidentally coding {[tl|gaps}} (with a curly bracket followed by a square bracket) in the first paragraph of this post. [7] Man-oh-man, Wikipedia’s server engine doesn’t like that; it simply wouldn’t show the entire last three-quarters of the page, including my post with the goofed-up brackets—not even in edit view. I had to go to a pre-edit, historical page, grab all that pre-goof code, and completely replace the contents here. Maybe {[tl|gaps}} is a fluke, or maybe this is a purposeful code I didn’t know about that is intended to mess with spacetime so you can go back into history and make it so Hitler had never been born. Greg L ( talk) 01:11, 18 February 2009 (UTC)
{{
editprotected}}
The text in question is under
Large numbers and is as follows.
In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. "8,274,527". In scientific context, thin spaces can also be used (but using {{ nowrap}} to prevent line-breaking within numbers), e.g. "8 274 527" (
{{nowrap|8 274 527}}
, or using the thin space character instead of its HTML entity). Consistency within an article is desirable as always.
I'm proposing that the text be changed to the following,
In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. "8,274,527". In scientific and mathematical contexts, {{ gaps}} may be used to insert thin spaces, e.g. use {{
gaps|8|274|527
}} to produce "8274527" (note: the thin space character and its HTML entity, 
, do not render correctly on some browsers). Consistency within an article is desirable as always.
JIMp talk· cont 07:33, 26 February 2009 (UTC)
Paragraph 2 seems to be a valid argument for having at least two English Wikipedia versions. 84.9.125.170 ( talk) 23:09, 22 February 2009 (UTC)
As many of those who keep tabs here know, there has been an ongoing arbitration case on (de)linking chronological items. One of the clerks has started the framework for perhaps the most intricate RfC on the issue yet, which includes date autoformatting and other definitions of said feature. Please see User:Ryan Postlethwaite/Date linking RfC for the draft of the RfC and discuss its scope and questions at its corresponding discussion page. Opinions on the formatting of such an RfC are welcome here. Dabomb87 ( talk) 23:43, 23 February 2009 (UTC)
I don't see this addressed in the style: commas after dates. In standard written English, this sentence has the comma after the year: "His popularity fell after his arrest on June 12, 1987, became known." Many Wikipedia pages render this incorrectly, leaving out the comma after the year. Should this standard rule be included in the manual on dates and numbers? Is this addressed by any of the bots that fix dates? BlackberryHacks ( talk) —Preceding undated comment was added at 22:00, 10 February 2009 (UTC).
The comma following the year is required because the year is parenthetical. It's required for the same reason that a comma is required in the sentence: I believe that Jack Smith, my brother, is a good man. It's just a different way of writing: His popularity fell after his arrest on June 12 (in the year 1987) became known. By the same reasoning, the year should actually be made parenthetical even when using DMY format, although I've not seen any style guides that recommend that. -- UC_Bill ( talk) 16:35, 12 February 2009 (UTC)
I have recently seen the argument put that the line in #Strong national ties to a topic that says
means that WikiProjects are at liberty to adopt a particular format across the board, irrespective of national ties. For example, WikiProject Hats may adopt a convention of using US-style date formatting for all hat articles.
I think this is a misunderstanding of what was intended here. I believe "customary format" means what people customarily do out there in the real world, not what Wikipedia editors in the subject area customarily do. Can I get a clarification on this point, both here and in the guideline text?
Hesperian 04:52, 7 March 2009 (UTC)
{{
editprotected}}
There was a protected edit request in the
archive from 12 February, which I have just deactivated. Is this edit still needed? If so, please could you provide a clear and succinct instruction here, as there was a huge amount of text in that thread.
Martin
msgj 10:18, 25 February 2009 (UTC)
{{nowrap|299 792 458}}
and {{nowrap|149 014 769}}
in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate" in the "Large numbers" section with {{gaps|299|792|458}}
and {{gaps|149|014|769}}
respectively (the instruction was changed but the examples weren't; this one should be uncontroversial). There is a similar example in the last bullet point of the section "Decimal points", but there is no consensus about the precise wording to use (although there is consensus about what it should say). I'd go with replacing that bullet point with{{
val|0.1234567}}
generates 0.1234567 (with a four-digit group at the end); but due to server-related issues, {{
val}} can reliably handle no more than 12 significant digits. In cases where {{
val}} fails, the template {{
gaps}} can be used, but the position of the gaps has to be specified by hand.The above text (between the rules), replaces the last bullet point in WP:MOSNUM#Decimal points.
Alternatively, the wording I had in my last proposal (also archived) works for me. It is as follows:
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the
significand. For significands greater than this, editors should delimit high-precision values using the {{
gaps}} template; e.g. {{gaps|1.234|567|890|123|45}}
→ 1.23456789012345.{{
editprotected}}
You forgot fixing the examples. As I said above, “Now you should just replace {{nowrap|299 792 458}}
and {{nowrap|149 014 769}}
in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate" in the "Large numbers" section with {{gaps|299|792|458}}
and {{gaps|149|014|769}}
respectively (the instruction was changed but the examples weren't; this one should be uncontroversial).” --
A. di M. (
talk) 16:22, 6 March 2009 (UTC)
← In order not to confuse any admin going to address this: both I and Greg agree that the point above still applies, namely
Now you should just replace
{{nowrap|299 792 458}}
and{{nowrap|149 014 769}}
in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate.
-- A. di M. ( talk) 10:00, 8 March 2009 (UTC)
{{
editprotected}}
Under the heading "Scientific notation, engineering notation, and uncertainty" appears the bullet:
Since a region's measurement would be an area and not a length (and since the unit isn't the error/inconsistency being illustrated!), the first figure should be corrected to 2.23×102 m2. — Taper ( talk) 11:39, 6 March 2009 (UTC)
When writing the phrase "12 billion lightyears", which of the following is the best way to write it:
This issue does not seem to be clearly addressed in the MoS. Regardless of the correct answer, I suggest adding a statement explicitly explaining how to deal with compound numbers. -- Cryptic C62 · Talk 03:00, 28 February 2009 (UTC)
Lorem ipsum dolor sit amet, consectetuer adipiscing
12 billion lightyears sed diam nonummy nibh euismod.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit 12
billion lightyears sed diam nonummy nibh euismod dolore.
I’ve attended to these details in articles I work on. For instance, if it is a date like 8{{nbsp}}May
, I’ll keep such a short expression together. But if it is a longer date, like 27{{nbsp}}September
and it is next to a picture, where it might be in a very narrow column on some users’ 800 × 600 monitor (or worse), I manually drag my window width narrower to see how the word wrap flows in the paragraph and tweak if necessary.
These sort of issues crop up in more significant ways than dates; high-precision numerical equivalencies can be really nasty when word wrapping. For instance 0.45359237 kg appears in Kilogram right next to a picture. The extra two characters comprising kg don’t make it too much worse. Some editors like to keep the numeric value and the fully written-out unit of measure tied together; e.g. 0.45359237 kg. That’s quite a long sting to not allow to word-wrap so I try to use such an expression only very early in a new paragraph, where I am sure it won’t have to word-wrap (or check the word-wrap flow in variable window width). Of course, I don’t horse around with this level of detail on articles that are in a state of flux with many other contributors.
I would say a guideline could be as simple as “If it is just a two or three-digit numeric value next to a written-out named number, make it non-breaking since the extra word-wrap burden of the numeric value is minimal.” Or, alternatively…
Sinc their arr a lot uv edeters out their with a widde vareity of skeels, I woodnt bothre triing to git all of these into a guideline. I think I might just acknowledge that it is an acceptable practice and shouldn’t be reverted when done properly. Greg L ( talk) 04:14, 5 March 2009 (UTC)
• When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either
or{{nbsp}}
between the value and named number (e.g.12{{nbsp}}billion lightyears
). This will improve readability by preventing the expression from breaking at a line-end word-wrap.
<span style="margin-left:2.8em">
)12 billion
lightyears
99 billion
The unit “lightyears” actually takes up more room than both “12 billion” and “99 billion”. There is simply no problem when the practice of attaching digits to these named numbers is limited to two and three-digit numeric values; the combination ain’t that big of a character string. Greg L ( talk) 21:08, 9 March 2009 (UTC)
{{
editprotected}}
Considering we're
currently in arbitration over this, and given the willingness of those involved to continue to cite this fully protected page as if it were not in dispute, I propose adding {{
disputedtag}} with section=yes
(so {{disputedtag|section=yes}}
) to "
Linking and autoformatting of dates". —
Locke Cole •
t •
c 02:44, 8 March 2009 (UTC)
Please Locke; your disruption to Wikipedia, high and low and in every nook and cranny, started getting tedious quite some time ago. Greg L ( talk) 03:53, 8 March 2009 (UTC)
As someone with no stake in the date (de)linking dispute, I am going to disable the editprotected tag. Since there is disagreement about the requested edit, no admin is going to make the change that has been requested. However, I am certain that, even if there is not a "disputed" tag, it is well known that there is disagreement over the issue of date linking. And the protection template at the top of the page is a clear sign to any reader that there is a dispute. — Carl ( CBM · talk) 04:07, 8 March 2009 (UTC)
(*sigh*) Could it be that I recently quote MOSNUM in an ANI? Unable to change what MOSNUM says, you asked, above, to have a {disputed} tag slapped on the text with which you disagree. Someone then quotes “consensus”. WP:Consensus is not locked down so there you go, making edits to WP:Consensus to push a POV that, IMO, is A) self-serving in your crusade on date linking, B) amounted to editing against consensus on WP:Consensus; all of which is C) part of a crusade on an issue—date linking—which past RfCs clearly show the community has no stomach whatsoever for.
Please chill and let the ArbCom on all of this run its course. I know you won’t believe me, but what I say is true: your running around trying to change the foundation principles of Wikipedia’s guidelines and policies won’t feed into and influence the outcome of the ArbCom; if anything, it is the other way around.
As for “bullying”, well… Do you see me running around, insisting upon unwelcome changes to long-standing Wikipedia policy pages? Cow patties.
Greg L (
talk) 17:59, 8 March 2009 (UTC)
{{ editprotected}} Can someone please add the {{ disputed}} tag at the end of the sentence here reading "Dates (years, months, day and month, full dates) should not be linked, unless there is a reason to do so." This is still a matter of dispute, but I'm seeing this cited as an actual standing guideline by editors unfamiliar with the protected nature of the page. -- Kendrick7 talk 05:22, 8 March 2009 (UTC)
I am going to disable the editprotected banner. There is obviously a dispute, but the protection banner already indicates this. I strongly doubt that any admin would edit this page while it is protected to place a disputed tag on it, since it would never be feasible to get agreement about such an edit. — Carl ( CBM · talk) 13:57, 8 March 2009 (UTC)
{{
editprotected}}
The numerically oriented birth and death templates eg: {{
death date and age}}
have a number of problems as discussed last month in
MOSNUM discussions. Due to the needless complexity these older templates introduce, their error prone nature, their inflexibility with date display, as well as their inability to handle Julian dates, I suggest the following change to the guidance regarding their use. The new guidance steers contributors to the templates that accept plain text dates rather than the numeric dates:
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, thegregorian
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.
The current passage may be found in the birth and death dates section. Comments/ improvements? - J JMesserly ( talk) 19:55, 11 March 2009 (UTC)
Personally, I think the birth and death years should be linked for EVERY biography, as history is important and a person's life is lived in context. However, when it comes to articles on "oldest" or "last survivors," the year of birth becomes an imperative part of the story. That Henry Allingham was born in 1896 and is still living beggars the question: how has the world changed in 112+ years? Having a convenient link to the year 1896 makes sense in these cases. Therefore, an exception should be made even if a decision is made to not link birth and death dates. Ryoung122 10:50, 12 March 2009 (UTC)
I'll have to disagree with Ryoung & Anderson here. Trivia about the particular year that a person happens to have been born in has little connexion to a serious biography. By all means link to the century/centuries he lived in but not a particular year. JIMp talk· cont 18:49, 12 March 2009 (UTC)
All kinds of interesting things happened in 1896, such as the first modern Olympic Games, the 40-minute Anglo-Zanzibar War and a pivotal (realigning) U.S. Presidential Election. Whether they (or equally-important but completely-apolitical events) are properly featured is a matter of editing 1896. ¶ But that's really not the point, the editors working on Henry Allingham's article are those who should discuss and decide whether that particular article is interesting enough or relevant enough to their article to merit a link. Trying to establish a single policy in such matters for two million articles is far worse than madness. —— Shakescene ( talk) 22:03, 12 March 2009 (UTC)
This matter will be addressed in depth in an Arbcom-spawned RfC, I suggest that users direct opinions and input about the RfC here. Dabomb87 ( talk)
A while back I saw a discussion where many editors voiced opposition to any form of date autoformatting that caused registered users to see different content from unregistered users. Does anyone else remember this? Where is this discussion archived?
I'm wondering because there's now a proposal to open a new can of worms by creating a "formatdate" function that does exactly the same date autoformatting that was rejected before, just without the brackets. — Remember the dot ( talk) 01:10, 17 March 2009 (UTC)
Please add the shortcut WP:COMPUNITS for the discussion of how to represent binary/decimal values. Ham Pastrami ( talk) 03:11, 17 March 2009 (UTC)
It seems that cool heads, peace, and civility has broken out—completely unchecked—all over the place on the ArbCom and its related subpages. I have this proposal: Why not unlock MOSNUM with the proviso that anything related to date formats, autoformatting, and date linking be left alone. Greg L ( talk) 04:40, 17 March 2009 (UTC)
P.S. After MOSNUM is unlocked, maybe we might see that everyone standing around on Wikipedian street corners will have a confused, blank look, and say to their neighbor “Instead of running for our AK‑47s, wanna play a game of checkers or something?” Greg L ( talk) 04:47, 17 March 2009 (UTC)
Unlocking MOSNUM will help everyone settle into a feeling of normalcy, which has been sorely lacking for a while. Greg L ( talk) 03:34, 18 March 2009 (UTC)
Hallelujah. (I had proposed this on 15 February, but it was ignored.) -- A. di M. ( talk) 16:37, 20 March 2009 (UTC)
As previously discussed ( archive), would anyone object to my adding this as the fourth bullet point here on MOSNUM:
• When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either
or{{nbsp}}
between the value and named number (e.g.12{{nbsp}}billion lightyears
). This will improve readability by preventing the expression from breaking at a line-end word-wrap.
Greg L ( talk) 22:06, 19 March 2009 (UTC)
• When expressing large approximate numbers, it is preferable to write numbers in words, or partly in figures and part in words, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but It grossed $28,106,731 on its opening day (the exact number). When both a figure and a word are used in the same number, it is useful to use a non-breaking space, as in
128 million
, to prevent a line break from occurring between them.
(outdent)
I took the initiative and looked at the existing verbiage. I’ve revised the key nouns to be harmonious with adjacent text and added the following:
• When expressing large approximate quantities, it is preferable to write them spelled out, or partly in figures and part as a spelled‑out named number, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but The movie grossed $28,106,731 on its opening day (the exact quantity).
• When both a figure and spelled-out named number are used in a quantity, it is useful to use a non-breaking space, as in
128 million
or128{{nbsp}}million
to prevent a line break from occurring between them.
Be my guest to tweak and revise to your heart’s content; I’m not stuck on anything—just the basics here. Greg L ( talk) 04:31, 21 March 2009 (UTC)
An aside on browsers. Many of us have tweaked the appearance of our code with thinspaces and whatnot to make rendered pages appear better. This is just a reminder that if something doesn’t look quite right and you are using Internet Explorer 8, that it would be a good idea to try other browsers too. According to ChannelWeb, IE 8 rates a 20 out of 100 on The Web Standards Project’s Acid3 Browser Test, which “is the third in a series of test pages written to help browser vendors ensure proper support for web standards in their products.”
The ChannelWeb article mentioned also that “Apple's Safari 4 browser scores 100 on Acid 3”. Whereas Safari is only third in market share, with nearly 11% of Web activity, it will show you how pages are supposed to look. Greg L ( talk) 21:25, 21 March 2009 (UTC)
Many writers have converted the years under Buddhist Era (BE) to Christian Era (AD) in an incorrect way for they left one exception behind.
We should take notice that:
Article 3 is an exception usually left behind by many people, and this led to a great problem about inaccuracy of year counting or conversion in many Wikipedia articles as to Thailand, Thai persons, Thai stuffs, Buddhist stuffs and any others in connection with the said.
Therefore, I suggest us to lay down a project to check and rectify the said mistakes. I cannot say how to carry out the project, but I can say that checking whether this one is a correctly-converted year or not would be much difficult and we need to seek Thai Wikipedia for cooperation. Thai Wikipedia is also meeting with the same problem as us. —— PORtrait | chit~chat - 24 March BE 2552 (2009), 03:17 hours (GMT+7)
The above link leads to a community poll regarding date linking on Wikipedia. The poll has not yet opened, but the community is invited to review the format and make suggestions/comments on the talk page. We need as many neutral comments as we can get so the poll runs as smoothly as possible and is able to give a good idea of the communities expectations regarding date linking on the project. Ryan PostlethwaiteSee the mess I've created or let's have banter 19:43, 21 March 2009 (UTC)
Is there any standing on the abbreviation of months in an article? Is abbreviation ever acceptable? In what cases can they be accepted? or can not? Is it known as unacceptable in infoboxes? FireCrystal ( talk) 16:59, 27 March 2009 (UTC)
I don't think kcal is kilogram calorie but kilocalorie, which is different. -- SLi ( talk) 18:05, 24 March 2009 (UTC)
RockyMtnGuy exaggerates the case against using a hyphen. The source he(?) uses has this to say in another section:
9.4 Spelling unit names obtained by multiplication
When the name of a derived unit formed from other units by multiplication is spelled out, a space, which is preferred by Ref. [6] and this Guide, or a hyphen is used to separate the names of the individual units.
Example: pascal second or pascal-second
-- Jc3s5h ( talk) 17:49, 27 March 2009 (UTC)
I went ahead and removed the example. If no-one objects, I'm going to mention that spaces can also be used. -- A. di M. ( talk) 20:17, 27 March 2009 (UTC)
Hi. What do you do with articles that only use Islamic dating (A.H. - After Hejira) for reference in the English-speaking Wikipedia? Do we leave the dates alone? It renders the article essentially useless for English-speaking individuals accustomed to western ( Gregorian calendar) dating traditions. I can accept there being co-dating with Islamic dating along side Gregorian dates as it provides us with more information - although I don't know what Wikipedia's policy is for it - but it seems self-defeating (from an information perspective) to leave articles such as this, uncorrected. Is there a Tag/template located somewhere that we can post, urging the article to be converted to Gregorian dates and/or that any new dates be entered using Gregorian calendar dating? In particular, many of the scientific and scholarly Arabs do not have Gregorian dates assigned to their articles but instead use A.H. dating, such as Al-Juwayni... Stevenmitchell ( talk) 04:52, 29 March 2009 (UTC)
The date linking and formatting poll is now open. All users are invited to participate. Ryan PostlethwaiteSee the mess I've created or let's have banter 23:00, 29 March 2009 (UTC)
I've gotten a positive response at WT:MOS#Which is it (i.e.)? to my request to stop monthly updates of the WP:MOS page for the 4 reasons I gave there. This is the only other page that, conceivably, all 4 reasons apply to; it's too soon to tell. I'll ask for opinions at the end of the month. - Dan Dank55 ( push to talk) 22:42, 20 March 2009 (UTC)
What is the correct format to use if you know the range of years within which a person died? The problem occurs in Adam de Stratton, who was alive in 1292, but dead by 1294. Using a dash seems a bit silly, as if he spent two years dying. Some publications use an "x", as in 1292x94. Lampman ( talk) 19:09, 1 April 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.
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)
a 10-kilogram (22 pound) bag of potatoes and a 5-kg (11 lb) bag of carrots
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)
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)
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)
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)
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 [15] and the other can be found at [16]. 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)