![]() | 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 130 | ← | Archive 133 | Archive 134 | Archive 135 | Archive 136 | Archive 137 | → | Archive 140 |
Colleagues, I've never been completely confident about the decimal-point consistency thing. I've raised it here. In particular, this one foxes me: "whose height varies between 4 and 12 cm (1.6 and 4.7 in), and which is typically between 1 and 1.5 cm (0.4 and 0.6 in) thick". Your advice? Tony (talk) 07:49, 8 July 2011 (UTC)
WP:SEASON was used here to justify uncapitalizing "Northern Hemisphere". So should we fix it? Art LaPella ( talk) 19:45, 10 July 2011 (UTC)
I know we discussed year ranges, but what about page ranges and such? Do we drop digits, or not? Dicklyon ( talk) 04:10, 11 July 2011 (UTC)
I have recently been made aware of some ambiguity in date formatting. Last night I ran across a proposal to make changes to the MOS on date formatting, but it did not appear to pass for lack of consensus. I have searched through the archives, but I cannot find any references to this question below. Maybe I did not search well enough, or maybe it is not there. I presume there are likely a number of editors who are passionate about this topic and can point directly to the thread.
In the section for MOS:DATEUNIFY we have the section:
- Access and archive dates in references should be in either the reference format, or YYYY-MM-DD
- In the same article, do
- Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009.
- or
- Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05.
- or
- Jones, J. (September 20, 2008) ... Retrieved 2009-02-05.
- but not
- Jones, J. (20 Sep 2008) ... Retrieved February 5, 2009.
Here are the points I think need some clarification:
By looking at the prior MOSNUM debate linked above, I assume I will get a flood of replies to this question that says we cannot improve Wikipedia by making a decision on this topic. That is unfortunate for the readers. § Music Sorter § ( talk) 08:50, 11 July 2011 (UTC)
Also, I am one of a small handful of editors who work to keep date formats consistent within articles and across some article categories. This job is too tedious to perform manually on the scale that is required to ensure orderliness. Our task is rendered complicated by not stipulating the uniformity of dates in refs section (exceptions I noted aside). The consequence is that those of us who maintain dates either avoid aligning dates (in refs section) due to the complexity, or run the risk of complaints from those who want to see yyyy-mm-dd formats retained but do not ensure that articles 'under their wing' are compliant, the mix of many dates in reference sections will proliferate due to organic nature of growth of articles. I do not recall hearing any cogent argument why we must restrict yyyy-mm-dd dates to the 'accessdate' parameter (and not apply to the 'date' parameter within citations as well). If the oft-cited desire for "conciseness" is a true desire, allowing yyyy-mm-dd dates to be used uniformly throughout reference sections ought to be the standard. It isn't. Given that it is only a small handful of editors who care about date consistency and an equally small number in favour of retaining yyyy-mm-dd formats for access dates, it seems mighty unfair and tedious to have to bash it out on each article where the two groups of contributors would meet. It is a matter that needs to be more strictly defined and determined at MOS level. -- Ohconfucius ¡digame! 02:13, 12 July 2011 (UTC)
Just wanted to let all of you know that I've deleted Wikipedia:Manual of Style/(dates and numbers)/Eras - Archive2 (created in 2005), because the creator blanked it just two minutes after creation, and since that time it's never had any content except deletion templates and a category. There's significant content on the talk page, so I didn't delete that. I don't know how this page's archiving is normally done, so I just wanted to make sure that people who do know were aware of this situation. Nyttend ( talk) 13:04, 11 July 2011 (UTC)
There's been discussion about the conversion of acres (again), and I appears that there's no easy solution. I do believe editors need more detail in the guidelines about whether to convert to hectares or square metres or what. I have no idea what the solution is, but I find this, from Symphony Park very reader-unfriendly—both the originals and the conversions. Can't the rat of zeros be avoided? And can't we identify areas in which the ability of readers to visualise the quantities suggests how to express them?
“ | The $6 billion project is projected to include 11,000,000 sq ft (1,000,000 m2) of space on 61 acres. Plans call for 1,908,000 sq ft (177,300 m2) of office and medical space, 5,200,000 sq ft (480,000 m2) comprising 3,200 residential units, 3 hotels providing and estimated 1,800 to 2,300 rooms in 1,575,000 sq ft (146,300 m2) of space with 475,000 sq ft (44,100 m2) of retail. The area is also expected to include 60,000–100,000 sq ft (5,600–9,300 m2) of casino space. | ” |
Your input would be appreciated. Tony (talk) 10:12, 12 July 2011 (UTC)
Acres: a brief search found these examples. WP's treatment of acres looks like a real mess. I'm so glad I don't write articles that involve such areas. I wouldn't know where to go for guidance.
almost one billion acres, approximately 4,046,856 km2 (1,562,500 sq mi)
I don't believe the guideline is very clear... is it best to use the notation BC/BCE for both years in a span contained before the Christian Era (i.e. 20 BC – 10 BC), or just after the latter year (i.e. 20 – 10 BCE)? I ask this because I am coming across several articles across the main article space that use either or, and it could be confusing for readers. Especially if they aren't aware that BC years count backward as time moves forward. Thoughts? Should we decide on and clarify this?. — CIS ( talk | stalk) 03:16, 17 July 2011 (UTC)
Is there any reason this page doesn't mention {{ date}}? This can be used to automatically format dates like the old system but doesn't link them. We ought to think about when it should or shouldn't be used.-- Doug.( talk • contribs) 23:25, 15 July 2011 (UTC)
Feb. 14, 1987, was the target date.
Transclusions: The template isn't used often. It only looks like that because it's embedded in several templates. Lightmouse ( talk) 10:18, 18 July 2011 (UTC)
'Template:Infobox poker player' appears to be responsible for 60% of the transclusions. The date template was embedded in 2009. Its only function is to accept '2011-07-07' or '7 July 2011' in edit mode to get '7 July 2011' in read mode. Lightmouse ( talk) 12:47, 18 July 2011 (UTC)
If I understand this date template correctly, it is an abortion that should never have been made. It only affects how the dates appear for A) registered editors, B) who change their date preferences from “No preference.” Well over 99% of our readership will just see a default format (18 July). The use of this template just allows registered editors (those responsible for ensuring text is consistent and appropriate) from seeing that there might be a hodge-podge of different date formats in an article because the template effectively says “Here crybaby, we won’t darken your doorstep with a date format you don’t like to be exposed to.” My recommendation is to discourage use of the {date} format and for all editors who actually care about what our readership is seeing to set their date preferences to “No preference.”
Greg L (
talk)
15:40, 18 July 2011 (UTC)
OK, Experiment time. This date: July 18, 2011 was coded as {{date|2011-07-18|mdy}}
. Let me try this… (one moment, I’m in “Show preview” mode)…
With “No preference” in my date preferences, I see “July 18, 2011”. With my prefs set to “20:33, 18 July 2011”, I see the same thing. So…
Why would someone want to learn to use this template? What good is it? If I wanted a date to read July 18, 2011, why would I type {{date|2011-07-18|mdy}}
?? Someone explain this to me, please.
Greg L (
talk)
20:38, 18 July 2011 (UTC)
P.S. Apparently, it has utility somewhere in obscure practices with dates in highly structured sections, such as tables and other templates. I agree with Doug; it doesn’t need to be mentioned here.
Greg L (
talk)
20:48, 18 July 2011 (UTC)
The majority of cases are not useful. For an example of trivial use, see: 'Template:Infobox poker player'. If it has non-trivial uses, that's fine but trivial uses should be removed to simplify things for readers. Lightmouse ( talk) 12:26, 19 July 2011 (UTC)
The guidance says:
and
These appear to contradict each other. What should it say? Lightmouse ( talk) 18:55, 17 July 2011 (UTC)
Ah yes. I see now. I'll delete the first phrase as a contradiction. For the second phrase in 'Specific units' I propose changing:
Does that make the meaning clearer? Lightmouse ( talk) 19:25, 17 July 2011 (UTC)
A fair point. We have two issues:
Lightmouse ( talk) 13:30, 18 July 2011 (UTC)
Seems to be a solution looking for a problem. The only commonly used derived units are µL, mL, and L. Centiliters seem to be more common in Europe. Larger volumes are given in liters or cubic meters. -- Rifleman 82 ( talk) 05:51, 19 July 2011 (UTC)
Oppose - The current Wikipedia guidance is a rahash of the SI brouchure. In the United Kingdom millilitres are usually written "ml" rather than "mL" (at any rate the items in my fridge and store cupboard). I agree with User:Woodstone that we should not deviate from the SI Brochure unless there is good cause.
Martinvl ( talk) 06:38, 19 July 2011 (UTC)
Comment I prefer the lower-case versions and would oppose banning them. I just would want to see "ml" alongside "L". Woodstone raises a good point that the "1" wouldn't appear in the same position. JIMp talk· cont 07:40, 19 July 2011 (UTC)
Stop voting. Nobody has presented proposed text to change the intent of the guidance. This thread is only about whether we need to eliminate a contradiction and failure of clarity in *existing* guidance. User:Jc3s5h suggested changing the intent of the guidance but before a vote, please take it to another thread. In the meantime, I'll update the *existing guidance* to make clarify (as far as I can) the *existing intent*. 10:25, 19 July 2011 (UTC)
The guideline exemplifies the preferred abbreviation in roman face, c., although italicises the spellings-out. I've often wondered which is correct for the single-letter abbreviation. A recently promoted article, Deusdedit of Canterbury, has the italics. Tony (talk) 10:18, 10 July 2011 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
please change AD and BC to a more accurate scientific dating system
Jojotruth1 ( talk) 17:36, 20 July 2011 (UTC)
I think we've now resolved contradiction and clarity problems with current guidance on litre. Several people wanted to discuss changes in guidance. The following table summarises what I think people meant:
Permit 'l' without prefix | Permit mix of 'L' and 'ml' in article | Supporters | Comment |
---|---|---|---|
No | No | Jimp, Jc3s5h | |
No | Yes | Current guidance | |
Follow guidance in BIPM SI brochure | Woodstone Martinvl |
SI guidance |
If I've misunderstood, please make the appropriate changes. Lightmouse ( talk) 15:14, 19 July 2011 (UTC)
Interesting, thanks. Does the mosnum guidance over and above the SI brochure have any effect? Guidance that has no effect is probably a waste. Lightmouse ( talk) 14:26, 20 July 2011 (UTC)
Yes, I agree. WP mosnum repeats, contradicts, and goes beyond SI as we choose. I was merely suggesting that we look critically at the value of each repetition.
Forgive me for not understanding you. I agree with you that we can and should choose to repeat some of SI. We just need to ensure repetition adds value. Lightmouse ( talk) 16:44, 20 July 2011 (UTC)
Ah. I seem to remember seeing "ℓ" mentioned somewhere before. But I don't think I've ever encountered it in Wikipedia. Forgive me for not following you, can we take it step by step. Are you saying mosnum should have guidance on "ℓ"? Lightmouse ( talk) 20:58, 20 July 2011 (UTC)
Your wish appears to be granted. Mosnum says:
Table 6 of the SI brochure says:
The only remaining issue is whether there's a problem in WIkipedia that needs mosnum to say more than SI. User:Woodstone and User:Martinvl are happy with a one-to-one match between mosnum and SI guidance. If you are too, then so am I. Lightmouse ( talk) 09:43, 22 July 2011 (UTC)
I sympathise with your first choice but agree it's unlikely to succeed. Your second choice means keeping the 'Name' and 'Comment' columns the same and changing the 'Symbol' column to:
I'm ok with that. Lightmouse ( talk) 15:25, 22 July 2011 (UTC)
How about, instead of just allowing either notation in any given article, we take one of each and make it the standard. Most who complain about BC/AD being offensive cite the "Year of Our Lord" in AD, and most who complain about BCE/CE cite the 3 digits found in "BCE".
How about we make the new standard BC and CE? We will use "BC" all throughout Wikipedia for years before Year One, and we will use "CE" all throughout Wikipedia for years from 1 onward. For example, the contentious Jesus article would read, under this new Wikipedia system:
"Jesus of Nazareth, Yeshua in Hebrew or Aramaic (7-2 BC — 30-36 CE)"
Well, why not? I know that BC and CE are rarely paired in external sources, but why can't Wikipedia make a compromise to be as neutral as possible without also being as frustrating as possible by allowing both and having edit wars and reversions constantly? What's bad about this idea? Thoughts?. — Steven Evens ( contribs) 02:52, 22 July 2011 (UTC)
It is common for many publications to use BCE/CE when trying to be politically correct and trip all over oneself to be as inoffensive as possible. However, I’ve yet to hear narrators on TV and film documentaries (like on Egyptian pyramids) use this new terminology; instead, they stick to the “BC” and “AD” forms. I assume this is because the customary terms are less distracting in audible form because saying “This pyramid was thought to have been built in 2500 bee see eee” would leave the viewer in “WTF-land” for 15 seconds.
At risk of ticking off some of the 16-year-old wikipedians who might be looking in on this and who are all smitten with how wise and knowledgeable they have become in only two short years and who are trying to change the world; and in order to make peace on this issue using actual policy that underlies important principals of Wikipedia, I am all for just following the RSs for each particular article. For those articles where there is no guidance by the RSs, or the usage is mixed or unclear by the RSs, my personal preference is to use the BC/AD since I believe it least draws attention to itself for those who hear the words in their heads as they read. This philosophy comes from Technical Writing 101, which states that Thou shalt not use a writing style that draws undo attention to itself for the target readership.
But, since the above might make too much sense and deprive people of their God-given entitlement to wikidrama, I suspect the best thing to do here on this issue is the standard solution for deadlocks: “Do whatever ya’ want.” Greg L ( talk) 16:29, 27 July 2011 (UTC)
I noticed that few of the “regulars” of this page are signed up as members of WP:MEASURE. Have you ever considered joining it? It's not terribly active at the moment, but that might be because it has so few members. ― A. di M. plé dréachtaí 21:36, 3 August 2011 (UTC)
GiBberish in articles I care about infuriates me: Almost anything remotely related to the
octet variant of the
byte known as B
requires a binary interpretation, e.g., calculations with
sectors might use sector size 512, 2048, or 4096, but certainly never the 1000 to justify say
TiB. Please avoid marketing
GiBberish trying to sell less than 4,000,000,000 bytes as 4
GB.
ISO produces mainly non-free standards and is indirectly (via national bodies) dominated by the industry, not by consumers (incl. Wikipedia readers) or experts (incl. Wikipedia editors). –
89.204.153.166 (
talk)
10:22, 3 August 2011 (UTC)
There is a section called 'Unnecessary vagueness'. I think guidance can sometimes
That section doesn't appear to do any of the above. It seems to be just like saying 'use common sense', 'make appropriate edits', 'consult editors if there's a dispute' etc. I suspect the answer will be 'nothing' but what would happen if that section were deleted? Lightmouse ( talk) 11:11, 4 August 2011 (UTC)
I've not read through MOSNUM for some time. How did the units of measurement section get into such a mess? I can't understand most of it. Just how it's useful for editors is beyond me. Tony (talk) 13:02, 3 August 2011 (UTC)
I noticed [1], which would have changed the guidance. Past discussions resulted in saying it was acceptable to have publication date format differing from accessdate format - or, said a different way, that there was no consensus to forbid it. I clarified this based on the examples. However, the phrasing would still restrict a form that exists in articles - yyyy-mm-dd for the publication date, and ymd or dmy for accessdate. I've rephrased again, but I can see this being more disputed, so I'm drawing attention here: [2] Gimmetoo ( talk) 14:53, 5 August 2011 (UTC)
-- Ohconfucius ¡digame! 15:37, 6 August 2011 (UTC)
We have two templates: 'height' and convert. Although they are written differently, they have overlapping capabilities. Each has its own discussion page but there isn't a forum for discussion relating to the overlap. If the output is the same, when should an article use one rather than the other? Lightmouse ( talk) 10:56, 19 July 2011 (UTC)
{{height|ft=6|in=2}}
with {{convert|6|ft|2|in|m|2|abbr=on}}
. Which is why I was disappointed when Lightbot started going round infoboxes changing {{height}} to its {{convert}} equivalent, but assumed this would have been discussed somewhere...precision=0
parameter to usages of {{height}} where the default precision had produced half-inches in the output (displayed as a vulgar fraction). If there actually is agreement that nowadays people's heights are generally measured to the nearest whole inch, then it's fair enough to display at that precision as the result of a conversion from metric. But maybe this should be implemented by changing the output default at the template itself, rather than by complicating matters with the added precision parameter. cheers,
Struway2 (
talk)
12:57, 19 July 2011 (UTC)As far as I can tell, the following is true:
Height template | Convert template | Comment |
---|---|---|
{{height|ft=5|in=6}} 5 ft 6 in (1.68 m) |
{{convert|5|ft|6|in|2|abbr=on}} 5 ft 6 in (1.68 m) |
Identical. Height template actually uses the convert template |
{{height|m=1.68|precision=0}} 1.68 m (5 ft 6 in) |
{{convert|1.68|m|0|abbr=on}} 1.68 m (5 ft 6 in) |
Identical. |
What are the reasons for choosing one template over another? Lightmouse ( talk) 17:28, 23 July 2011 (UTC)
We have guidance that says:
Some units are neither common nor uncommon. They're in a middle commonality zone (e.g. nautical mile) where a link isn't required if a conversion is present. Can anyone suggest appropriate wording? Lightmouse ( talk) 11:56, 27 July 2011 (UTC)
How about adding an additional bullet:
Would that work? Lightmouse ( talk) 11:14, 31 July 2011 (UTC)
Aha! I'm not the only editor that missed conversions being mentioned in the footnote. I don't care where the discussion takes place but I brought it here because I thought it was a matter for units of measurement people. The issue is that the threshold is different inside a conversion. I think source and target are covered by the phrase but I'd welcome alternative suggestions. Lightmouse ( talk) 12:04, 31 July 2011 (UTC)
A good point. It would be a *lot* simpler to have a list of:
Widespread (aka 'common') units shouldn't be linked, less widespread but still-well-known units shouldn't be linked when in conversions. These two lists could be generated from a subset of the units in US NIST document. This would end frequent debates about whether <unit> should or should not be linked inside and outside a conversion. Lightmouse ( talk) 19:06, 2 August 2011 (UTC)
To A. di M.: Which of these U.S. Customary units of measure are drop-dead obvious to most non-U.S. English-speaking readers to the extent that virtually no non-U.S. reader would ever bother to click it if it were linked(?):
Let me know of your thoughts. Off the top of my head, the only SI unit of measure that is so exceedingly familiar that very few American readers would click a link is the liter, which is pretty common in grocery stores. Other than that one, I just can’t think of other units from the SI that should generally be considered as drop-dead obvious for many Americans (particularly older ones), including the kilogram and meter. Note that some of the above-listed units are already SI (but are essentially part of U.S. Customary) or are accepted for use with the SI; namely, the volt, degree of angle, and units of date and time. Greg L ( talk) 21:26, 2 August 2011 (UTC)
Certainly link the truely obscure units so as to help understanding but we should avoid cluttering the place up with links to articles with very little relevance to the topic at hand. If you're suggesting that a significant number of Americans would find such units as the kilometre, metre, centimetre, millimetre, square metre, square kilometre, kilogram, gram and kilometre per hour obsure, I'd find that quite surprising (inspite of how the rest of us like poking fun at supposed American ignorance). Sure, such units as the tonne, hectare, newton, kilojoule and degree Celsius might be a little obscure to many Americans, as would be their US customary/imperial counterparts to most of us metricated folk. However, I'd suggest that even these are not yet approaching that grey area Lightmouse refers to, they're still only more-or-less off-white. The thing is that we have, to reverse the section title, conversions instead of links. An American (even an ignorant one, assuming they're at least literate) is going to read "20 hectares (49 acres)" and think something along the lines of "oh yeah, a hectare is an area unit" and, if they care enough, could easily figure out "... about 2+1⁄2 acres"; just as a metric-minded fellow (yes, we can be ignorant too) will read "20 pounds-force (89 N)" and think something like "right, a pound force is a unit of force ..." and, again, after a little mental maths, "... about 4+1⁄2 newtons". If it bugs them enough, let them copy and paste it into the search box. No, that grey area is occupied by such units as the micrometre, the parsec, the pascal, the troy ounce, the bushel, the oil barrel, the nautical mile, etc. but it still depends on context. The knot in an article about a certain boat should not be considered obscure nor should the picometre be in an article about a certain molecule. There may even be contexts in which such relatively obscure units as fathoms, furlongs, firkins or femtometres need not be linked. JIMp talk· cont 05:17, 3 August 2011 (UTC)
Greg ask Tony if a principle should be:
If that's fine with Tony and Greg, it's fine with me as a principle. Although it's worth mentioning explicitly that a converted unit is less in need of a link than an unconverted one.
Greg suggested the following units wouldn't need linking for US readers:
It might help to say:
I agree that those few units shouldn't be linked. But like Jimp, I'm surprised the list isn't longer. Anyway, even just that would be an improvement over the current guidance. Lightmouse ( talk) 14:57, 3 August 2011 (UTC)
I think there is an over-abundance of left-brained males represented in this venue. I can tell you that if WT:MOSNUM had an ocean of right-brained *wife-types* (verbal and reading skills, not so much insofar as spatial reasoning) participating here, we would receive earnest advise that calculating how many cubic yards or cubic meters of beauty bark to order from a landscaper is not a universal skill and the nature of the measure is not as intuitive as some here seem to assume. Greg L ( talk) 22:46, 4 August 2011 (UTC)
Sorry but you are going to have to simplify that for the layman. What on earth does "they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on." mean? Keith D ( talk) 19:07, 3 August 2011 (UTC)
Quantity | US | UK and some∗ of the Commonwealth | Most of the rest of the world |
---|---|---|---|
Length | inch, foot, yard, mile | inch, foot, yard, mile | millimetre, centimetre, metre, kilometre |
Mass | ounce, pound, short ton | ounce, pound, stone, long ton | gram, kilogram, tonne (AKA “metric ton” in the US) |
Time | second, minute, hour, day, week, month, year, decade, century, millennium | same as the US + fortnight | same as the US |
Speed | mile per hour | mile per hour | kilometre per hour |
Temperature | °F | °C | °C |
Currency | US dollar | pound sterling | euro |
Angle | degree, full turn (and simple fractions thereof) | degree, full turn (and simple fractions thereof) | degree, full turn (and simple fractions thereof) |
Power | watt, kilowatt | watt, kilowatt | watt, kilowatt |
Energy | kilowatt-hour, calorie† | kilowatt-hour, calorie† | kilowatt-hour, calorie† |
Voltage | volt | volt | volt |
Volume | US fluid ounce, pint, quart, gallon, litre | imperial fluid ounce, pint, quart, gallon, litre | millilitre, centilitre |
Frequency | megahertz, gigahertz | megahertz, gigahertz | megahertz, gigahertz |
Information | bit, byte, kilobyte, megabyte, gigabyte, terabyte‡ | (same) | (same) |
Am I missing some/including some I shouldn't? My conjecture is that iff a quantity is shown in a set of units such that each cell of the relevant row of this table is represented, then the fraction of readers of en.wiki who would not understand the quantity is negligible. ― A. di M. plé dréachtaí 13:15, 5 August 2011 (UTC)
Can we take some examples *within conversions*:
Do any of those need a link? Lightmouse ( talk) 17:00, 5 August 2011 (UTC)
User:AdiM's table is a good start. However, we still have the problem that some editors assert that units in the 'other system' are obscure and need linking. Can anyone propose guidance text that explains that although '9 millimetres' may be deemed obscure to Americans, it doesn't qualify for a link when in a conversion with the not-obscure '0.35 inches'? Lightmouse ( talk) 17:54, 6 August 2011 (UTC)
As I understand it, Greg was saying km and kg are obscure and require linking. If that's not the case, then I'm fine with that. Following your encouragement and updated Wikipedia:Manual of Style (linking) so the advice that conversions are relevant isn't in a footnote. I've also added a table inspired by yours. If it needs amending, please go ahead. Lightmouse ( talk) 20:27, 6 August 2011 (UTC)
This looks like a nice beginning of a list but I'd say that there are more units to include. Also should the list be context dependant?
A problem with a list of "non-obscure units" is that it might seem to imply that whatever is not on the list is obscure and thus encourage overlinking rather than discourage it. There are so many units out there which are well enough known not to be linked (esp when there a conversion). Is this list the tip of a very big iceberg? ... miles per gallon, litres per 100 kilometres, cubic centimetre, mm of Hg, psi, pascal, foot pound, newton metre, calorie per ounce, kilojoule per gram, tonne of TNT, nauticle mile, hectare, light-year, pixel, megapixel, oil barrel, yen, Aussie dollar, German mark, teaspoon, cup, ... JIMp talk· cont 11:20, 7 August 2011 (UTC)
A link is much less justified *within a conversion*. Above, Jimp highlighted two legitimate concerns:
There is no need to list <not-obscure unit> divided by <not-obscure unit> or <not-obscure unit> squared. The benefit of a list of specific units is that it documents consensus of what the guidance actually means. Please note the 80-20 rule, most of the overlinking problem (say 80%) is due to a few units (say 20%). The 12-row table that User:AdiM proposed would address the majority of the problem.
I'd be fine with that of somebody else's table but for the record, here is mine:
Quantity | Not obscure in US | Not obscure in UK | Not obscure in rest of world |
---|---|---|---|
Length, area, volume | Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes. | Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes. | |
Length, area, volume | Inch, foot, yard, mile. Plus square yard (based on comments by User:GregL but other editors suggest square foot may also be not-obscure to Americans) | Inch, foot, yard, mile. Plus squares and cubes | |
Length, area, volume | Litre | Litre. Plus prefixes milli, centi, kilo, mega, giga. | Litre. Plus prefixes milli, centi, kilo, mega, giga. |
Length, area, volume | US fluid ounce, pint, quart, gallon | imperial fluid ounce, pint, quart, gallon | |
Mass | Gram. Plus prefixes milli, centi, kilo, mega, giga. | Gram. Plus prefixes milli, centi, kilo, mega, giga. | |
Mass | Ounce, pound, short ton | Ounce, pound, stone, tonne | tonne |
Time | Second, minute, hour, day, week, month, year, decade, century, millennium | second, minute, hour, day, week, fortnight, month, year, decade, century, millennium | second, minute, hour, day, week, month, year, decade, century, millennium |
Speed | Mile per hour | <not-obscure unit of length> divided by time | <not-obscure unit of length> divided by time |
Temperature | °F | °C | °C |
Power | Watt, Plus prefix kilo | Watt Plus prefixes milli, centi, kilo, mega, giga. | Watt. Plus prefixes milli, centi, kilo, mega, giga. |
Power | Horsepower | ||
Energy | Kilowatt hour | <not-obscure unit of power> |
<not-obscure unit of power> |
Energy | Calorie. | Calorie. | Calorie. |
Voltage | Volt | Volt. Plus prefixes milli, centi, kilo, mega, giga. | Volt Plus prefixes milli, centi, kilo, mega, giga. |
Frequency | Hertz. Plus prefixes milli, centi, kilo, mega, giga. | Hertz. Plus prefixes milli, centi, kilo, mega, giga. | Hertz. Plus prefixes milli, centi, kilo, mega, giga. |
Information | Bit. Plus prefixes milli, centi, kilo, mega, giga. | Bit. Plus prefixes milli, centi, kilo, mega, giga. | Bit. Plus prefixes milli, centi, kilo, mega, giga. |
Information | Byte. Plus prefixes milli, centi, kilo, mega, giga. | Byte. Plus prefixes milli, centi, kilo, mega, giga. | Byte. Plus prefixes milli, centi, kilo, mega, giga. |
Others | <not-obscure unit> divided by <not-obscure unit> | <not-obscure unit> divided by <not-obscure unit> |
In response to "Can you provide an example division using units from the table that you think requires linking?", some kind of explanation of "kilowatt per year" would be required if we used in the same sense as this PDF. (I'm not sure if that usage makes sense or not, but if it does an explanation is required). The explanation could be in the form of a link, although no "Kilowatt per year" article exists yet. Jc3s5h ( talk) 11:19, 8 August 2011 (UTC)
A good point. You may remember a recent discussion about 'BTU' versus 'BTU/h' ( here and here). I think it's the same issue. Lightmouse ( talk) 12:43, 8 August 2011 (UTC)
Here we are deliberating as to what is to be considered obscure and what is not. Firstly all units which belong to the other system are obscure (the other system is an instrument of the Devil created to cause disharmony on Earth, but we have to put up with it on WP bacuse we can't find any reliable source to back this up ... or even to prove that the Devil exists). Feet are obscure to us, metres are obscure to them, but this is okay since we have conversions. The question is what's obscure to all of us. It depends on context. Now, suppose we have a unit which, in the particluar context, could be considered obscure. Now suppose this said unit has nothing in particular to do with the topic at hand. I must wonder what such a unit would be doing there at all.
Linking days of the week, dates, months, years, we're over it ... unless it has to do with the topic at hand. Linking countries ... we're over this too ... right ... unless it has to do with the topic at hand. What about applying the same rule to units? Obscurity, forget about it; is the unit relevant to the topic? Regardless of how obscure or well known the unit may or be, link it iff it is germane. Even non-obscure units should be linked when they relate to the context. JIMp talk· cont 00:15, 8 August 2011 (UTC)
The template {{
times}} is now available, to display a typographically correct 'times' character (×
in HTML); for eample 4{{times}}100m relay
renders as 4×100m relay.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits
20:11, 6 August 2011 (UTC)
2 × 2
" is easier to read than either "2 {{times}} 2
" or "2 × 2
".
JIMp
talk·
cont
02:12, 9 August 2011 (UTC)
{{times}}
than hit Tab umteen times but are mouseless users (who can't manage ×
either) that significant a group of people that we need this?
JIMp
talk·
cont
10:28, 10 August 2011 (UTC)
×
but can {{times}}
even non-empty? ―
A. di M.
plé
dréachtaí
00:30, 12 August 2011 (UTC)
I have observed a number of editors convert date ranges in the form "1990 to 1991" to 1990–1991, claiming that WP:DATESNO requires that all date ranges use an endash. Specifically, the form "1990 to 1991" is used in some tables where an endash in a date range impedes sorting. Is this a case where the MOS requires a particular form even if it results in broken functionality? Or may date ranges be written in other ways (excluding a hyphen)? Gimmetoo ( talk) 21:39, 6 August 2011 (UTC)
For people previously uninvolved, here's some background information on the issue of dashes/sorting:
Nymf hideliho! 22:23, 6 August 2011 (UTC)
This website shows all versions of Safari accounting for 5.17% of users in July 2011. Of this, Safari 5 accounts for 3.52%, leaving only 1.65% of Internet traffic is using all other versions of Safari. It hardly seems worth our while to convert our filmography tables to a style that does not follow our own Manual of Style to accommodate such a tiny percentage of internet traffic; Safari 4 came out two years ago and even Safari 5 is over a year old and is being replaced with 5.1. This stuff is little used, and Safari 4 is obsolete, antique in internet terms.-- Dianna ( talk) 22:31, 8 August 2011 (UTC)
I tried to just ask the MOS question here, but people keep bringing in other issues. So here is an overview of the problem and solutions identified so far.
There are a number of ways to deal with this issue. Some of them are:
So I would like answers to a few questions:
Comments below. Gimmetoo ( talk) 01:31, 10 August 2011 (UTC)
I believe the user base is large enough to justify some form of fix. I don't think it's appropriate to intentionally make a technical feature misbehave for a significant subset of readers when there are very simple fixes available. To my recollection, WP has supported browsers up to 5 years old. Among the options listed, most editors who are familiar with the issue think the templated sortkey approach is too complex for the scope of this issue. I tend to agree, since much simpler fixes are available. I think the "to" option is appropriately simple for the scope of this issue. (Even if it were against the MOS - and I don't agree it is - I think this would justify a MOS exception.) I'm also fine with a different table structure that avoids the issue, or with reverting to the non-sortable form of the table. Gimmetoo ( talk) 01:31, 10 August 2011 (UTC)
The usage of Safari 4.0 is trivial and will be effectively zero in next to no time, certainly before a significant number of /fixes/ could be deployed. Removing sorting functionality, as Gimmetoo has done, over this tiny issue with a tiny number of readers is flat-out disruptive. I'm amazed at the insistent argumentation over this non-issue. I noticed an odd 'to' in a date range and looked at why, and days later, the insipid argument continues. Use normal endashes and any common browser and all is fine. -- 168.122.165.145 ( talk) 02:23, 10 August 2011 (UTC)
There's been an extensive discussion above. On the basis of the 80%/20% rule, it doesn't matter if we don't have the table complete and/or don't capture all units. It can be updated as required. But the most common 20% of units that are responsible for most of the overlinking and editors need specific guidance. In the absence of any other proposal, I propose the following table
Quantity | Not obscure in US | Not obscure in UK | Not obscure in rest of world |
---|---|---|---|
Length, area, volume | Metre/meter | Metre/meter | |
Length, area, volume | Inch, foot, yard, mile. Square yard | Inch, foot, yard, mile. | |
Length, area, volume | Litre/liter | Litre/liter | Litre/liter |
Length, area, volume | US fluid ounce, pint, quart, gallon | imperial fluid ounce, pint, quart, gallon | |
Mass | Gram | Gram | |
Mass | Ounce, pound, short ton | Ounce, pound, stone, tonne | tonne |
Time | Second, minute, hour, day, week, month, year, decade, century, millennium | second, minute, hour, day, week, fortnight, month, year, decade, century, millennium | second, minute, hour, day, week, month, year, decade, century, millennium |
Speed | Mile per hour | <not-obscure unit of length> divided by time | <not-obscure unit of length> divided by time |
Temperature | °F | °C | °C |
Power | Watt, Plus prefix kilo | Watt | Watt. |
Power | Horsepower | ||
Energy | Kilowatt hour | <not-obscure unit of power> multiplied by time | <not-obscure unit of power> multiplied by time |
Energy | Calorie. | Calorie. | Calorie. |
Voltage | Volt | Volt | Volt |
Frequency | Hertz | Hertz | Hertz |
Information | Bit, byte. | Bit, byte. | Bit, byte |
Other | Prefixes milli, centi, kilo, mega, giga applied to <not obscure SI units> | Prefixes milli, centi, kilo, mega, giga applied to <not obscure SI units> | |
Other | Square and cubes of <not obscure units> | Square and cubes of <not obscure units> |
I've tried to encapsulate all comments. I think it's time to document consensus for adding a table like that, or even a trimmed down version. Lightmouse ( talk) 11:40, 10 August 2011 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Perceived problems of the current guideline as I understand it, excepting for dates within titles and quotations :
I propose that henceforth we stipulate that all dates in the reference sections are uniformly consistent, as provided in this version (click on "show" to see it):
Date formats may be the same as prevailing in the body of the text – and may be abbreviated if there are space concerns, or they may be in the yyyy-mm-dd format -- Ohconfucius ¡digame! 09:15, 7 August 2011 (UTC)
I would like to see if a new consensus exists based on the following premises:
- there is no consensus to eliminate ISO 8601 or yyyy-mm-dd date formats from articles, in particular the reference sections
- a mix of date formats in the reference sections is aesthetically unattractive and difficult to parse
- there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for access dates whilst leaving the publication date in dmy or mdy format
- there is little reason to disallow ISO 8601 or yyyy-mm-dd formats for publication dates whilst allowing this for the accessdates
- there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for archive dates should be treated any differently from publication or access dates
- dmy or mdy format using abbreviated months can be equally concise as the yyyy-mm-dd format; the only thing we care about is consistency
- 'reference format' remains undefined and its meaning is unclear.
- tabular form of presentation where examples of dos and don'ts are juxtaposed is starker and more easily comprehended by the reader.
I suggest modifying one bullet and adding a new one; additons are underlined:
Also, change all instances of ISO 8601 to yyyy-mm-dd.
Jc3s5h ( talk) 22:26, 7 August 2011 (UTC), modified 23:57 UT
In answer to a question posed on my talk page, "the format specified in any style guide the reference section follows", the MOS does not address itself to references, except to refer to WP:CITE. That guideline indicates any style may be used for citations. At least one citation style, APA style, calls for one format in the body of articles (Mmmm DD, YYYY,) but a different format in the citations (YYYY, Mmmm DD). To disallow following an external style guide in the reference section would place this guideline in conflict with WP:CITE. Jc3s5h ( talk) 01:45, 8 August 2011 (UTC)
On further consideration, I withdraw my suggestion and instead offer a counter-proposal below. Jc3s5h ( talk) 21:33, 8 August 2011 (UTC)
I suggest removing the text currently in the guideline:
![]() |
![]() |
---|---|
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009 | Jones, J. (20 September 2008) ... Retrieved 5 Feb 2009 Jones, J. (20 Sep 2008) ... Retrieved Feb 5, 2009 |
Jones, J. (20 September 2008) ... Retrieved 5 February 2009 | Jones, J. (20 September 2008) ... Retrieved February 5, 2009 |
Jones, J. (2008-09-20) ... Retrieved 2009-02-05. | Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05 Jones, J. (2008-09-20) ... Retrieved 5 February 2009 |
I would replace it with the following:
Also, I would add a statement to "Citing sources" that all-numeric date formats in which the first element represents the day or month should not be used, regardless of any recommendation in an external style guide, and any article currently using such a system should be corrected. Jc3s5h ( talk) 21:41, 8 August 2011 (UTC)
Would an admin close this discussion? Thanks,
Cunard (
talk)
05:20, 28 September 2011 (UTC)
Would an admin close this discussion? Thanks, Cunard ( talk) 20:25, 14 October 2011 (UTC)
I recently came across a fine example of what I like to call " misconversions". The Gallons per mile section of Fuel economy in automobiles used to read as follows (with a minor typo fixed, the reference removed and the {{convert}} call written out explicitely).
For example, replacing a car that gets 14 mpg-US (17 mpg-imp; 17 L/100 km) with a car that gets 25 mpg-US (30 mpg-imp; 9.4 L/100 km) saves 3 US gallons (2.5 imp gal; 11 L) of fuel every 100 miles (160 km). Because 1 US gallon (0.83 imp gal; 3.8 L) of fuel emits 20 pounds (9.1 kg) of carbon dioxide, saving 3 US gallons (11 L) of fuel every 100 miles (160 km) saves 3 short tons (2.7 t) of carbon dioxide every 10,000 miles (16,000 km) of driving.
I took a look at this through a couple of "filters". Firstly my imperial filter yeilded this.
For example, replacing a car that gets 17 mpg-imp with a car that gets 30 mpg-imp saves 2.5 imp gal of fuel every 100 miles. Because 0.83 imperial gallon of fuel emits 20 pounds of carbon dioxide, saving 2.5 imperial gallons of fuel every 100 miles saves ??? of carbon dioxide every 10,000 miles of driving.
It made me wonder what kind of measure 20 pounds of carbon dioxide per 0.83 imperial gal was. 20 pounds per 0.83 imperial gallon. What fancy number is 0.83?
Then I tried on my metric filter. Here's what I got.
For example, replacing a car that uses 17 L/100 km with a car that uses 9.4 L/100 km saves 11 litres of fuel every 160 kilometres. Because 3.8 litres of fuel emits 9.1 kilograms of carbon dioxide, saving 11 litres of fuel every 160 kilometres saves 2.7 tonnes of carbon dioxide every 16,000 kilometres of driving.
"Wow!" though I. Even more fancy numbers. 11 litres per 160 kilometres times 9.1 kilograms per 3.8 litres equals 2.7 tonnes per 16,000 kilometres. Now, I'm feeling much enlightened. 'Cause here in metricland we always measure things by the 3.8 litre and the 1.6 kilometre.
Another thing we tend to to, here in metricland, is measure food energy density in kilojoules per 450 grams. For example, I like to eat Foobars but I'm getting fat because they contain 420 kJ (100 Cal) per 450 grams (1 lb). I also drink Foozypop which contains 630 kJ (150 Cal) per 355 ml (12 US fl oz).
Well, I rewrote the example to give litres per 100 kilometres, pounds per imperial gallon, kilograms per litre, long tons per 10,000 miles and tonnes per 10,000 kilometres. I also tweaked the numbers for accuracy, tweaked the wording for flow and came up with this.
For example, replacing a car that gets 16 mpg-US (19 mpg-imp or 15 L/100 km) with a car that gets 30 mpg-US (36 mpg-imp or 8 L/100 km) saves 3 US gallons (2.5 imp gal) of fuel every 100 miles (7 L/100 km). Because the combustion of 1 US gallon of fuel emits 20 pounds of carbon dioxide (burning 1 imp gal emits 24 lb and burning 1 L emits 2.4 kg), this saves 3 short tons (2.7 long tons) of carbon dioxide every 10,000 miles (1.7 t every 10,000 km) of driving.
This might well be the worst I've see but it's not the first. I wonder whether it's worth adding guidance regarding the conversion of such ratios imbedded in text. Converting the ratio as a whole rather than converting its parts individually seems such common sense to me but I guess it's not so for everyone. What might be a good way to phrase it? JIMp talk· cont 10:19, 7 August 2011 (UTC)
At present, the following is given: A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). Given that I have never seen this requirement in academic works, in fact, the opposite exists, years are normally expressed in full. FWiW Bzuk ( talk) 17:46, 11 August 2011 (UTC).
I brought this up recently. The resulting discussion is probably in the archives somewhere. My position is that short date ranges are more commonly written with two closing digits (e.g. 1914-18 and 1939-45), but that writing it out in full is also common. I think that when writing out a person's birth and death years, it is vital to write the death year out in full no matter what the context. This is because these years are so central to identifying people, especially those with the same or similar names. It is also a matter of style. Aesthetically, it looks better if the closing year is uniformly written the same way, not varying depending on the context, so the full closing year is best. Finally, as a reader, when looking for information in an article or list, I often know the year something happened and search for that to find it in the article (often I find people have neglected to name the year and that is something that can be corrected). Similarly, when trying to identify people (often relatively obscure 19th century naturalists) when I have a name and no birth or death year, I sometimes find what might be the birth or death year, and then do a new search including that year, and get the results I need. For obvious reasons, it is best to be able to search on the full year, not an abbreviated version. Carcharoth ( talk) 15:55, 29 August 2011 (UTC)
Please see WT:CITE#Which Wikipedia guideline(s) should establish citation format? Jc3s5h ( talk) 16:59, 13 August 2011 (UTC)
Per MOS biographies, I added a note that if the full dates are provided by an infobox or in the text of the article, a simple span of years is sufficient in the lede. This follows the general principle of reducing clutter in the lede. Although I have added quite a few pronunciations to biography articles, I would encourage those to be moved to an infobox as well. (This has been done systematically with astronomical bodies.) — kwami ( talk) 23:24, 21 August 2011 (UTC)
<ref>
tags is a very bad idea, as it's impossible for readers to anticipate that the footnote contains stuff other than a citation of a source. With <ref group="Note">
, on the other hand... ―
A. di M.
plé
dréachtaí
10:01, 25 August 2011 (UTC)
{{#tag:ref||group="note"}}
to the 'Wiki markup' edit window for just these situations. Unlike <ref group="Note">
, #tag:ref allows you to place <ref>
tags in the notes themselves. —
kwami (
talk)
10:23, 25 August 2011 (UTC)A couple of points. Firstly, all the discussion about pronunciation and non-MOSNUM stuff should either be discussed at a different location or unified in a single discussion. In other words, if sweeping changes are to be made to the way biographical articles are written on Wikipedia, a discussion should be opened at WT:BIOGRAPHY and possibly notification left at WP:CENT given the massive number of biography articles on Wikipedia. Also, it would help if a preliminary audit gave an idea of the number of articles this would affect, and how many use the current style? A further point is that many biography articles don't use infoboxes, so it is best to leave infoboxes out of the discussion, or state what should be done where there is no infobox. My view is that a discussion should be undertaken to settle on the style used on biographical articles, rather than piecemeal discussion of different aspects in different places (year range in lede at MOSNUM and pronunciation at PRON is a classic example of splitting up a discussion that should be done altogether in one place). But that discussion should take place at the Biography WikiProject pages, not at MOSNUM. Possibly Wikipedia talk:Manual of Style (biographies) is a another venue, but it is vital that input is obtained from those who write biography articles on Wikipedia, rather than those who write manuals of style. My view is that having the birth and death dates in the lead is fine, but everything else should be seen as clutter and relocated. The reason I think birth and death dates should stay in the lead? Because if you remove them, the lamest edit wars you can imagine will break out between people who want to write 1832-1895 and those who want to write 1832-95. Seriously (and that is on-topic for this page!). Carcharoth ( talk) 01:00, 29 August 2011 (UTC)
{{
cite journal}}
: Missing or empty |title=
(
help)
Is there a policy on abbreviating the word "number"? In articles concerning rail transport, I often see text concerning individual locomotives. Rail locomotives are normally identified by number, and so this text is usually like "No. 123 was built in ..." but sometimes I see text like "Nº 123 was built in ...". Do we have a policy on whether one of these forms is preferable to the other? -- Redrose64 ( talk) 18:48, 24 August 2011 (UTC)
Perhaps opinions vary, but I usually avoid all abbreviations. My pet peave is "aka" which slips in too many times. Unlike other encyclopedias that are limited by paper, we should have no constraints. On the other hand, there might be some domain-specific styles that use certain well-known abbreviations almost exclusively, the one I think of is HMS or USS for ship names- these are almost never spelled out. You might also discuss at a relevant project page. But when in doubt, spell it out. W Nowicki ( talk) 23:01, 24 August 2011 (UTC)
We're informed that it was agreed to move MoS pages to subpage format, which means this page ought to be called Wikipedia:Manual of Style/Dates and numbers. I can't move it since it's move protected - can someone with admin rights do it (or does someone want to object?)-- Kotniski ( talk) 11:25, 30 August 2011 (UTC)
No need to worry about numerical pages. Most talk pages deem a search box sufficient for access to archives. Lightmouse ( talk) 15:21, 3 September 2011 (UTC)
I was puzzled by this guidance: When only the years are known, or days and months would be irrelevant detail: "Socrates (470–399 BC) was..."
Under what circumstances would days and months be an irrelevant detail? I assume we omit the exact dates of Socrates' life because we don't know them, not because they're irrelevant. Why would they be irrelevant? Because dates of people who lived long ago are automatically not relevant, and dates of people who live or lived more recently are automatically relevant? Now that I think about it, if we're making determinations based on relevance, it's hard for me to see the relevance of including the birthdates (beyond the year) of the vast majority of living people who are the subject of Wikipedia articles.
I suggest deleting the phrase about "irrelevant detail," but if there is some meaning to it that I'm missing, I suggest the guideline be clarified to explain the distinction between relevance and irrelevance. Theoldsparkle ( talk) 15:23, 6 September 2011 (UTC)
Well, it's not that simple. The statement "Joe Shmoe (birth - death) was..." is at the intersection of WP:MOSBIO and WP:MOSDATE.
There have been a lot of discussions regarding the parenthesized vital information traditionally following a person's name in biographical articles. There was a huge discussion on this last year: Wikipedia talk:Manual of Style (dates and numbers)/Archive 132#So what IS the deal with birth/death locations in the opening? (ignore the section title and opening section and jump down to the "Staw Poll" subsection). Over 80 editors participated so this is the operative discussion in my opinion.
Anyway... Some people feel it should be "Charles Robert Darwin (12 February 1809 – 19 April 1882) was..." and some that it should be "Charles Robert Darwin (1809 – 1882) was...". And there's no agreement on this, so people do what they they think best. The problem is, one might infer from the example used in MOSDOB that there's a prescription to give the day and month, and that's not true. But if you changed the example to give only the year, that would possibly imply that there's a prescription to not give the day and month, and that's not true either.
It's confusing. There is absolutely not a consensus to use the day and month in the parenthesized vital information. The examples show this, but only because the examples have to show something.
MOSBIO handles this much better, but MOSBIO also has a failing: it says nothing about the parenthesized vital information. It only talks about the lede paragraph as a whole. (The examples there show parenthesized vital information, leaving one to possibly infer that they're at least recommended, but that's it.) If you go by MOSBIO -- what's written, not the examples -- the following lede would be perfectly within the MOS:
We need to combine the strengths of this two complementary sections, in one place. Here's what I think: MOSDATE should get out of the biography business. (Either that, or MOSBIO should get out of the date business (which would be a lot harder, I think).) MOSDATE's job is telling what kind of dash should separate two dates when they appear in succession, and what kind of punctuation should separate the day from the month and the month of from the year when a full date is given, and so forth. And that's it. It should not saying, or even implying through examples, what level of detail is to be given to the parenthesized vital information at the start of of an article, or whether biographical articles should have the death date in the lede or at the end, and so forth. That's MOSBIOS's job.
It's certainly not a good idea to have two different MOS's talking about the same thing and not agreeing, which is the case now, at least arguably (depending on whether you think examples imply prescription, which I think a lot of people think they do unless this is overtly disclaimed).
This has been a headache for years, and a constant source of confusion. It's time to put paid to this. I propose to work up an RfC on this presently. Herostratus ( talk) 06:11, 21 September 2011 (UTC)
Maybe I've missed it somewhere, but I see no direct information regarding the use of the word "present" in section headers. For example, I see many headers that list an event that occurred over a series of time and listed as (1980-present). I'm thinking that the same train of thought that applies to use of the word "currently" would also apply here but I'd like to be sure. Would that same rule apply that applies to the article body also apply to the section headers? NJZombie ( talk) 18:23, 8 September 2011 (UTC)
Note that, contrary to the dates section of this manual, the logon screen today reads:
With superscript. — Robert Greer ( talk) 16:52, 18 September 2011 (UTC)
The plural of euros has been discussed so many times (see the archives of this talk page). Following the latest edit [8] we are now being told the plural is euro. But is the fragment "it is easier to pay for eggs in euro" really in the preferred form? Linguistic issues concerning the euro is sympathetic with "euros" and A handbook for authors and translators in the European Commission (at 20.9) is definite. Also, although I can imagine someone writing "a two-euros pen", English adjectives are not inflected and people do not need to be told this here. Could we not delete this whole bullet point as being far more bother than it is worth? Thincat ( talk) 17:09, 2 October 2011 (UTC)
I would like to see a statement here regarding the use of the South Asian numbering system in articles. For example the article Ajay Kumar, it says he won by "1.55 lakh votes", is acceptable style? Kevink707 ( talk) 17:03, 10 October 2011 (UTC)
I'm not sure how (or where) to address this concern. Basically, I'm asking if infoboxes such as "{Infobox cemetery}" need lines for both Lat/Long entries and coordinates. (I've posted a comment on the particular infobox discussion page Template talk:Infobox cemetery.) Comments welcome. -- S. Rich ( talk) 04:56, 11 October 2011 (UTC)
Hey all.
I wonder if there is anyone who agrees with me, when I question the current DATERET guidelines. I regularly come across articles that have absolutely no relation to US or Canada, and still have a date format that is distinctly North American (or even US, as Canada have both formats). These articles – on topics that are Russian, German, Spanish, Japanese, Danish, or whatever – were probably once created by an American wikipedian, using his/her own habitual date format. That is no reason for those articles to have a US-centric date format, but the current guidelines seem to prevent changing the articles to a more appropriate format.
Wouldn't it be better if the "Strong national ties" section of the guidelines was altered so that it was permissible to alter the date format to a more appropriate one? (Changes could obviously go both ways.) I mean, just because the first major editor, probably unknowingly, made a poor choice of format, should the article for ever be doomed to keep that? If I had started the article on Tiger Woods or Bill Clinton using the international date format, would that be right?
HandsomeFella ( talk) 19:48, 14 October 2011 (UTC)
Questions are in regard to WP:ASOF. It doesn't look like that page sees much traffic, so posting here instead.
Any responses are appreciated. Thanks, Nightw 14:30, 17 October 2011 (UTC)
In Wikipedia:DATESNO it states that the ordinal suffix is never used, but I was told here that there is an exception when the date is preceeded by the day of the week. Is there an exception to this rule? If so, we should cover it here. Thank you. Frietjes ( talk) 15:13, 18 October 2011 (UTC)
Which of these is correct:
The only guidance given is that "September, 1944" is wrong and "September 1944" (no comma) should be used instead. This tells me to remove the comma in that case, but doesn't tell me to remove the "of" if it exists.
I'm fine with "whatever". I think that "...in September of 1944, the..." sounds better and is more idiomatic, but I don't much care. Am I correct in believing that there is no guidance and editors are free to do as they prefer, right? (In which case other editors shouldn't correct whatever the previous editor decided, generally.)
If there should be a standard, it should be added as an entry in the table in the "Dates" section - Incorrect = June of 2001, Correct = June 2001. Herostratus ( talk) 18:35, 21 October 2011 (UTC)
Just to clarify, I don't think there needs to be a standard. I don't believe in getting down to the level of detail where the MOS is telling editors they can never write "One of the many..." and must always write "Among the many..." instead, and so forth. (It might be nice to make a notation to the effect of "There is no preference between 'September 1944' and 'September of 1944', do as you wish", to clarify the situation.) But is editors think it should be specified that'd be OK I guess. Herostratus ( talk) 18:51, 21 October 2011 (UTC)
You are invited to join the discussion at
Template talk:Convert#Numbers greater than 0 but less than or equal to 1 should use singluar nouns.
― A. di M.
19:12, 24 October 2011 (UTC)
The discussion here may interest some of you. The question is whether it is appropriate to revert an editor who used a consistent date format in refs in an article. So that instead, inconsistent date formats exist (even within the same refs).
Some guidelines at issue are WP:DATESNO, WP:STRONGNAT, and Wikipedia:Citing sources.-- Epeefleche ( talk) 06:44, 28 October 2011 (UTC)
Where the refs section, for example, of an article uses 3-letter abbreviation for the month:
An editor inserted this:
I think this is probably correct but I'm not certain and just wanted to see if there was any objection. If anyone objects to this here would be the place to so state. Herostratus ( talk) 20:09, 19 November 2011 (UTC)
Well, it'd be good to ask Art LaPella on that one, since it's his example, and because I'm not 100% confident on that usage. However, I believe I would employ the comma (in his as well as in your simplified example), as I'd wish to communicate to the reader that the usual word order (subject-verb-object(s)) is being changed. — JohnFromPinckney ( talk) 22:53, 22 November 2011 (UTC)
A bit of a conflagration at Neolithic Revolution has made me realise that the current wording of WP:ERA:
Is slightly ambiguous about what reasons there can be for changing from one style to the other, especially for new editors who aren't totally familiar with our nuanced definition of "consensus" (i.e., it isn't a vote, it's limited, and it should be based on policy). I understand why the wording was changed early this year from a version that was slightly more clear in that regard, but User:Cynwolfe has already suggested a version that gives us the best of both worlds (w/ some slight alterations):
Can we go ahead and add this? joe•roe t• c 12:07, 1 December 2011 (UTC)
There is a discussion at convert regarding foot-pounds and pound-feet. A number of points raised there deserve a broader consensus that convert's talk page provides.
What're your thoughts? JIMp talk· cont 06:21, 5 December 2011 (UTC)
I agree absolutely that it should be a middle dot separating "ft" and "lb", not a hyphen, not a bullet and definitely not a slash (lb/ft is pounds per foot and ft/lb is feet per pound). However, none of these should be capitalised. Thus it's "ft·lbf" or "ft·lb" and "lb·ftf" or "lb·ft" (or "ft·lbf" and "lbf·ft"). This is in accordance with MOSNUM.
- When unit symbols are combined by multiplication, use a middle dot (
·
) or a non-breaking space (
) to separate the symbols. ...- Unit symbols/abbreviations, apart from those listed below, are written in either non-alphabetic characters or in lower-case letters unless they are derived from a proper name, in which case the first letter is a capital letter. ...
Scheinwerfermann, it would seem you prefer "lbf" over "lbf" or am I misreading you? Should we insist on one? Should we insist on the other?
It has become established practice that we follow the sources. As it is an encyclopædia we're cobbling together, our preference ought to be for the more scholarly source. Assuming that your collection, Scheinwerfermann, is representative of current literature, it seems we have a solid case for adopting Worthington's convention here. Much less the harm if we err in favour of unambiguity. I support restricting "foot-pounds (force)" to energy and "pound (force)-feet" to torque on WP. Further, I support the general case of restricting length-force units to energy and force-length units (e.g. newton-metres) to torque. I propose adding this to the guideline.
How about the "force" in "foot-pounds (force)" and "pound (force)-feet"? Is it manditory, preferable, context dependant,, completely optional, undersirable or to be banned entirely? Is the "force" in "foot-pounds (force)" to be given equal weight as that in "pound (force)-feet" or are they to be given unequal footing? Scheinwerfermann, do I read you wrong that you'd accept "pound-feet" ("lb·ft") but not "pound force-feet" ("lb·ftf") but you find both "foot-pounds force" ("ft·lbf") and "foot-pounds" ("ft·lb") acceptable? JIMp talk· cont 00:46, 6 December 2011 (UTC)
I have proposed adopting the convention that a unit written as length times force is a unit of energy and a unit written as force times length is a unit of torque. There being no opposition to and clear advantages in so doing let us add this to the guideline. JIMp talk· cont 02:51, 9 December 2011 (UTC)
I have added the following to WP:MOSNUM#Unit names.
When units of torque or energy are formed by multiplication of a unit of force with a unit of length, distinguish these by putting the force unit first for torque (e.g., newton-metres or pound-feet) and the length unit first for energy (e.g., foot-pounds or foot-pounds force).
JIMp talk· cont 08:19, 9 December 2011 (UTC)
Having just added pound-moles to {{ convert}} and wondering whether we abbreviate it as "lbmol", "lb-mol" or either, I brought the question up at MOS Chem. JIMp talk· cont 03:18, 8 December 2011 (UTC)
All editors are reminded that voting closes for ACE2011 in just over a day's time (Saturday 10 December at 23:59 UTC). To avoid last-minute technical logjams, editors are asked to vote at least an hour before the close, that is, by:
For the election coordinators. Tony (talk) 13:05, 9 December 2011 (UTC)
Minor question regarding WP:DECADE: It says that four digits (1960s) are preferred over two digits (60s), which makes sense. I've got an article that has "1960s and 70s". That seems superior to "1960s and 1970s". Should WP:DECADE identify that as a permissible use of 2 digits, or is that too obscure? -- Noleander ( talk) 17:49, 9 December 2011 (UTC)
Section 2.5 states: "Forms such as the 1700s are normally best avoided since it may be unclear whether a 10- or 100-year period is meant (i.e. 1700–1709 or 1700–1799).". I agree, but no alternative form that should be used is provided. I have been using, for example, 'first decade of the 21st century'; I imagine others might use something else. An agreed upon alternative to 2000s would be helpful if stated here in the MOS. Thanks Hmains ( talk) 20:51, 12 December 2011 (UTC)
I see no guidance on abbreviating this currency, but have always seen it as RM. Ulf Heinsohn has made a series of edits changing it to script ℛℳ, in this edit to Nibelungen Bridge (Regensburg) with the edit summary "typo", elsewhere, (for example this edit to Festhalle Viersen) also replacing Reichsmark with German gold mark and referring only to that change in the edit summary. I believe he's right to regard Reichsmark as anachronistic in those cases, but what is the policy on the script rather than plain text abbreviation? I wanted to determine whether there was one before raising the issue with the editor. Yngvadottir ( talk) 19:01, 13 December 2011 (UTC)
According to Wikipedia:MOSNUM#Large_numbers, millions is abbreviated to upper case M, but billions is abbreviated to lower case bn. This strikes me as being inconsistent (and thus contrary to one of the general rules of MOS). Should we use consistent case? Is there a specific reason why the case is different here? Mitch Ames ( talk) 13:28, 14 December 2011 (UTC)
For what it's worth, I was thinking about currency, eg $20m or $20M, when I raised the matter. Here are the relevant , comment and revert. Mitch Ames ( talk) 12:02, 16 December 2011 (UTC)
There is a discussion of the application of STRONGNAT here, which may interest some readers of this page.-- Epeefleche ( talk) 16:41, 14 December 2011 (UTC)
I've never seen any real consensus to accept sloppy, lazy crap like "30 Sep 2009" and "Sep 30 2009". Not here, not at WP:MOSABBR, not in years and years of debates about date formatting and autoformatting. I correct this mess to proper date formatting every time I encounter it, and this is getting increasingly tedious. Now I know why: Some joker added this to WP:DATESNO on a whim, and it's consequently attracting lazy editors to follow its bad advice. Even the allowance of ISO dates for accessdates is a bad idea with a lot of negative consequences (everyone and their dog has been using them for publication dates in citations, too. Often enough to be worrisome, non-technical non-Americans, used to day-month order in prose wrongly put 2009-30-09, which is "fatally" problematic for any day number under 13.
But this month abbreviation garbage is going to far. For one thing, there's no universal standard. Some people like any of "Sep", "Sep.", "Sept" and "Sept." among probably others. It's a total nightmare for reusability (e.g. parsing by bots). It's even worse for non-native English speakers who don't automatically recognize inconsistent abbreviations through long familiarity. And it's just sloppy, and lazy. It's going to spread to article prose (already is - I've undone it in articles many, many times). There are already too many date formats here. Even being American, I'd prefer we standardized on 30 September 2009 format and deprecated ALL others. At least clean up this particular mess:
=====In references===== {{See also|Wikipedia:Citing sources#Citation style |l1="Citation style " section in "Citing Sources"}} * Publication dates in article references should all have the same format. :In the same article, write :{{xt| :*Jones, J. (20 September 2008) :*Smith, H. (August 2002) :*Garcia, M. (4 May 1999} }} :or :{{xt| :*Jones, J. (September 20, 2008) :*Smith, H. (August 2002) :*Garcia, M. (May 4, 1999} }} :but not :{{!xt| :*Jones, J. (20 September 2008) :*Smith, H. (August 2008) :*Garcia, M. (May 4, 1999} }} *Access and archive dates in references should be in either the format used for publication dates, or YYYY-MM-DD. :In the same article, write :{{xt| :*Jones, J. (20 September 2008) ... Retrieved 5 February 2009. }} :or :{{xt| :*Jones, J. (September 20, 2008) ... Retrieved 2009-02-05. }} :but not :{{!xt| :*Jones, J. (20 September 2008) ... Retrieved February 5, 2009. }} These requirements do not apply to dates in quotations or titles. }}
Made the examples a bit clearer in the process.
I would (severably) also prose elimination of ISO dates as acceptable for anything, including tables if the current table sorting code can work around the need for being able to sort by date, which appears to be the case. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 15:15, 16 December 2011 (UTC)
There is currently a discussion taking place at WT:HWY regarding the potential use of coordinates in highway articles. Your input is welcomed. -- Rs chen 7754 01:30, 26 December 2011 (UTC)
I have been editing quite a few articles about English villages recently, and a question has arisen in my mind regarding the use of hyphens in centuries. Am I right in thinking that when a century is used as a noun, there is no hyphen between the number denoting which century it is, and the actual word "century", whereas a hyphen is required when the century is used as an adjective (e.g. "the church was built in the 15th century" [used as a noun], contrasting with "a 15th-century church" [used as an adjective])? I could find no mention of this issue in the MoS. PaleCloudedWhite ( talk) 01:27, 28 December 2011 (UTC)
Thanks. I didn't look at that section; I didn't read far enough down the page (I just looked at the bits about calendars etc.) That'll teach me to draw rushed conclusions about a topic not being in the MoS (although finding the required information isn't always easy!) Still, it does back up my own deduction... PaleCloudedWhite ( talk) 08:57, 28 December 2011 (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 130 | ← | Archive 133 | Archive 134 | Archive 135 | Archive 136 | Archive 137 | → | Archive 140 |
Colleagues, I've never been completely confident about the decimal-point consistency thing. I've raised it here. In particular, this one foxes me: "whose height varies between 4 and 12 cm (1.6 and 4.7 in), and which is typically between 1 and 1.5 cm (0.4 and 0.6 in) thick". Your advice? Tony (talk) 07:49, 8 July 2011 (UTC)
WP:SEASON was used here to justify uncapitalizing "Northern Hemisphere". So should we fix it? Art LaPella ( talk) 19:45, 10 July 2011 (UTC)
I know we discussed year ranges, but what about page ranges and such? Do we drop digits, or not? Dicklyon ( talk) 04:10, 11 July 2011 (UTC)
I have recently been made aware of some ambiguity in date formatting. Last night I ran across a proposal to make changes to the MOS on date formatting, but it did not appear to pass for lack of consensus. I have searched through the archives, but I cannot find any references to this question below. Maybe I did not search well enough, or maybe it is not there. I presume there are likely a number of editors who are passionate about this topic and can point directly to the thread.
In the section for MOS:DATEUNIFY we have the section:
- Access and archive dates in references should be in either the reference format, or YYYY-MM-DD
- In the same article, do
- Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009.
- or
- Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05.
- or
- Jones, J. (September 20, 2008) ... Retrieved 2009-02-05.
- but not
- Jones, J. (20 Sep 2008) ... Retrieved February 5, 2009.
Here are the points I think need some clarification:
By looking at the prior MOSNUM debate linked above, I assume I will get a flood of replies to this question that says we cannot improve Wikipedia by making a decision on this topic. That is unfortunate for the readers. § Music Sorter § ( talk) 08:50, 11 July 2011 (UTC)
Also, I am one of a small handful of editors who work to keep date formats consistent within articles and across some article categories. This job is too tedious to perform manually on the scale that is required to ensure orderliness. Our task is rendered complicated by not stipulating the uniformity of dates in refs section (exceptions I noted aside). The consequence is that those of us who maintain dates either avoid aligning dates (in refs section) due to the complexity, or run the risk of complaints from those who want to see yyyy-mm-dd formats retained but do not ensure that articles 'under their wing' are compliant, the mix of many dates in reference sections will proliferate due to organic nature of growth of articles. I do not recall hearing any cogent argument why we must restrict yyyy-mm-dd dates to the 'accessdate' parameter (and not apply to the 'date' parameter within citations as well). If the oft-cited desire for "conciseness" is a true desire, allowing yyyy-mm-dd dates to be used uniformly throughout reference sections ought to be the standard. It isn't. Given that it is only a small handful of editors who care about date consistency and an equally small number in favour of retaining yyyy-mm-dd formats for access dates, it seems mighty unfair and tedious to have to bash it out on each article where the two groups of contributors would meet. It is a matter that needs to be more strictly defined and determined at MOS level. -- Ohconfucius ¡digame! 02:13, 12 July 2011 (UTC)
Just wanted to let all of you know that I've deleted Wikipedia:Manual of Style/(dates and numbers)/Eras - Archive2 (created in 2005), because the creator blanked it just two minutes after creation, and since that time it's never had any content except deletion templates and a category. There's significant content on the talk page, so I didn't delete that. I don't know how this page's archiving is normally done, so I just wanted to make sure that people who do know were aware of this situation. Nyttend ( talk) 13:04, 11 July 2011 (UTC)
There's been discussion about the conversion of acres (again), and I appears that there's no easy solution. I do believe editors need more detail in the guidelines about whether to convert to hectares or square metres or what. I have no idea what the solution is, but I find this, from Symphony Park very reader-unfriendly—both the originals and the conversions. Can't the rat of zeros be avoided? And can't we identify areas in which the ability of readers to visualise the quantities suggests how to express them?
“ | The $6 billion project is projected to include 11,000,000 sq ft (1,000,000 m2) of space on 61 acres. Plans call for 1,908,000 sq ft (177,300 m2) of office and medical space, 5,200,000 sq ft (480,000 m2) comprising 3,200 residential units, 3 hotels providing and estimated 1,800 to 2,300 rooms in 1,575,000 sq ft (146,300 m2) of space with 475,000 sq ft (44,100 m2) of retail. The area is also expected to include 60,000–100,000 sq ft (5,600–9,300 m2) of casino space. | ” |
Your input would be appreciated. Tony (talk) 10:12, 12 July 2011 (UTC)
Acres: a brief search found these examples. WP's treatment of acres looks like a real mess. I'm so glad I don't write articles that involve such areas. I wouldn't know where to go for guidance.
almost one billion acres, approximately 4,046,856 km2 (1,562,500 sq mi)
I don't believe the guideline is very clear... is it best to use the notation BC/BCE for both years in a span contained before the Christian Era (i.e. 20 BC – 10 BC), or just after the latter year (i.e. 20 – 10 BCE)? I ask this because I am coming across several articles across the main article space that use either or, and it could be confusing for readers. Especially if they aren't aware that BC years count backward as time moves forward. Thoughts? Should we decide on and clarify this?. — CIS ( talk | stalk) 03:16, 17 July 2011 (UTC)
Is there any reason this page doesn't mention {{ date}}? This can be used to automatically format dates like the old system but doesn't link them. We ought to think about when it should or shouldn't be used.-- Doug.( talk • contribs) 23:25, 15 July 2011 (UTC)
Feb. 14, 1987, was the target date.
Transclusions: The template isn't used often. It only looks like that because it's embedded in several templates. Lightmouse ( talk) 10:18, 18 July 2011 (UTC)
'Template:Infobox poker player' appears to be responsible for 60% of the transclusions. The date template was embedded in 2009. Its only function is to accept '2011-07-07' or '7 July 2011' in edit mode to get '7 July 2011' in read mode. Lightmouse ( talk) 12:47, 18 July 2011 (UTC)
If I understand this date template correctly, it is an abortion that should never have been made. It only affects how the dates appear for A) registered editors, B) who change their date preferences from “No preference.” Well over 99% of our readership will just see a default format (18 July). The use of this template just allows registered editors (those responsible for ensuring text is consistent and appropriate) from seeing that there might be a hodge-podge of different date formats in an article because the template effectively says “Here crybaby, we won’t darken your doorstep with a date format you don’t like to be exposed to.” My recommendation is to discourage use of the {date} format and for all editors who actually care about what our readership is seeing to set their date preferences to “No preference.”
Greg L (
talk)
15:40, 18 July 2011 (UTC)
OK, Experiment time. This date: July 18, 2011 was coded as {{date|2011-07-18|mdy}}
. Let me try this… (one moment, I’m in “Show preview” mode)…
With “No preference” in my date preferences, I see “July 18, 2011”. With my prefs set to “20:33, 18 July 2011”, I see the same thing. So…
Why would someone want to learn to use this template? What good is it? If I wanted a date to read July 18, 2011, why would I type {{date|2011-07-18|mdy}}
?? Someone explain this to me, please.
Greg L (
talk)
20:38, 18 July 2011 (UTC)
P.S. Apparently, it has utility somewhere in obscure practices with dates in highly structured sections, such as tables and other templates. I agree with Doug; it doesn’t need to be mentioned here.
Greg L (
talk)
20:48, 18 July 2011 (UTC)
The majority of cases are not useful. For an example of trivial use, see: 'Template:Infobox poker player'. If it has non-trivial uses, that's fine but trivial uses should be removed to simplify things for readers. Lightmouse ( talk) 12:26, 19 July 2011 (UTC)
The guidance says:
and
These appear to contradict each other. What should it say? Lightmouse ( talk) 18:55, 17 July 2011 (UTC)
Ah yes. I see now. I'll delete the first phrase as a contradiction. For the second phrase in 'Specific units' I propose changing:
Does that make the meaning clearer? Lightmouse ( talk) 19:25, 17 July 2011 (UTC)
A fair point. We have two issues:
Lightmouse ( talk) 13:30, 18 July 2011 (UTC)
Seems to be a solution looking for a problem. The only commonly used derived units are µL, mL, and L. Centiliters seem to be more common in Europe. Larger volumes are given in liters or cubic meters. -- Rifleman 82 ( talk) 05:51, 19 July 2011 (UTC)
Oppose - The current Wikipedia guidance is a rahash of the SI brouchure. In the United Kingdom millilitres are usually written "ml" rather than "mL" (at any rate the items in my fridge and store cupboard). I agree with User:Woodstone that we should not deviate from the SI Brochure unless there is good cause.
Martinvl ( talk) 06:38, 19 July 2011 (UTC)
Comment I prefer the lower-case versions and would oppose banning them. I just would want to see "ml" alongside "L". Woodstone raises a good point that the "1" wouldn't appear in the same position. JIMp talk· cont 07:40, 19 July 2011 (UTC)
Stop voting. Nobody has presented proposed text to change the intent of the guidance. This thread is only about whether we need to eliminate a contradiction and failure of clarity in *existing* guidance. User:Jc3s5h suggested changing the intent of the guidance but before a vote, please take it to another thread. In the meantime, I'll update the *existing guidance* to make clarify (as far as I can) the *existing intent*. 10:25, 19 July 2011 (UTC)
The guideline exemplifies the preferred abbreviation in roman face, c., although italicises the spellings-out. I've often wondered which is correct for the single-letter abbreviation. A recently promoted article, Deusdedit of Canterbury, has the italics. Tony (talk) 10:18, 10 July 2011 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
please change AD and BC to a more accurate scientific dating system
Jojotruth1 ( talk) 17:36, 20 July 2011 (UTC)
I think we've now resolved contradiction and clarity problems with current guidance on litre. Several people wanted to discuss changes in guidance. The following table summarises what I think people meant:
Permit 'l' without prefix | Permit mix of 'L' and 'ml' in article | Supporters | Comment |
---|---|---|---|
No | No | Jimp, Jc3s5h | |
No | Yes | Current guidance | |
Follow guidance in BIPM SI brochure | Woodstone Martinvl |
SI guidance |
If I've misunderstood, please make the appropriate changes. Lightmouse ( talk) 15:14, 19 July 2011 (UTC)
Interesting, thanks. Does the mosnum guidance over and above the SI brochure have any effect? Guidance that has no effect is probably a waste. Lightmouse ( talk) 14:26, 20 July 2011 (UTC)
Yes, I agree. WP mosnum repeats, contradicts, and goes beyond SI as we choose. I was merely suggesting that we look critically at the value of each repetition.
Forgive me for not understanding you. I agree with you that we can and should choose to repeat some of SI. We just need to ensure repetition adds value. Lightmouse ( talk) 16:44, 20 July 2011 (UTC)
Ah. I seem to remember seeing "ℓ" mentioned somewhere before. But I don't think I've ever encountered it in Wikipedia. Forgive me for not following you, can we take it step by step. Are you saying mosnum should have guidance on "ℓ"? Lightmouse ( talk) 20:58, 20 July 2011 (UTC)
Your wish appears to be granted. Mosnum says:
Table 6 of the SI brochure says:
The only remaining issue is whether there's a problem in WIkipedia that needs mosnum to say more than SI. User:Woodstone and User:Martinvl are happy with a one-to-one match between mosnum and SI guidance. If you are too, then so am I. Lightmouse ( talk) 09:43, 22 July 2011 (UTC)
I sympathise with your first choice but agree it's unlikely to succeed. Your second choice means keeping the 'Name' and 'Comment' columns the same and changing the 'Symbol' column to:
I'm ok with that. Lightmouse ( talk) 15:25, 22 July 2011 (UTC)
How about, instead of just allowing either notation in any given article, we take one of each and make it the standard. Most who complain about BC/AD being offensive cite the "Year of Our Lord" in AD, and most who complain about BCE/CE cite the 3 digits found in "BCE".
How about we make the new standard BC and CE? We will use "BC" all throughout Wikipedia for years before Year One, and we will use "CE" all throughout Wikipedia for years from 1 onward. For example, the contentious Jesus article would read, under this new Wikipedia system:
"Jesus of Nazareth, Yeshua in Hebrew or Aramaic (7-2 BC — 30-36 CE)"
Well, why not? I know that BC and CE are rarely paired in external sources, but why can't Wikipedia make a compromise to be as neutral as possible without also being as frustrating as possible by allowing both and having edit wars and reversions constantly? What's bad about this idea? Thoughts?. — Steven Evens ( contribs) 02:52, 22 July 2011 (UTC)
It is common for many publications to use BCE/CE when trying to be politically correct and trip all over oneself to be as inoffensive as possible. However, I’ve yet to hear narrators on TV and film documentaries (like on Egyptian pyramids) use this new terminology; instead, they stick to the “BC” and “AD” forms. I assume this is because the customary terms are less distracting in audible form because saying “This pyramid was thought to have been built in 2500 bee see eee” would leave the viewer in “WTF-land” for 15 seconds.
At risk of ticking off some of the 16-year-old wikipedians who might be looking in on this and who are all smitten with how wise and knowledgeable they have become in only two short years and who are trying to change the world; and in order to make peace on this issue using actual policy that underlies important principals of Wikipedia, I am all for just following the RSs for each particular article. For those articles where there is no guidance by the RSs, or the usage is mixed or unclear by the RSs, my personal preference is to use the BC/AD since I believe it least draws attention to itself for those who hear the words in their heads as they read. This philosophy comes from Technical Writing 101, which states that Thou shalt not use a writing style that draws undo attention to itself for the target readership.
But, since the above might make too much sense and deprive people of their God-given entitlement to wikidrama, I suspect the best thing to do here on this issue is the standard solution for deadlocks: “Do whatever ya’ want.” Greg L ( talk) 16:29, 27 July 2011 (UTC)
I noticed that few of the “regulars” of this page are signed up as members of WP:MEASURE. Have you ever considered joining it? It's not terribly active at the moment, but that might be because it has so few members. ― A. di M. plé dréachtaí 21:36, 3 August 2011 (UTC)
GiBberish in articles I care about infuriates me: Almost anything remotely related to the
octet variant of the
byte known as B
requires a binary interpretation, e.g., calculations with
sectors might use sector size 512, 2048, or 4096, but certainly never the 1000 to justify say
TiB. Please avoid marketing
GiBberish trying to sell less than 4,000,000,000 bytes as 4
GB.
ISO produces mainly non-free standards and is indirectly (via national bodies) dominated by the industry, not by consumers (incl. Wikipedia readers) or experts (incl. Wikipedia editors). –
89.204.153.166 (
talk)
10:22, 3 August 2011 (UTC)
There is a section called 'Unnecessary vagueness'. I think guidance can sometimes
That section doesn't appear to do any of the above. It seems to be just like saying 'use common sense', 'make appropriate edits', 'consult editors if there's a dispute' etc. I suspect the answer will be 'nothing' but what would happen if that section were deleted? Lightmouse ( talk) 11:11, 4 August 2011 (UTC)
I've not read through MOSNUM for some time. How did the units of measurement section get into such a mess? I can't understand most of it. Just how it's useful for editors is beyond me. Tony (talk) 13:02, 3 August 2011 (UTC)
I noticed [1], which would have changed the guidance. Past discussions resulted in saying it was acceptable to have publication date format differing from accessdate format - or, said a different way, that there was no consensus to forbid it. I clarified this based on the examples. However, the phrasing would still restrict a form that exists in articles - yyyy-mm-dd for the publication date, and ymd or dmy for accessdate. I've rephrased again, but I can see this being more disputed, so I'm drawing attention here: [2] Gimmetoo ( talk) 14:53, 5 August 2011 (UTC)
-- Ohconfucius ¡digame! 15:37, 6 August 2011 (UTC)
We have two templates: 'height' and convert. Although they are written differently, they have overlapping capabilities. Each has its own discussion page but there isn't a forum for discussion relating to the overlap. If the output is the same, when should an article use one rather than the other? Lightmouse ( talk) 10:56, 19 July 2011 (UTC)
{{height|ft=6|in=2}}
with {{convert|6|ft|2|in|m|2|abbr=on}}
. Which is why I was disappointed when Lightbot started going round infoboxes changing {{height}} to its {{convert}} equivalent, but assumed this would have been discussed somewhere...precision=0
parameter to usages of {{height}} where the default precision had produced half-inches in the output (displayed as a vulgar fraction). If there actually is agreement that nowadays people's heights are generally measured to the nearest whole inch, then it's fair enough to display at that precision as the result of a conversion from metric. But maybe this should be implemented by changing the output default at the template itself, rather than by complicating matters with the added precision parameter. cheers,
Struway2 (
talk)
12:57, 19 July 2011 (UTC)As far as I can tell, the following is true:
Height template | Convert template | Comment |
---|---|---|
{{height|ft=5|in=6}} 5 ft 6 in (1.68 m) |
{{convert|5|ft|6|in|2|abbr=on}} 5 ft 6 in (1.68 m) |
Identical. Height template actually uses the convert template |
{{height|m=1.68|precision=0}} 1.68 m (5 ft 6 in) |
{{convert|1.68|m|0|abbr=on}} 1.68 m (5 ft 6 in) |
Identical. |
What are the reasons for choosing one template over another? Lightmouse ( talk) 17:28, 23 July 2011 (UTC)
We have guidance that says:
Some units are neither common nor uncommon. They're in a middle commonality zone (e.g. nautical mile) where a link isn't required if a conversion is present. Can anyone suggest appropriate wording? Lightmouse ( talk) 11:56, 27 July 2011 (UTC)
How about adding an additional bullet:
Would that work? Lightmouse ( talk) 11:14, 31 July 2011 (UTC)
Aha! I'm not the only editor that missed conversions being mentioned in the footnote. I don't care where the discussion takes place but I brought it here because I thought it was a matter for units of measurement people. The issue is that the threshold is different inside a conversion. I think source and target are covered by the phrase but I'd welcome alternative suggestions. Lightmouse ( talk) 12:04, 31 July 2011 (UTC)
A good point. It would be a *lot* simpler to have a list of:
Widespread (aka 'common') units shouldn't be linked, less widespread but still-well-known units shouldn't be linked when in conversions. These two lists could be generated from a subset of the units in US NIST document. This would end frequent debates about whether <unit> should or should not be linked inside and outside a conversion. Lightmouse ( talk) 19:06, 2 August 2011 (UTC)
To A. di M.: Which of these U.S. Customary units of measure are drop-dead obvious to most non-U.S. English-speaking readers to the extent that virtually no non-U.S. reader would ever bother to click it if it were linked(?):
Let me know of your thoughts. Off the top of my head, the only SI unit of measure that is so exceedingly familiar that very few American readers would click a link is the liter, which is pretty common in grocery stores. Other than that one, I just can’t think of other units from the SI that should generally be considered as drop-dead obvious for many Americans (particularly older ones), including the kilogram and meter. Note that some of the above-listed units are already SI (but are essentially part of U.S. Customary) or are accepted for use with the SI; namely, the volt, degree of angle, and units of date and time. Greg L ( talk) 21:26, 2 August 2011 (UTC)
Certainly link the truely obscure units so as to help understanding but we should avoid cluttering the place up with links to articles with very little relevance to the topic at hand. If you're suggesting that a significant number of Americans would find such units as the kilometre, metre, centimetre, millimetre, square metre, square kilometre, kilogram, gram and kilometre per hour obsure, I'd find that quite surprising (inspite of how the rest of us like poking fun at supposed American ignorance). Sure, such units as the tonne, hectare, newton, kilojoule and degree Celsius might be a little obscure to many Americans, as would be their US customary/imperial counterparts to most of us metricated folk. However, I'd suggest that even these are not yet approaching that grey area Lightmouse refers to, they're still only more-or-less off-white. The thing is that we have, to reverse the section title, conversions instead of links. An American (even an ignorant one, assuming they're at least literate) is going to read "20 hectares (49 acres)" and think something along the lines of "oh yeah, a hectare is an area unit" and, if they care enough, could easily figure out "... about 2+1⁄2 acres"; just as a metric-minded fellow (yes, we can be ignorant too) will read "20 pounds-force (89 N)" and think something like "right, a pound force is a unit of force ..." and, again, after a little mental maths, "... about 4+1⁄2 newtons". If it bugs them enough, let them copy and paste it into the search box. No, that grey area is occupied by such units as the micrometre, the parsec, the pascal, the troy ounce, the bushel, the oil barrel, the nautical mile, etc. but it still depends on context. The knot in an article about a certain boat should not be considered obscure nor should the picometre be in an article about a certain molecule. There may even be contexts in which such relatively obscure units as fathoms, furlongs, firkins or femtometres need not be linked. JIMp talk· cont 05:17, 3 August 2011 (UTC)
Greg ask Tony if a principle should be:
If that's fine with Tony and Greg, it's fine with me as a principle. Although it's worth mentioning explicitly that a converted unit is less in need of a link than an unconverted one.
Greg suggested the following units wouldn't need linking for US readers:
It might help to say:
I agree that those few units shouldn't be linked. But like Jimp, I'm surprised the list isn't longer. Anyway, even just that would be an improvement over the current guidance. Lightmouse ( talk) 14:57, 3 August 2011 (UTC)
I think there is an over-abundance of left-brained males represented in this venue. I can tell you that if WT:MOSNUM had an ocean of right-brained *wife-types* (verbal and reading skills, not so much insofar as spatial reasoning) participating here, we would receive earnest advise that calculating how many cubic yards or cubic meters of beauty bark to order from a landscaper is not a universal skill and the nature of the measure is not as intuitive as some here seem to assume. Greg L ( talk) 22:46, 4 August 2011 (UTC)
Sorry but you are going to have to simplify that for the layman. What on earth does "they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on." mean? Keith D ( talk) 19:07, 3 August 2011 (UTC)
Quantity | US | UK and some∗ of the Commonwealth | Most of the rest of the world |
---|---|---|---|
Length | inch, foot, yard, mile | inch, foot, yard, mile | millimetre, centimetre, metre, kilometre |
Mass | ounce, pound, short ton | ounce, pound, stone, long ton | gram, kilogram, tonne (AKA “metric ton” in the US) |
Time | second, minute, hour, day, week, month, year, decade, century, millennium | same as the US + fortnight | same as the US |
Speed | mile per hour | mile per hour | kilometre per hour |
Temperature | °F | °C | °C |
Currency | US dollar | pound sterling | euro |
Angle | degree, full turn (and simple fractions thereof) | degree, full turn (and simple fractions thereof) | degree, full turn (and simple fractions thereof) |
Power | watt, kilowatt | watt, kilowatt | watt, kilowatt |
Energy | kilowatt-hour, calorie† | kilowatt-hour, calorie† | kilowatt-hour, calorie† |
Voltage | volt | volt | volt |
Volume | US fluid ounce, pint, quart, gallon, litre | imperial fluid ounce, pint, quart, gallon, litre | millilitre, centilitre |
Frequency | megahertz, gigahertz | megahertz, gigahertz | megahertz, gigahertz |
Information | bit, byte, kilobyte, megabyte, gigabyte, terabyte‡ | (same) | (same) |
Am I missing some/including some I shouldn't? My conjecture is that iff a quantity is shown in a set of units such that each cell of the relevant row of this table is represented, then the fraction of readers of en.wiki who would not understand the quantity is negligible. ― A. di M. plé dréachtaí 13:15, 5 August 2011 (UTC)
Can we take some examples *within conversions*:
Do any of those need a link? Lightmouse ( talk) 17:00, 5 August 2011 (UTC)
User:AdiM's table is a good start. However, we still have the problem that some editors assert that units in the 'other system' are obscure and need linking. Can anyone propose guidance text that explains that although '9 millimetres' may be deemed obscure to Americans, it doesn't qualify for a link when in a conversion with the not-obscure '0.35 inches'? Lightmouse ( talk) 17:54, 6 August 2011 (UTC)
As I understand it, Greg was saying km and kg are obscure and require linking. If that's not the case, then I'm fine with that. Following your encouragement and updated Wikipedia:Manual of Style (linking) so the advice that conversions are relevant isn't in a footnote. I've also added a table inspired by yours. If it needs amending, please go ahead. Lightmouse ( talk) 20:27, 6 August 2011 (UTC)
This looks like a nice beginning of a list but I'd say that there are more units to include. Also should the list be context dependant?
A problem with a list of "non-obscure units" is that it might seem to imply that whatever is not on the list is obscure and thus encourage overlinking rather than discourage it. There are so many units out there which are well enough known not to be linked (esp when there a conversion). Is this list the tip of a very big iceberg? ... miles per gallon, litres per 100 kilometres, cubic centimetre, mm of Hg, psi, pascal, foot pound, newton metre, calorie per ounce, kilojoule per gram, tonne of TNT, nauticle mile, hectare, light-year, pixel, megapixel, oil barrel, yen, Aussie dollar, German mark, teaspoon, cup, ... JIMp talk· cont 11:20, 7 August 2011 (UTC)
A link is much less justified *within a conversion*. Above, Jimp highlighted two legitimate concerns:
There is no need to list <not-obscure unit> divided by <not-obscure unit> or <not-obscure unit> squared. The benefit of a list of specific units is that it documents consensus of what the guidance actually means. Please note the 80-20 rule, most of the overlinking problem (say 80%) is due to a few units (say 20%). The 12-row table that User:AdiM proposed would address the majority of the problem.
I'd be fine with that of somebody else's table but for the record, here is mine:
Quantity | Not obscure in US | Not obscure in UK | Not obscure in rest of world |
---|---|---|---|
Length, area, volume | Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes. | Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes. | |
Length, area, volume | Inch, foot, yard, mile. Plus square yard (based on comments by User:GregL but other editors suggest square foot may also be not-obscure to Americans) | Inch, foot, yard, mile. Plus squares and cubes | |
Length, area, volume | Litre | Litre. Plus prefixes milli, centi, kilo, mega, giga. | Litre. Plus prefixes milli, centi, kilo, mega, giga. |
Length, area, volume | US fluid ounce, pint, quart, gallon | imperial fluid ounce, pint, quart, gallon | |
Mass | Gram. Plus prefixes milli, centi, kilo, mega, giga. | Gram. Plus prefixes milli, centi, kilo, mega, giga. | |
Mass | Ounce, pound, short ton | Ounce, pound, stone, tonne | tonne |
Time | Second, minute, hour, day, week, month, year, decade, century, millennium | second, minute, hour, day, week, fortnight, month, year, decade, century, millennium | second, minute, hour, day, week, month, year, decade, century, millennium |
Speed | Mile per hour | <not-obscure unit of length> divided by time | <not-obscure unit of length> divided by time |
Temperature | °F | °C | °C |
Power | Watt, Plus prefix kilo | Watt Plus prefixes milli, centi, kilo, mega, giga. | Watt. Plus prefixes milli, centi, kilo, mega, giga. |
Power | Horsepower | ||
Energy | Kilowatt hour | <not-obscure unit of power> |
<not-obscure unit of power> |
Energy | Calorie. | Calorie. | Calorie. |
Voltage | Volt | Volt. Plus prefixes milli, centi, kilo, mega, giga. | Volt Plus prefixes milli, centi, kilo, mega, giga. |
Frequency | Hertz. Plus prefixes milli, centi, kilo, mega, giga. | Hertz. Plus prefixes milli, centi, kilo, mega, giga. | Hertz. Plus prefixes milli, centi, kilo, mega, giga. |
Information | Bit. Plus prefixes milli, centi, kilo, mega, giga. | Bit. Plus prefixes milli, centi, kilo, mega, giga. | Bit. Plus prefixes milli, centi, kilo, mega, giga. |
Information | Byte. Plus prefixes milli, centi, kilo, mega, giga. | Byte. Plus prefixes milli, centi, kilo, mega, giga. | Byte. Plus prefixes milli, centi, kilo, mega, giga. |
Others | <not-obscure unit> divided by <not-obscure unit> | <not-obscure unit> divided by <not-obscure unit> |
In response to "Can you provide an example division using units from the table that you think requires linking?", some kind of explanation of "kilowatt per year" would be required if we used in the same sense as this PDF. (I'm not sure if that usage makes sense or not, but if it does an explanation is required). The explanation could be in the form of a link, although no "Kilowatt per year" article exists yet. Jc3s5h ( talk) 11:19, 8 August 2011 (UTC)
A good point. You may remember a recent discussion about 'BTU' versus 'BTU/h' ( here and here). I think it's the same issue. Lightmouse ( talk) 12:43, 8 August 2011 (UTC)
Here we are deliberating as to what is to be considered obscure and what is not. Firstly all units which belong to the other system are obscure (the other system is an instrument of the Devil created to cause disharmony on Earth, but we have to put up with it on WP bacuse we can't find any reliable source to back this up ... or even to prove that the Devil exists). Feet are obscure to us, metres are obscure to them, but this is okay since we have conversions. The question is what's obscure to all of us. It depends on context. Now, suppose we have a unit which, in the particluar context, could be considered obscure. Now suppose this said unit has nothing in particular to do with the topic at hand. I must wonder what such a unit would be doing there at all.
Linking days of the week, dates, months, years, we're over it ... unless it has to do with the topic at hand. Linking countries ... we're over this too ... right ... unless it has to do with the topic at hand. What about applying the same rule to units? Obscurity, forget about it; is the unit relevant to the topic? Regardless of how obscure or well known the unit may or be, link it iff it is germane. Even non-obscure units should be linked when they relate to the context. JIMp talk· cont 00:15, 8 August 2011 (UTC)
The template {{
times}} is now available, to display a typographically correct 'times' character (×
in HTML); for eample 4{{times}}100m relay
renders as 4×100m relay.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits
20:11, 6 August 2011 (UTC)
2 × 2
" is easier to read than either "2 {{times}} 2
" or "2 × 2
".
JIMp
talk·
cont
02:12, 9 August 2011 (UTC)
{{times}}
than hit Tab umteen times but are mouseless users (who can't manage ×
either) that significant a group of people that we need this?
JIMp
talk·
cont
10:28, 10 August 2011 (UTC)
×
but can {{times}}
even non-empty? ―
A. di M.
plé
dréachtaí
00:30, 12 August 2011 (UTC)
I have observed a number of editors convert date ranges in the form "1990 to 1991" to 1990–1991, claiming that WP:DATESNO requires that all date ranges use an endash. Specifically, the form "1990 to 1991" is used in some tables where an endash in a date range impedes sorting. Is this a case where the MOS requires a particular form even if it results in broken functionality? Or may date ranges be written in other ways (excluding a hyphen)? Gimmetoo ( talk) 21:39, 6 August 2011 (UTC)
For people previously uninvolved, here's some background information on the issue of dashes/sorting:
Nymf hideliho! 22:23, 6 August 2011 (UTC)
This website shows all versions of Safari accounting for 5.17% of users in July 2011. Of this, Safari 5 accounts for 3.52%, leaving only 1.65% of Internet traffic is using all other versions of Safari. It hardly seems worth our while to convert our filmography tables to a style that does not follow our own Manual of Style to accommodate such a tiny percentage of internet traffic; Safari 4 came out two years ago and even Safari 5 is over a year old and is being replaced with 5.1. This stuff is little used, and Safari 4 is obsolete, antique in internet terms.-- Dianna ( talk) 22:31, 8 August 2011 (UTC)
I tried to just ask the MOS question here, but people keep bringing in other issues. So here is an overview of the problem and solutions identified so far.
There are a number of ways to deal with this issue. Some of them are:
So I would like answers to a few questions:
Comments below. Gimmetoo ( talk) 01:31, 10 August 2011 (UTC)
I believe the user base is large enough to justify some form of fix. I don't think it's appropriate to intentionally make a technical feature misbehave for a significant subset of readers when there are very simple fixes available. To my recollection, WP has supported browsers up to 5 years old. Among the options listed, most editors who are familiar with the issue think the templated sortkey approach is too complex for the scope of this issue. I tend to agree, since much simpler fixes are available. I think the "to" option is appropriately simple for the scope of this issue. (Even if it were against the MOS - and I don't agree it is - I think this would justify a MOS exception.) I'm also fine with a different table structure that avoids the issue, or with reverting to the non-sortable form of the table. Gimmetoo ( talk) 01:31, 10 August 2011 (UTC)
The usage of Safari 4.0 is trivial and will be effectively zero in next to no time, certainly before a significant number of /fixes/ could be deployed. Removing sorting functionality, as Gimmetoo has done, over this tiny issue with a tiny number of readers is flat-out disruptive. I'm amazed at the insistent argumentation over this non-issue. I noticed an odd 'to' in a date range and looked at why, and days later, the insipid argument continues. Use normal endashes and any common browser and all is fine. -- 168.122.165.145 ( talk) 02:23, 10 August 2011 (UTC)
There's been an extensive discussion above. On the basis of the 80%/20% rule, it doesn't matter if we don't have the table complete and/or don't capture all units. It can be updated as required. But the most common 20% of units that are responsible for most of the overlinking and editors need specific guidance. In the absence of any other proposal, I propose the following table
Quantity | Not obscure in US | Not obscure in UK | Not obscure in rest of world |
---|---|---|---|
Length, area, volume | Metre/meter | Metre/meter | |
Length, area, volume | Inch, foot, yard, mile. Square yard | Inch, foot, yard, mile. | |
Length, area, volume | Litre/liter | Litre/liter | Litre/liter |
Length, area, volume | US fluid ounce, pint, quart, gallon | imperial fluid ounce, pint, quart, gallon | |
Mass | Gram | Gram | |
Mass | Ounce, pound, short ton | Ounce, pound, stone, tonne | tonne |
Time | Second, minute, hour, day, week, month, year, decade, century, millennium | second, minute, hour, day, week, fortnight, month, year, decade, century, millennium | second, minute, hour, day, week, month, year, decade, century, millennium |
Speed | Mile per hour | <not-obscure unit of length> divided by time | <not-obscure unit of length> divided by time |
Temperature | °F | °C | °C |
Power | Watt, Plus prefix kilo | Watt | Watt. |
Power | Horsepower | ||
Energy | Kilowatt hour | <not-obscure unit of power> multiplied by time | <not-obscure unit of power> multiplied by time |
Energy | Calorie. | Calorie. | Calorie. |
Voltage | Volt | Volt | Volt |
Frequency | Hertz | Hertz | Hertz |
Information | Bit, byte. | Bit, byte. | Bit, byte |
Other | Prefixes milli, centi, kilo, mega, giga applied to <not obscure SI units> | Prefixes milli, centi, kilo, mega, giga applied to <not obscure SI units> | |
Other | Square and cubes of <not obscure units> | Square and cubes of <not obscure units> |
I've tried to encapsulate all comments. I think it's time to document consensus for adding a table like that, or even a trimmed down version. Lightmouse ( talk) 11:40, 10 August 2011 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Perceived problems of the current guideline as I understand it, excepting for dates within titles and quotations :
I propose that henceforth we stipulate that all dates in the reference sections are uniformly consistent, as provided in this version (click on "show" to see it):
A guideline for uniform display of dates | ||||||||
---|---|---|---|---|---|---|---|---|
These requirements do not apply to dates in quotations or titles. |
Date formats may be the same as prevailing in the body of the text – and may be abbreviated if there are space concerns, or they may be in the yyyy-mm-dd format -- Ohconfucius ¡digame! 09:15, 7 August 2011 (UTC)
I would like to see if a new consensus exists based on the following premises:
- there is no consensus to eliminate ISO 8601 or yyyy-mm-dd date formats from articles, in particular the reference sections
- a mix of date formats in the reference sections is aesthetically unattractive and difficult to parse
- there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for access dates whilst leaving the publication date in dmy or mdy format
- there is little reason to disallow ISO 8601 or yyyy-mm-dd formats for publication dates whilst allowing this for the accessdates
- there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for archive dates should be treated any differently from publication or access dates
- dmy or mdy format using abbreviated months can be equally concise as the yyyy-mm-dd format; the only thing we care about is consistency
- 'reference format' remains undefined and its meaning is unclear.
- tabular form of presentation where examples of dos and don'ts are juxtaposed is starker and more easily comprehended by the reader.
I suggest modifying one bullet and adding a new one; additons are underlined:
Also, change all instances of ISO 8601 to yyyy-mm-dd.
Jc3s5h ( talk) 22:26, 7 August 2011 (UTC), modified 23:57 UT
In answer to a question posed on my talk page, "the format specified in any style guide the reference section follows", the MOS does not address itself to references, except to refer to WP:CITE. That guideline indicates any style may be used for citations. At least one citation style, APA style, calls for one format in the body of articles (Mmmm DD, YYYY,) but a different format in the citations (YYYY, Mmmm DD). To disallow following an external style guide in the reference section would place this guideline in conflict with WP:CITE. Jc3s5h ( talk) 01:45, 8 August 2011 (UTC)
On further consideration, I withdraw my suggestion and instead offer a counter-proposal below. Jc3s5h ( talk) 21:33, 8 August 2011 (UTC)
I suggest removing the text currently in the guideline:
![]() |
![]() |
---|---|
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009 | Jones, J. (20 September 2008) ... Retrieved 5 Feb 2009 Jones, J. (20 Sep 2008) ... Retrieved Feb 5, 2009 |
Jones, J. (20 September 2008) ... Retrieved 5 February 2009 | Jones, J. (20 September 2008) ... Retrieved February 5, 2009 |
Jones, J. (2008-09-20) ... Retrieved 2009-02-05. | Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05 Jones, J. (2008-09-20) ... Retrieved 5 February 2009 |
I would replace it with the following:
Also, I would add a statement to "Citing sources" that all-numeric date formats in which the first element represents the day or month should not be used, regardless of any recommendation in an external style guide, and any article currently using such a system should be corrected. Jc3s5h ( talk) 21:41, 8 August 2011 (UTC)
Would an admin close this discussion? Thanks,
Cunard (
talk)
05:20, 28 September 2011 (UTC)
Would an admin close this discussion? Thanks, Cunard ( talk) 20:25, 14 October 2011 (UTC)
I recently came across a fine example of what I like to call " misconversions". The Gallons per mile section of Fuel economy in automobiles used to read as follows (with a minor typo fixed, the reference removed and the {{convert}} call written out explicitely).
For example, replacing a car that gets 14 mpg-US (17 mpg-imp; 17 L/100 km) with a car that gets 25 mpg-US (30 mpg-imp; 9.4 L/100 km) saves 3 US gallons (2.5 imp gal; 11 L) of fuel every 100 miles (160 km). Because 1 US gallon (0.83 imp gal; 3.8 L) of fuel emits 20 pounds (9.1 kg) of carbon dioxide, saving 3 US gallons (11 L) of fuel every 100 miles (160 km) saves 3 short tons (2.7 t) of carbon dioxide every 10,000 miles (16,000 km) of driving.
I took a look at this through a couple of "filters". Firstly my imperial filter yeilded this.
For example, replacing a car that gets 17 mpg-imp with a car that gets 30 mpg-imp saves 2.5 imp gal of fuel every 100 miles. Because 0.83 imperial gallon of fuel emits 20 pounds of carbon dioxide, saving 2.5 imperial gallons of fuel every 100 miles saves ??? of carbon dioxide every 10,000 miles of driving.
It made me wonder what kind of measure 20 pounds of carbon dioxide per 0.83 imperial gal was. 20 pounds per 0.83 imperial gallon. What fancy number is 0.83?
Then I tried on my metric filter. Here's what I got.
For example, replacing a car that uses 17 L/100 km with a car that uses 9.4 L/100 km saves 11 litres of fuel every 160 kilometres. Because 3.8 litres of fuel emits 9.1 kilograms of carbon dioxide, saving 11 litres of fuel every 160 kilometres saves 2.7 tonnes of carbon dioxide every 16,000 kilometres of driving.
"Wow!" though I. Even more fancy numbers. 11 litres per 160 kilometres times 9.1 kilograms per 3.8 litres equals 2.7 tonnes per 16,000 kilometres. Now, I'm feeling much enlightened. 'Cause here in metricland we always measure things by the 3.8 litre and the 1.6 kilometre.
Another thing we tend to to, here in metricland, is measure food energy density in kilojoules per 450 grams. For example, I like to eat Foobars but I'm getting fat because they contain 420 kJ (100 Cal) per 450 grams (1 lb). I also drink Foozypop which contains 630 kJ (150 Cal) per 355 ml (12 US fl oz).
Well, I rewrote the example to give litres per 100 kilometres, pounds per imperial gallon, kilograms per litre, long tons per 10,000 miles and tonnes per 10,000 kilometres. I also tweaked the numbers for accuracy, tweaked the wording for flow and came up with this.
For example, replacing a car that gets 16 mpg-US (19 mpg-imp or 15 L/100 km) with a car that gets 30 mpg-US (36 mpg-imp or 8 L/100 km) saves 3 US gallons (2.5 imp gal) of fuel every 100 miles (7 L/100 km). Because the combustion of 1 US gallon of fuel emits 20 pounds of carbon dioxide (burning 1 imp gal emits 24 lb and burning 1 L emits 2.4 kg), this saves 3 short tons (2.7 long tons) of carbon dioxide every 10,000 miles (1.7 t every 10,000 km) of driving.
This might well be the worst I've see but it's not the first. I wonder whether it's worth adding guidance regarding the conversion of such ratios imbedded in text. Converting the ratio as a whole rather than converting its parts individually seems such common sense to me but I guess it's not so for everyone. What might be a good way to phrase it? JIMp talk· cont 10:19, 7 August 2011 (UTC)
At present, the following is given: A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). Given that I have never seen this requirement in academic works, in fact, the opposite exists, years are normally expressed in full. FWiW Bzuk ( talk) 17:46, 11 August 2011 (UTC).
I brought this up recently. The resulting discussion is probably in the archives somewhere. My position is that short date ranges are more commonly written with two closing digits (e.g. 1914-18 and 1939-45), but that writing it out in full is also common. I think that when writing out a person's birth and death years, it is vital to write the death year out in full no matter what the context. This is because these years are so central to identifying people, especially those with the same or similar names. It is also a matter of style. Aesthetically, it looks better if the closing year is uniformly written the same way, not varying depending on the context, so the full closing year is best. Finally, as a reader, when looking for information in an article or list, I often know the year something happened and search for that to find it in the article (often I find people have neglected to name the year and that is something that can be corrected). Similarly, when trying to identify people (often relatively obscure 19th century naturalists) when I have a name and no birth or death year, I sometimes find what might be the birth or death year, and then do a new search including that year, and get the results I need. For obvious reasons, it is best to be able to search on the full year, not an abbreviated version. Carcharoth ( talk) 15:55, 29 August 2011 (UTC)
Please see WT:CITE#Which Wikipedia guideline(s) should establish citation format? Jc3s5h ( talk) 16:59, 13 August 2011 (UTC)
Per MOS biographies, I added a note that if the full dates are provided by an infobox or in the text of the article, a simple span of years is sufficient in the lede. This follows the general principle of reducing clutter in the lede. Although I have added quite a few pronunciations to biography articles, I would encourage those to be moved to an infobox as well. (This has been done systematically with astronomical bodies.) — kwami ( talk) 23:24, 21 August 2011 (UTC)
<ref>
tags is a very bad idea, as it's impossible for readers to anticipate that the footnote contains stuff other than a citation of a source. With <ref group="Note">
, on the other hand... ―
A. di M.
plé
dréachtaí
10:01, 25 August 2011 (UTC)
{{#tag:ref||group="note"}}
to the 'Wiki markup' edit window for just these situations. Unlike <ref group="Note">
, #tag:ref allows you to place <ref>
tags in the notes themselves. —
kwami (
talk)
10:23, 25 August 2011 (UTC)A couple of points. Firstly, all the discussion about pronunciation and non-MOSNUM stuff should either be discussed at a different location or unified in a single discussion. In other words, if sweeping changes are to be made to the way biographical articles are written on Wikipedia, a discussion should be opened at WT:BIOGRAPHY and possibly notification left at WP:CENT given the massive number of biography articles on Wikipedia. Also, it would help if a preliminary audit gave an idea of the number of articles this would affect, and how many use the current style? A further point is that many biography articles don't use infoboxes, so it is best to leave infoboxes out of the discussion, or state what should be done where there is no infobox. My view is that a discussion should be undertaken to settle on the style used on biographical articles, rather than piecemeal discussion of different aspects in different places (year range in lede at MOSNUM and pronunciation at PRON is a classic example of splitting up a discussion that should be done altogether in one place). But that discussion should take place at the Biography WikiProject pages, not at MOSNUM. Possibly Wikipedia talk:Manual of Style (biographies) is a another venue, but it is vital that input is obtained from those who write biography articles on Wikipedia, rather than those who write manuals of style. My view is that having the birth and death dates in the lead is fine, but everything else should be seen as clutter and relocated. The reason I think birth and death dates should stay in the lead? Because if you remove them, the lamest edit wars you can imagine will break out between people who want to write 1832-1895 and those who want to write 1832-95. Seriously (and that is on-topic for this page!). Carcharoth ( talk) 01:00, 29 August 2011 (UTC)
{{
cite journal}}
: Missing or empty |title=
(
help)
Is there a policy on abbreviating the word "number"? In articles concerning rail transport, I often see text concerning individual locomotives. Rail locomotives are normally identified by number, and so this text is usually like "No. 123 was built in ..." but sometimes I see text like "Nº 123 was built in ...". Do we have a policy on whether one of these forms is preferable to the other? -- Redrose64 ( talk) 18:48, 24 August 2011 (UTC)
Perhaps opinions vary, but I usually avoid all abbreviations. My pet peave is "aka" which slips in too many times. Unlike other encyclopedias that are limited by paper, we should have no constraints. On the other hand, there might be some domain-specific styles that use certain well-known abbreviations almost exclusively, the one I think of is HMS or USS for ship names- these are almost never spelled out. You might also discuss at a relevant project page. But when in doubt, spell it out. W Nowicki ( talk) 23:01, 24 August 2011 (UTC)
We're informed that it was agreed to move MoS pages to subpage format, which means this page ought to be called Wikipedia:Manual of Style/Dates and numbers. I can't move it since it's move protected - can someone with admin rights do it (or does someone want to object?)-- Kotniski ( talk) 11:25, 30 August 2011 (UTC)
No need to worry about numerical pages. Most talk pages deem a search box sufficient for access to archives. Lightmouse ( talk) 15:21, 3 September 2011 (UTC)
I was puzzled by this guidance: When only the years are known, or days and months would be irrelevant detail: "Socrates (470–399 BC) was..."
Under what circumstances would days and months be an irrelevant detail? I assume we omit the exact dates of Socrates' life because we don't know them, not because they're irrelevant. Why would they be irrelevant? Because dates of people who lived long ago are automatically not relevant, and dates of people who live or lived more recently are automatically relevant? Now that I think about it, if we're making determinations based on relevance, it's hard for me to see the relevance of including the birthdates (beyond the year) of the vast majority of living people who are the subject of Wikipedia articles.
I suggest deleting the phrase about "irrelevant detail," but if there is some meaning to it that I'm missing, I suggest the guideline be clarified to explain the distinction between relevance and irrelevance. Theoldsparkle ( talk) 15:23, 6 September 2011 (UTC)
Well, it's not that simple. The statement "Joe Shmoe (birth - death) was..." is at the intersection of WP:MOSBIO and WP:MOSDATE.
There have been a lot of discussions regarding the parenthesized vital information traditionally following a person's name in biographical articles. There was a huge discussion on this last year: Wikipedia talk:Manual of Style (dates and numbers)/Archive 132#So what IS the deal with birth/death locations in the opening? (ignore the section title and opening section and jump down to the "Staw Poll" subsection). Over 80 editors participated so this is the operative discussion in my opinion.
Anyway... Some people feel it should be "Charles Robert Darwin (12 February 1809 – 19 April 1882) was..." and some that it should be "Charles Robert Darwin (1809 – 1882) was...". And there's no agreement on this, so people do what they they think best. The problem is, one might infer from the example used in MOSDOB that there's a prescription to give the day and month, and that's not true. But if you changed the example to give only the year, that would possibly imply that there's a prescription to not give the day and month, and that's not true either.
It's confusing. There is absolutely not a consensus to use the day and month in the parenthesized vital information. The examples show this, but only because the examples have to show something.
MOSBIO handles this much better, but MOSBIO also has a failing: it says nothing about the parenthesized vital information. It only talks about the lede paragraph as a whole. (The examples there show parenthesized vital information, leaving one to possibly infer that they're at least recommended, but that's it.) If you go by MOSBIO -- what's written, not the examples -- the following lede would be perfectly within the MOS:
We need to combine the strengths of this two complementary sections, in one place. Here's what I think: MOSDATE should get out of the biography business. (Either that, or MOSBIO should get out of the date business (which would be a lot harder, I think).) MOSDATE's job is telling what kind of dash should separate two dates when they appear in succession, and what kind of punctuation should separate the day from the month and the month of from the year when a full date is given, and so forth. And that's it. It should not saying, or even implying through examples, what level of detail is to be given to the parenthesized vital information at the start of of an article, or whether biographical articles should have the death date in the lede or at the end, and so forth. That's MOSBIOS's job.
It's certainly not a good idea to have two different MOS's talking about the same thing and not agreeing, which is the case now, at least arguably (depending on whether you think examples imply prescription, which I think a lot of people think they do unless this is overtly disclaimed).
This has been a headache for years, and a constant source of confusion. It's time to put paid to this. I propose to work up an RfC on this presently. Herostratus ( talk) 06:11, 21 September 2011 (UTC)
Maybe I've missed it somewhere, but I see no direct information regarding the use of the word "present" in section headers. For example, I see many headers that list an event that occurred over a series of time and listed as (1980-present). I'm thinking that the same train of thought that applies to use of the word "currently" would also apply here but I'd like to be sure. Would that same rule apply that applies to the article body also apply to the section headers? NJZombie ( talk) 18:23, 8 September 2011 (UTC)
Note that, contrary to the dates section of this manual, the logon screen today reads:
With superscript. — Robert Greer ( talk) 16:52, 18 September 2011 (UTC)
The plural of euros has been discussed so many times (see the archives of this talk page). Following the latest edit [8] we are now being told the plural is euro. But is the fragment "it is easier to pay for eggs in euro" really in the preferred form? Linguistic issues concerning the euro is sympathetic with "euros" and A handbook for authors and translators in the European Commission (at 20.9) is definite. Also, although I can imagine someone writing "a two-euros pen", English adjectives are not inflected and people do not need to be told this here. Could we not delete this whole bullet point as being far more bother than it is worth? Thincat ( talk) 17:09, 2 October 2011 (UTC)
I would like to see a statement here regarding the use of the South Asian numbering system in articles. For example the article Ajay Kumar, it says he won by "1.55 lakh votes", is acceptable style? Kevink707 ( talk) 17:03, 10 October 2011 (UTC)
I'm not sure how (or where) to address this concern. Basically, I'm asking if infoboxes such as "{Infobox cemetery}" need lines for both Lat/Long entries and coordinates. (I've posted a comment on the particular infobox discussion page Template talk:Infobox cemetery.) Comments welcome. -- S. Rich ( talk) 04:56, 11 October 2011 (UTC)
Hey all.
I wonder if there is anyone who agrees with me, when I question the current DATERET guidelines. I regularly come across articles that have absolutely no relation to US or Canada, and still have a date format that is distinctly North American (or even US, as Canada have both formats). These articles – on topics that are Russian, German, Spanish, Japanese, Danish, or whatever – were probably once created by an American wikipedian, using his/her own habitual date format. That is no reason for those articles to have a US-centric date format, but the current guidelines seem to prevent changing the articles to a more appropriate format.
Wouldn't it be better if the "Strong national ties" section of the guidelines was altered so that it was permissible to alter the date format to a more appropriate one? (Changes could obviously go both ways.) I mean, just because the first major editor, probably unknowingly, made a poor choice of format, should the article for ever be doomed to keep that? If I had started the article on Tiger Woods or Bill Clinton using the international date format, would that be right?
HandsomeFella ( talk) 19:48, 14 October 2011 (UTC)
Questions are in regard to WP:ASOF. It doesn't look like that page sees much traffic, so posting here instead.
Any responses are appreciated. Thanks, Nightw 14:30, 17 October 2011 (UTC)
In Wikipedia:DATESNO it states that the ordinal suffix is never used, but I was told here that there is an exception when the date is preceeded by the day of the week. Is there an exception to this rule? If so, we should cover it here. Thank you. Frietjes ( talk) 15:13, 18 October 2011 (UTC)
Which of these is correct:
The only guidance given is that "September, 1944" is wrong and "September 1944" (no comma) should be used instead. This tells me to remove the comma in that case, but doesn't tell me to remove the "of" if it exists.
I'm fine with "whatever". I think that "...in September of 1944, the..." sounds better and is more idiomatic, but I don't much care. Am I correct in believing that there is no guidance and editors are free to do as they prefer, right? (In which case other editors shouldn't correct whatever the previous editor decided, generally.)
If there should be a standard, it should be added as an entry in the table in the "Dates" section - Incorrect = June of 2001, Correct = June 2001. Herostratus ( talk) 18:35, 21 October 2011 (UTC)
Just to clarify, I don't think there needs to be a standard. I don't believe in getting down to the level of detail where the MOS is telling editors they can never write "One of the many..." and must always write "Among the many..." instead, and so forth. (It might be nice to make a notation to the effect of "There is no preference between 'September 1944' and 'September of 1944', do as you wish", to clarify the situation.) But is editors think it should be specified that'd be OK I guess. Herostratus ( talk) 18:51, 21 October 2011 (UTC)
You are invited to join the discussion at
Template talk:Convert#Numbers greater than 0 but less than or equal to 1 should use singluar nouns.
― A. di M.
19:12, 24 October 2011 (UTC)
The discussion here may interest some of you. The question is whether it is appropriate to revert an editor who used a consistent date format in refs in an article. So that instead, inconsistent date formats exist (even within the same refs).
Some guidelines at issue are WP:DATESNO, WP:STRONGNAT, and Wikipedia:Citing sources.-- Epeefleche ( talk) 06:44, 28 October 2011 (UTC)
Where the refs section, for example, of an article uses 3-letter abbreviation for the month:
An editor inserted this:
I think this is probably correct but I'm not certain and just wanted to see if there was any objection. If anyone objects to this here would be the place to so state. Herostratus ( talk) 20:09, 19 November 2011 (UTC)
Well, it'd be good to ask Art LaPella on that one, since it's his example, and because I'm not 100% confident on that usage. However, I believe I would employ the comma (in his as well as in your simplified example), as I'd wish to communicate to the reader that the usual word order (subject-verb-object(s)) is being changed. — JohnFromPinckney ( talk) 22:53, 22 November 2011 (UTC)
A bit of a conflagration at Neolithic Revolution has made me realise that the current wording of WP:ERA:
Is slightly ambiguous about what reasons there can be for changing from one style to the other, especially for new editors who aren't totally familiar with our nuanced definition of "consensus" (i.e., it isn't a vote, it's limited, and it should be based on policy). I understand why the wording was changed early this year from a version that was slightly more clear in that regard, but User:Cynwolfe has already suggested a version that gives us the best of both worlds (w/ some slight alterations):
Can we go ahead and add this? joe•roe t• c 12:07, 1 December 2011 (UTC)
There is a discussion at convert regarding foot-pounds and pound-feet. A number of points raised there deserve a broader consensus that convert's talk page provides.
What're your thoughts? JIMp talk· cont 06:21, 5 December 2011 (UTC)
I agree absolutely that it should be a middle dot separating "ft" and "lb", not a hyphen, not a bullet and definitely not a slash (lb/ft is pounds per foot and ft/lb is feet per pound). However, none of these should be capitalised. Thus it's "ft·lbf" or "ft·lb" and "lb·ftf" or "lb·ft" (or "ft·lbf" and "lbf·ft"). This is in accordance with MOSNUM.
- When unit symbols are combined by multiplication, use a middle dot (
·
) or a non-breaking space (
) to separate the symbols. ...- Unit symbols/abbreviations, apart from those listed below, are written in either non-alphabetic characters or in lower-case letters unless they are derived from a proper name, in which case the first letter is a capital letter. ...
Scheinwerfermann, it would seem you prefer "lbf" over "lbf" or am I misreading you? Should we insist on one? Should we insist on the other?
It has become established practice that we follow the sources. As it is an encyclopædia we're cobbling together, our preference ought to be for the more scholarly source. Assuming that your collection, Scheinwerfermann, is representative of current literature, it seems we have a solid case for adopting Worthington's convention here. Much less the harm if we err in favour of unambiguity. I support restricting "foot-pounds (force)" to energy and "pound (force)-feet" to torque on WP. Further, I support the general case of restricting length-force units to energy and force-length units (e.g. newton-metres) to torque. I propose adding this to the guideline.
How about the "force" in "foot-pounds (force)" and "pound (force)-feet"? Is it manditory, preferable, context dependant,, completely optional, undersirable or to be banned entirely? Is the "force" in "foot-pounds (force)" to be given equal weight as that in "pound (force)-feet" or are they to be given unequal footing? Scheinwerfermann, do I read you wrong that you'd accept "pound-feet" ("lb·ft") but not "pound force-feet" ("lb·ftf") but you find both "foot-pounds force" ("ft·lbf") and "foot-pounds" ("ft·lb") acceptable? JIMp talk· cont 00:46, 6 December 2011 (UTC)
I have proposed adopting the convention that a unit written as length times force is a unit of energy and a unit written as force times length is a unit of torque. There being no opposition to and clear advantages in so doing let us add this to the guideline. JIMp talk· cont 02:51, 9 December 2011 (UTC)
I have added the following to WP:MOSNUM#Unit names.
When units of torque or energy are formed by multiplication of a unit of force with a unit of length, distinguish these by putting the force unit first for torque (e.g., newton-metres or pound-feet) and the length unit first for energy (e.g., foot-pounds or foot-pounds force).
JIMp talk· cont 08:19, 9 December 2011 (UTC)
Having just added pound-moles to {{ convert}} and wondering whether we abbreviate it as "lbmol", "lb-mol" or either, I brought the question up at MOS Chem. JIMp talk· cont 03:18, 8 December 2011 (UTC)
All editors are reminded that voting closes for ACE2011 in just over a day's time (Saturday 10 December at 23:59 UTC). To avoid last-minute technical logjams, editors are asked to vote at least an hour before the close, that is, by:
For the election coordinators. Tony (talk) 13:05, 9 December 2011 (UTC)
Minor question regarding WP:DECADE: It says that four digits (1960s) are preferred over two digits (60s), which makes sense. I've got an article that has "1960s and 70s". That seems superior to "1960s and 1970s". Should WP:DECADE identify that as a permissible use of 2 digits, or is that too obscure? -- Noleander ( talk) 17:49, 9 December 2011 (UTC)
Section 2.5 states: "Forms such as the 1700s are normally best avoided since it may be unclear whether a 10- or 100-year period is meant (i.e. 1700–1709 or 1700–1799).". I agree, but no alternative form that should be used is provided. I have been using, for example, 'first decade of the 21st century'; I imagine others might use something else. An agreed upon alternative to 2000s would be helpful if stated here in the MOS. Thanks Hmains ( talk) 20:51, 12 December 2011 (UTC)
I see no guidance on abbreviating this currency, but have always seen it as RM. Ulf Heinsohn has made a series of edits changing it to script ℛℳ, in this edit to Nibelungen Bridge (Regensburg) with the edit summary "typo", elsewhere, (for example this edit to Festhalle Viersen) also replacing Reichsmark with German gold mark and referring only to that change in the edit summary. I believe he's right to regard Reichsmark as anachronistic in those cases, but what is the policy on the script rather than plain text abbreviation? I wanted to determine whether there was one before raising the issue with the editor. Yngvadottir ( talk) 19:01, 13 December 2011 (UTC)
According to Wikipedia:MOSNUM#Large_numbers, millions is abbreviated to upper case M, but billions is abbreviated to lower case bn. This strikes me as being inconsistent (and thus contrary to one of the general rules of MOS). Should we use consistent case? Is there a specific reason why the case is different here? Mitch Ames ( talk) 13:28, 14 December 2011 (UTC)
For what it's worth, I was thinking about currency, eg $20m or $20M, when I raised the matter. Here are the relevant , comment and revert. Mitch Ames ( talk) 12:02, 16 December 2011 (UTC)
There is a discussion of the application of STRONGNAT here, which may interest some readers of this page.-- Epeefleche ( talk) 16:41, 14 December 2011 (UTC)
I've never seen any real consensus to accept sloppy, lazy crap like "30 Sep 2009" and "Sep 30 2009". Not here, not at WP:MOSABBR, not in years and years of debates about date formatting and autoformatting. I correct this mess to proper date formatting every time I encounter it, and this is getting increasingly tedious. Now I know why: Some joker added this to WP:DATESNO on a whim, and it's consequently attracting lazy editors to follow its bad advice. Even the allowance of ISO dates for accessdates is a bad idea with a lot of negative consequences (everyone and their dog has been using them for publication dates in citations, too. Often enough to be worrisome, non-technical non-Americans, used to day-month order in prose wrongly put 2009-30-09, which is "fatally" problematic for any day number under 13.
But this month abbreviation garbage is going to far. For one thing, there's no universal standard. Some people like any of "Sep", "Sep.", "Sept" and "Sept." among probably others. It's a total nightmare for reusability (e.g. parsing by bots). It's even worse for non-native English speakers who don't automatically recognize inconsistent abbreviations through long familiarity. And it's just sloppy, and lazy. It's going to spread to article prose (already is - I've undone it in articles many, many times). There are already too many date formats here. Even being American, I'd prefer we standardized on 30 September 2009 format and deprecated ALL others. At least clean up this particular mess:
=====In references===== {{See also|Wikipedia:Citing sources#Citation style |l1="Citation style " section in "Citing Sources"}} * Publication dates in article references should all have the same format. :In the same article, write :{{xt| :*Jones, J. (20 September 2008) :*Smith, H. (August 2002) :*Garcia, M. (4 May 1999} }} :or :{{xt| :*Jones, J. (September 20, 2008) :*Smith, H. (August 2002) :*Garcia, M. (May 4, 1999} }} :but not :{{!xt| :*Jones, J. (20 September 2008) :*Smith, H. (August 2008) :*Garcia, M. (May 4, 1999} }} *Access and archive dates in references should be in either the format used for publication dates, or YYYY-MM-DD. :In the same article, write :{{xt| :*Jones, J. (20 September 2008) ... Retrieved 5 February 2009. }} :or :{{xt| :*Jones, J. (September 20, 2008) ... Retrieved 2009-02-05. }} :but not :{{!xt| :*Jones, J. (20 September 2008) ... Retrieved February 5, 2009. }} These requirements do not apply to dates in quotations or titles. }}
Made the examples a bit clearer in the process.
I would (severably) also prose elimination of ISO dates as acceptable for anything, including tables if the current table sorting code can work around the need for being able to sort by date, which appears to be the case. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 15:15, 16 December 2011 (UTC)
There is currently a discussion taking place at WT:HWY regarding the potential use of coordinates in highway articles. Your input is welcomed. -- Rs chen 7754 01:30, 26 December 2011 (UTC)
I have been editing quite a few articles about English villages recently, and a question has arisen in my mind regarding the use of hyphens in centuries. Am I right in thinking that when a century is used as a noun, there is no hyphen between the number denoting which century it is, and the actual word "century", whereas a hyphen is required when the century is used as an adjective (e.g. "the church was built in the 15th century" [used as a noun], contrasting with "a 15th-century church" [used as an adjective])? I could find no mention of this issue in the MoS. PaleCloudedWhite ( talk) 01:27, 28 December 2011 (UTC)
Thanks. I didn't look at that section; I didn't read far enough down the page (I just looked at the bits about calendars etc.) That'll teach me to draw rushed conclusions about a topic not being in the MoS (although finding the required information isn't always easy!) Still, it does back up my own deduction... PaleCloudedWhite ( talk) 08:57, 28 December 2011 (UTC)