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 125 | ← | Archive 128 | Archive 129 | Archive 130 | Archive 131 | Archive 132 | → | Archive 135 |
Talk:Sharon Johnston lists the issues. Feel free to add to the discussion there. -- Walter Görlitz ( talk) 16:53, 7 August 2010 (UTC)
Wikipedia lists distances in American articles about roads. I added metric units but was reverted. When I queried this, I was told that it had been discussed in the a subsection of the manual of style:
There is nothing in the MOS that forbids it but I was told it was the de facto standard following those discussions. I read the discussions and still think that it should be permitted to use metric units for distances in a table. I can understand that there might be something special about "milepost 17" but I can't see what is special about "the second exit is 1.8 miles from the origin and the third exit is 2.4 miles from the origin". What do other people think? Lightmouse ( talk) 21:39, 1 August 2010 (UTC)
The phrase "every time it occurs" was intended to apply to repeats of the same value. This is not the case with a table of different distances. When you say that some felt that metric units clutter the table, were those people from metric countries? Lightmouse ( talk) 21:56, 1 August 2010 (UTC)
It is way too much clutter, especially for really lengthy junction lists. -- Rs chen 7754 00:11, 2 August 2010 (UTC)
Requiring the roads projects to include both units of measure in all junction lists amounts to requiring roads editors to do a lot of extra work (some junction lists have hundreds of junctions) that would provide a very small benefit, or none at all. -- Rs chen 7754 07:46, 2 August 2010 (UTC)
Ah, it sounds like a resolution is possible that doesn't include 'require' or 'forbid'. It's now merely a matter of preferring separate columns. Lightmouse ( talk) 11:10, 2 August 2010 (UTC)
I haven't kept up with this current issue about metric conversions, but I wonder why an exception should be made for just this field. I accept that space is at a premium in tables, but other tables manage metric and US customary conversions perfectly well. The slight addition to "clutter" is just something we have to live with internationally when English-speakers have a dual system.
The Capitol Loop table seems to be ideal for adding conversions: the first two sub-columns would need very minor increases in width, and there appears to be no space crisis in the other columns, which could be narrowed a little if people want to retain the current overall width.
I am particularly concerned about the "slippery slope" implications of denying the many international readers, including many native English-speakers, easy comprehension of the distances. Tony (talk) 15:40, 2 August 2010 (UTC)
To me, this seems like a clear case where having the conversions is excessive. I'd post the appropriate text of MOS:CONVERSIONS here, but someone's already done so. Also, I don't see why the lack of miles in, say, Canadian junction lists isn't being discussed as an "issue" here. If you're going to "suggest" junction lists using solely imperial units be saddled with metric clutter, I don't see why junction lists using just metric units shouldn't be saddled with imperial clutter. (As an aside, RJL-style, milepost-only tables have been brought through FAC 29 times, and if conversions for each milepost were truly mandatory, I'm sure someone would have required them by now.) – T M F 16:09, 2 August 2010 (UTC)
I'm not a fan of a footnote. For me, it makes the mile column unacceptably wide. It would also require the addition of a footnote section to every article that doesn't have one, and for the US alone, that number is in the several thousands. I also can't justify adding a section everywhere just for one short footnote. Perhaps a better option is to put the note in the table footer instead. – T M F 21:54, 2 August 2010 (UTC)
To all the people who are pushing for these useless metric conversions, I hope that you would be willing to update pages such as Interstate 5 in California, where the table is hardcoded, rather than just making more work for us editors who actually edit the road articles and who really don't see a need for metric conversions. If foreigners want to drive on American roads, they will have to deal with the US system of measurement already. -- Rs chen 7754 04:20, 3 August 2010 (UTC)
This is a perennial proposal; it was debated three years ago exactly. I agree with a lot of the points that were made there in opposition to requiring both mi and km. The perception that it results in "number soup" is one I share (I could see myself mixing up the columns upon reading them). I find Holderca's posts very relevant—as he says, the guide signs, odometers, and distance markers in the United States are all in miles, so the km conversions would be functionally useless to anyone attempting to apply them while visiting the road. km conversions are already listed in the infobox and route description, so users just wanting a conversion to "fix the distances in their head" would be adequately served by those. In any event, if this is forced through, I hope there's one of these pro-conversions people willing to apply the conversions to all 12,500 U.S. road articles. I doubt you're going to find anyone in the road project willing to spend their time doing something so menial resulting in such a marginal improvement to the articles. — Scott5114 ↗ [EXACT CHANGE ONLY] 05:11, 3 August 2010 (UTC)
Adding metric conversions to US articles will not increase their readership. The distances on the roads are based on miles, the speed limits are in miles, the government posts the lengths in miles (which if the fractions of lengths are converted to kilometres and added up, they probably would not be equal), and the cars show miles in larger print than kilometres. On the flip side, for every other country except basically the UK, metric is the ONLY system of measurement. I refuse to convert the Ontario articles to show imperial - Canada hasn't used in for 40 years, and 95% of the planet is in the same position. If you feel like converting all the distances at I-10 in Texas or Highway 401, be my guest... but I will probably revert it if it looks like crap and clutters the table with useless and repetitive information. - ʄɭoʏɗiaɲ τ ¢ 14:55, 3 August 2010 (UTC)
Let me make a good comparison using an example we all know. Angel Falls in Venezuela is the tallest single drop in the world. That drop is 807 metres of the 979 metre total drop. For me, this is fine and dandy. For an American, it means diddly, so we convert it to feet. AHHH! There we go, 2,648 ft out of a total of 3,212 ft. Makes sense now! By comparison, the distance I travelled along I-90 last spring through Pennsyvania was about 45 miles. The sign said it as soon as I got there. Did I sit there to convert it to km so I could say "Oh ok, now I can gauge that distance"? No, because the speed limit is in miles. If I converted one, I'd have to convert everything, but in the end I'd get the same result - About a 45 minute drive at the maximum speed limit. Knowing the km between two points measured in miles is pointless, because you can't use that converted value for any purpose. When you see the next sign saying "Ohio - 28", you're dealing with 28 miles, but you've already come 28 kilometres, but only 17 miles, so you have... hmmm... 28 miles to go until you're in Ohio. If the pure statistic of the kilometric distance is that important, you can pick an exit number and convert it. - ʄɭoʏɗiaɲ τ ¢ 16:31, 3 August 2010 (UTC)
I was just wondering is there a MOS guideline on timeline dates in contents lists. 2010 Russian wildfires and also an older version of 2010 Northumbria Police manhunt highlight the problem. Depending on the date formatting used, the numbers look very messy when you end up with a list like..
2 Timeline
2.1 29 July
2.2 31 July
2.3 1 August
2.4 2 August
2.5 4 August
2.6 5 August
2.7 6 August
2.8 7 August
I would think this has come up before, but can not find anything stating how these sorts of things are meant to be handled. thanks BritishWatcher ( talk) 21:16, 7 August 2010 (UTC)
It's a sequence of events. The heading should emphasise the event name, the time of the event is a characteristic of the event and is secondary. Lightmouse ( talk) 11:47, 8 August 2010 (UTC)
Thanks. I also agree with you that the 24 hour clock is useful, particularly for data, transport, sequences, tables, timestamps. Lightmouse ( talk) 12:38, 8 August 2010 (UTC)
In a recent edit summary Wjemather stated "it is ISO format regardless of whether WP has adopted the standard or not. Added clarification". As a counterexanple, consider Microsoft Excel for Windows. It treats text entered into the current cell in the YYYY-MM-DD format as dates provided the date is on or after 1900-01-01; it treats earlier dates as text strings. Thus this widely used format is not equivalent to ISO 8601.
One facet of this topic where I have had no luck finding reliable sources is whether the people or government of any country ever adopted the YYYY-MM-DD format independently of ISO 8601, with different or unstated rules. I would appreciate being informed of any sources that address this.
P.S.: yes, I know about Excel's leap year difficulties. Jc3s5h ( talk) 20:34, 12 August 2010 (UTC)
::VariantChangeType
to see whether that is an underlying feature of that API or specific to Excel, but I don't see how it matters to the argument anyway, since it manifests as a feature of the user input interface and has nothing to do with how dates are displayed or stored.
Si Trew (
talk) 20:58, 12 August 2010 (UTC)YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose [...] However, they may be useful [...] . Because it might be thought to be following the ISO 8601 standard, this format should only be used for dates expressed in the Gregorian calendar and for the years from 1583 through 9999.
{{
cite/doc}}
for that template's accessdate parameter, but no longer are; {{
cite book/doc}}
does show such a use in its examples, as does {{
cite journal/doc}}
, and I imagine others do too.)Months are expressed as whole words (February, not 2), except in the ISO 8601 format (YYYY-MM-DD)
Just a side comment that I feel I should make. It is only my opinion, but this whole argument is getting kinda lame in my book. Call the damn things "ISO style date format" and move on. The usage may not be 100% compliant with the applicable ISO standard nor have we formally adopted the standard. Personally, I think the things should be excised from display text except where appropriate. Use them to set up sorting in tables using {{
sort}} and display the content in another format, but get rid of them in most other cases. Running prose and footnotes should be using a single, consistent date format that's used in the sources appropriate to the topic. Rarely is space a concern in footnote formatting, unlike some tables. I can see using ISO style dates in some topics, but they really should not be in use in many topics.
Imzadi
1979
→ 01:17, 13 August 2010 (UTC)
Guy Fawkes Night, also known as Bonfire Night, is an annual celebration held on the evening of 5 November to mark the failure of the Gunpowder Plot of 1605-11-05.
{{
cite journal/doc}}
and {{
cite book/doc}}
not to use the YYYY-MM-DD format, and checked {{
cite news}}
, {{
cite/doc}}
({{Citation/doc}}
), {{
cite web/doc}}
and {{
cite thesis/doc}}
which were OK anyway. Any others?
Si Trew (
talk) 06:54, 13 August 2010 (UTC){{cite}}
templates used to stipulate YYYY-MM-DD format, now they do not (the ones I mentioned state that they should use the format used in the rest of the article.) I can't find where in the history this was changed, but I assume that the stipulation for YYYY-MM-DD was removed. In that case, considering that MOSNUM already discourages using this format, and that it is only the examples that uses it and not the description of the parameter, I imagine it was just an oversight not to change the example. In any case, I don't see how it pre-empts the outcome of this dicussion here; I mentioned the cite templates as an aside; this discussion is about whether the term "ISO 6801" is required or not.
Si Trew (
talk) 15:33, 13 August 2010 (UTC)The current state "the ISO 8601 compliant YYYY-MM-DD format" is perfect. -- Walter Görlitz ( talk) 13:58, 13 August 2010 (UTC)
Please permit me to take this conversation a step backward. The statement is about not padding month numbers except when used in YYYY-MM-DD format. How can we word it so that we exclude this ISO 8601 standard debate? -- Walter Görlitz ( talk) 21:35, 13 August 2010 (UTC)
IMO "from N1 to N2" and "N1..N2" should be preferred over "between N1 and N2" to avoid ambiguity, since "between N1 and N2" can be used colloquially to men either "greater than N1 and less than N2" or "equal or greater to N1 and less than or equal to N2" is used colloquially to mean could mean "between N1 and N2 exclusively" or "between N1 and N2 inclusively". It's generally not a problem with narrow ranges (for example it would be unusual for someone to use "between 2 and 4" as a verbose way of saying "3"), however it's less clear for broder ranges (for example the corvidae article contains the statement that "Corvids can lay between 3 and 10 eggs", which could be interpreted as either a needlessly awkward and ambiguous way of saying "3 to 10 eggs" or an even more needlessly awkward and ambiguous way of saying "4 to 9 eggs"). -- Gordon Ecker ( talk) 06:37, 11 August 2010 (UTC)
Use a non-breaking space (also known as a hard space) to prevent the end-of-line displacement of elements that would be awkward at the beginning of a new line:
When would you ever write "7 World Trade Center"? For one, "7" should be spelt out and two, why would you need a non-breaking space there? McLerristarr (Mclay1) ( talk) 12:44, 13 August 2010 (UTC)
There is a discussion at User talk:Art LaPella#Your AWB edits concerning whether WP:NBSP should be applied within date parameters of a citation template as in date={{Nowrap|6 November}} 2010. It also concerns whether hyphens within titles should be changed to dashes according to the WP:DASH rules that apply elsewhere, as in this previous discussion. LeadSongDog come howl! 15:10, 19 August 2010 (UTC)
Surely it would be more productive and less clutterous to handle this from inside the template, something like {{#time:j" "F Y|{{{date|}}}}}
in this. Try it. See also
mw:Help:Extension:ParserFunctions##time. ―
cobaltcigs 16:45, 19 August 2010 (UTC)
With appropriate conditionals you could make it follow the order of the input. A rudimentary attempt might look like this:
{{#switch:{{{date|}}}
| {{#time:j F Y|{{{date}}}}} = {{#time:j" "F Y|{{{date|}}}}}
| {{#time:F j, Y|{{{date}}}}} = {{#time:F" "j, Y|{{{date|}}}}}
| #default = {{{date|}}}
}}
Beyond that you could add a few more cases to catch abbreviated months, leading zeroes, missing or extra commas, and other common deviancies to achieve greater immediate penetration (fewer defaulting cases requiring preparatory clean-up).
Alternatively you could add a {{{df}}} parameter like those already present in {{ birth date and age}} and similar templates. This would simplify the code somewhat while allowing the {{#time}} func to catch nearly anything and reformat it according to {{{df}}}:
{{#if:{{{df|}}} <!-- day first -->
| {{#time:j" "F Y|{{{date|}}}}} <!-- 6 November 2010 -->
| {{#time:F" "j, Y|{{{date|}}}}} <!-- November 6, 2010 -->
}}
Yes, the ideal solution would be a way for one template to know which other templates are being used on the same page (namely whether they include {{ mdy}}/{{ dmy}}) and make decisions based on that, but it’s not possible with current software. Look on bugzilla for something about that. The next best solution may be for bots to add the {{{df}}} parameter to cite_foo template calls based on which format is declared on the page, but hey—if you already had planned to edit a bunch of pages… ― cobaltcigs 20:53, 19 August 2010 (UTC)
|dateformat=
it is unclear (at least to me) what function it performs towards defining the |Date=
parameter passed to
Template:Citation/core.
LeadSongDog
come howl! 16:13, 20 August 2010 (UTC)
I don’t believe the problems would be “endless”, but no-wrapping the entire parameter automatically within the template would be saner than no-wrapping the input manually in each article. I’d consider both options less than ideal, but the internal approach requires fewer edits and will be easier to adapt to whatever new software features come available. ― cobaltcigs 01:06, 22 August 2010 (UTC)
If you add the #iferror: function to the second example, you can default to the status quo when facing unformatted nonsense:
{{#iferror: <!-- return the following unless it produces an error… -->
{{#if:{{{df|}}} <!-- day first -->
| {{#time:j" "F Y|{{{date|}}}}} <!-- 6 November 2010 -->
| {{#time:F" "j, Y|{{{date|}}}}} <!-- November 6, 2010 -->
}}
| {{{date|}}} <!-- …in which case, act like nothing happened -->
}}
#iferror is not necessary in the first example as an error merely would cause the switch statement to #default. The disadvantage to the first is that it re-formats based on an exact match. The second example re-formats anything resembling a date, but requires instructions as to which format. A third way would benefit from some function to tell us quite simply the order in which the month and day appear in the input, or one which tells us which date format should be used in the article at large (by asking whether it transcludes {{ dmy}}/{{ mdy}}, etc.). ― cobaltcigs 01:52, 22 August 2010 (UTC)
If it isn't reverted, this edit probably, though not unambiguously, means that all date fields should be entirely Nowrapped. The edit only mentions a dd month yyyy date, leaving us guessing about month dd, yyyy. I think there is a parameter that does the same thing as Nowrap. The same should be done to the {{ date}} template itself. Art LaPella ( talk) 22:35, 22 August 2010 (UTC)
The price of plain text is inconsistent order of information and ambiguity with respect to which text is supposed to represent what. I think ideally we’d have a database table to catalogue reference citations, and thus be able for auditing purposes to pull up an immediate and exhaustive list of articles whose content depends upon a specific source, be it the Los Angeles Times or Poor Richard’s Almanack, with dates, authors, etc. in a similarly machine-readable format. For now all we have is the parameter list where each template is invoked. Some readers may enjoy having non-breaking spaces, spans of style="white-space:nowrap;" and other formatting quirks in the html output, but including them as part of the input (wiki-text) only will complicate attempts to parse said input. Same principle applies to infoboxes, succession chains, etc. as far as I’m concerned. ― cobaltcigs 06:12, 23 August 2010 (UTC)
|date=
fields in citation templates sounds like a sensible step. Art LaPella's recent edits to add lots of {{
nowrap}}s are in the right intention, but it's a 3,000,000 edit solution versus a single citation/core edit solution, and more nested templates in citations doesn't make them easier to read (maybe if citation/core is updated we can remove those manually added nowraps again). It's true that there are various incorrect formats in use out there, part of my contributions to
WP:AWB is to catch & tidy them. If there are more fixes to citation dates that AWB could make, let me know.
Rjwilmsi 23:01, 28 August 2010 (UTC)
There are several similar unit articles. Please see the merge discussions about the following unit articles:
Regards Lightmouse ( talk) 12:26, 20 August 2010 (UTC)
Rich, is there some reason the guidance should be changed to allow the spelling out of the number? Tony (talk) 00:47, 22 August 2010 (UTC)
Yes, there are a number of reasons that we should revert this change - which was a revert of this, which is a revert of this which changes the initial "may be expressed as numbers" introduced by you as part of your sweeping re-write in 2007, and later changed to "are". Prior to this the advice was explicit
As introduced by me, here in February 2006, and standing for a long time (apart form a brief words-only interregnum) pursuant to this discussion.
The previous apparent implicit advice to use numbers actually started out under this rubric:
In other words a description of page titles became, in time a prescription for a text style.
Having laid out the wiki-history (there are also historical discussions - see the archive) let us look at style:
Fist, usage - in books the words are almost always spelled out - picking up the two on my desk "Who's Who in the Bible" and "Flowers in Britain" both use this style - and the latter has many numerals in its text in the form of measurements.
Secondly style guides either support words or are agnostic.
Third, barbarism.
Fourth, consistency.
Fifth meaning - contrary to obvious expectation a century is not a mathematical construct, certainly there is a technical meaning 00:00 on the first day of 1901 to 24:00 on the last day of 2000, was the twentieth century, however it is also use to describe an era and can significantly over-lap or under-lap one or both of the official ends of the century, using a numerical format does not convey this meaning as well.
Sixthly layout - numerals disrupt the flow of the text, more so in some typefaces than others. And while they are welcome in scientific and technical contexts, which tend to be replete with tables and graphs, in discussions about humanities and arts they should be firmly kept in check (speaking as a mathematician).
Regards, Rich Farmbrough, 05:07, 3 September 2010 (UTC).
Here's few:
I've noticed most, if not all, of the articles on the planets and moons of the solar system do not give conversions in Imperial/US customary units. Is there a particular reason for this, and where is it covered in the MOS that this is permisible? Given that the bulk of EN.WP's readership is still in the US, this seems quite odd. Thanks. - BilCat ( talk) 07:49, 31 August 2010 (UTC)
"When there are different currencies using the same symbol, use the full abbreviation ... unless the currency which is meant is clear from the context." Using the same symbol in the world, or using the same symbol in the article? If we link and define "$" as the US dollar in an article that uses US dollars, is "$" good enough to represent the US dollar, even if that symbol means something else in a country closely tied to the article? (In this case, Argentinians use "$" for their peso and "US$" or similar for the U.S. dollar.) - Dank ( push to talk) 13:15, 20 August 2010 (UTC)
I have amended the point and put "in the article" back in. McLerristarr / Mclay1 04:47, 12 September 2010 (UTC)
MOSNUM and MoS are pretty similar, but there's a minor niggle, and it would be better to make the wording and order the same where there's an opportunity:
MOSNUM
MoS
Comments
The text used to read: Forms such as the 1700s are normally best avoided (although the difference in meaning should be noted: the 1700s is 1700–1799, whereas the 18th century is 1701–1800). 1700s is ambiguous, as it could also be confused for the first decade of the 1700s, 1700–1709.
This was changed to: Forms such as the 1700s are normally best avoided (although the difference in meaning should be noted: the 1700s may mean 1700–1799, whereas the 18th century is 1701–1800) 1700s is ambiguous, as it could also be confused for the first decade of the 1700s, 1700–1709. (The change being from "the 1700s is 1700–1799" to "1700s may mean 1700–1799")
Given the context is perfectly clear (highlighting that the 1700s and the 18th century are not the same thing, i.e do not cover the same years), 1700s can only mean 1700–1799, so the change to "may mean" is unnecessary at best and possibly just plain wrong. My reversion to the previous wording has been contested, so I seek clarification. Perhaps it would be best to reword it altogether. wjemather bigissue 09:30, 3 September 2010 (UTC)
This does keep coming up over [4] and over [5] and over [6] again, and it seems like everyone is loathe to actually provide guidance to editors on what to do the first decade of a century. I, myself, have been caught in a debate over the topic, in large part because I looked at WP:DECADE and WP:CENTURY and came up with a different answer than it seems most people reach. Based on the number of talk-page hits for "decade" [7], it seems I'm not alone. Instruction creep or no, we need a rule here to avoid confusion and ruffled feathers. How should one reword a sentence like "By the early 2000s, x happened" when one means the first few years of the decade spanning 2000 to 2009? If the answer is "it's okay if it's clear in context," I think that WP:CENTURY needs to say that. // ⌘macwhiz ( talk) 21:26, 18 September 2010 (UTC)
A question about SMS Goeben: "A total of thirteen men were killed and three were wounded." 13 and three? 13 and 3? Also, the addition I made to WP:MOSNUM to disambiguate, "in the article", that is mentioned up at #Currencies was apparently reverted ... anyone know why? - Dank ( push to talk) 03:19, 12 September 2010 (UTC)
It's like 2 × 2 = 4.1. You just can't argue it's wrong in some venues. Tony (talk) 12:57, 12 September 2010 (UTC)
Following the deletions of {{ st}}, {{ nd}}, {{ rd}} and {{ th}}, I've been looking through other misuse of superscripting in ordinals. this search suggests that over 10,000 articles are presently using "1st" for "1st", which is contrary to the general discouraging of superscripting present in the MoS for a couple of years. Any suggestions on the best way to move forward with correcting this? Chris Cunningham (user:thumperward: not at work) - talk 09:04, 16 September 2010 (UTC)
Use words for simple fractions; but use the numerical fraction form in a percentage, with an abbreviated unit, or mixed with whole numbers (an eighth of a millimetre, but 1⁄8 mm; 1+1⁄4 slices). Use figures for decimal fractions (0.025).
An eighth of a millimetre? Really? I won't bother to link to the brochure, but the SI explicitly says (this information may be out out of date) the fractions should never be used to represent the values of SI units.
This is almost promoting incorrect use (or representation, should I say) of metric units, it needs to be changed, in my opinion and there is truthfully little to argue against here for the ones who like picking fights. --
Γιάννης Α.
✆|
☑ 23:09, 20 September 2010 (UTC)
Fractions are compatible with SI. In fact, two of the seven SI base units (metre and kelvin) are defined as fractions. One of the definitions even uses the word 'fraction'. See the official SI website: www.bipm.org/en/si/base_units.
Regards Lightmouse ( talk) 09:02, 21 September 2010 (UTC)
—— Shakescene ( talk) 18:31, 21 September 2010 (UTC)Use words for simple fractions; but use the numerical fraction form in a percentage, with an abbreviated unit, or mixed with whole numbers (an eighth of an inch, but 1⁄8 in; 1+1⁄4 slices). Use figures for decimal fractions (0.025).
I think it's a bit too strong to say that every use of fractions with metric units should be avoided. When people go to the market or to a butcher's shop, they often buy a pound or half a pound of something, the pound being a metric pound defined as exactly half a kilogramme. But thinking in metric pounds is very slowly dying out, and younger people are more likely to buy half a kilogramme or a quarter kilogramme than older people. Similarly for distances. You would never see something like "1/2 kilometre" on a street sign in Germany or France, but it's what people say. IMO the important points are the following:
Fractions with metric units are usually inappropriate here, and that should be clear. But if we aren't careful with the formulation someone will go around and mechanically remove them even in the few cases where they are appropriate and better than the alternative. Hans Adler 00:20, 23 September 2010 (UTC)
MOS guidance is:
MOSNUM guidance is:
If you search for the word 'fraction', you'll find multiple references to fractions in MOSNUM. Some of which may be redundant. I don't know if MOS needs bringing into line with MOSNUM or vice versa. I think it's a guideline looking for a problem that doesn't exist. Editors appear to use decimal fractions for metric units anyway. The guidance could be removed and it wouldn't make the slightest difference to editor action. Lightmouse ( talk) 08:58, 23 September 2010 (UTC)
For proper disambiguation in date ranges between centuries I boldly edited from:
"The full closing year is acceptable, but abbreviating it to a single digit (1881–6) or three digits (1881–886) is not."
TO:
"In such case the full closing year is given, as abbreviating it to a single digit (1881–6) or two digits 1881–86) or three digits (1881–986) are not acceptable."—
Iknow23 (
talk) 06:44, 23 September 2010 (UTC)
Also, the prior one had a obvious error as the material was about (1881–1986), thus the three digit closing would be 986, not 886. —
Iknow23 (
talk) 06:49, 23 September 2010 (UTC)
Tony, I was wanting to take this as a two-step process. First I wanted to clear up what it is currently saying. Then I was planning to propose 'deprecating the two-digit closing range' in all cases. I didn't want to overscope this present discussion.—
Iknow23 (
talk) 21:29, 24 September 2010 (UTC)
Grk, THAT is how I was understanding it in that "The full closing year is acceptable" in all cases, but it was pointed out to me that it was in context ONLY with the 'different century' senario.—
Iknow23 (
talk) 21:35, 24 September 2010 (UTC)
From Wikipedia:Manual_of_Style_(dates_and_numbers)#Numbers_as_figures_or_words:
"Numbers that begin a sentence are spelled out, since using figures risks the period being read as a decimal point or abbreviation mark"
This looks to me like a hangover from the days of typewriters as it's a hugely implausible risk. There are already too many exceptions in this section and I suggest just removing this one. GDallimore ( Talk) 15:03, 25 September 2010 (UTC)
I would just like to point out that depricating two-digit years would violate ISO 8601, which would interpret 2008–10 as the tenth month in the year 2008. Using the dash in any case would not comply as ISO 8601 requires a solidus (as in 2008/2010) to represent time intervals, but perhaps two-digit years were discouraged at least to avoid ambiguity. — sroc ( talk) 13:13, 12 October 2010 (UTC)
I have been told that I'm not allowed to change BCE to the less ambiguously defined BC because of this "manual of style". Who can I go to if I want to discuss that rule?-- Axiom talk 22:44, 26 September 2010 (UTC)
To address the original question. If the article was created and past the stub staging using BCE/CE, then it should stay. If the article was changed to that after it was establish it should be discussed and the original format should be applied. This is the basic rule of the Manual of Style. BCE should not be changed to BC just for the fun of it or vice versa. -- Walter Görlitz ( talk) 04:14, 10 October 2010 (UTC)
Even for those who know what it means, I think readers tend to have a *neuron-trigger* of “something new” when they encounter instances of BCE. Accordingly, for articles directed to a general-interest readership (not the scientific papers to which our articles may refer), I think the newer “BCE” tends to be distracting just because more of us notice the choice of wording and that distracts from the thought. I am keen to avoid any writing style that calls attention to itself so I tend to avoid “BCE” to make the article read as fluidly as possible.
I know that those who like to use the new terminology probably find it more satisfying and will claim it is “natural” to them. But I honestly think that as writers, their minds are actually noticing the writing style and being pleased with the choices rather than not noticing the writing style and being absorbed in the thoughts being conveyed.
Finally, I don’t think “ambiguous” has anything to do with it. If one is reading an article on Egyptian pyramids, “It was built in 3000 BC” is just as clear as “It was built in 3000 BCE”. As far as I know, the admonition against changing one form to another is to avoid edit warring. Greg L ( talk) 16:48, 11 October 2010 (UTC)
Do you know the underlying reason for delimiting numbers with only the American-style commas? Seems rather chauvinistic, no? Because a given country in Europe might have three ways to delimit numbers and primary-school children are taught all three, including the American way (using commas). Americans are taught just one. So unless it is an especially scientific article (hopefully directed to a scientific readership), it is best to use commas for delimiting on en.Wikipedia because it causes the least confusion for its readership and allows articles to be read most quickly and naturally without brain (!) interruptions.
The same goes for the “ca” in scientific papers. Again, we think about the target readership. While it is certainly fun to write articles that look like they belong in a scientific journal, writing “approximately” is better.
The issue between “BC” and “BCE” is similar; though it is less so about “confusion” it is still about making articles read quickly and most naturally. For general-interest readerships I prefer BC as I have found through observation and experience that it is part of a writing style that least draws attention to itself. But this is just a generality—even for me. I agree with the use of BCE in a few rare cases, like “ Dating Creation” because it covers how a variety of religions date creation. For that particular article, concerns over religious sensibilities trump awkwardness (assuming one has already recovered from the cognitive dissonance of how the entire universe was created precisely 2,196,528 days ago on October 23, 4004 BCE). That article is quite the exception. Greg L ( talk) 21:53, 12 October 2010 (UTC)
The religious objection to BC/AD comes from their spelled out versions, In the year of (the/Our) Lord and Before Christ; non-Christian recognize Jesus neither as Lord nor Christ. Those are dealt with by the BCE/CE distinction, even if setting the zero-year is the same. See Anno Domini. The massive number of non-Christian English speakers suggests this is a serious issue for English Wikipedia. There are also massive numbers of Chinese, Japanese, Korean, and Eastern European users educated with "Common Era" or "Western Era" equivalents as their norm.
At a minimum, we could agree to exclude BC/AD from articles about the history of non-Christian cultures, about non-Christian religions, and from technical articles in the sciences where BCE/CE are used.
Rich, can't we deal with readability issues with a template link?-- Carwil ( talk) 15:06, 23 October 2010 (UTC)
On the WP:MOS page I proposed reducing the section Chronological items to a short paragraph that would serve as an introduction to the corresponding section in this article, much as I did with Units of measure and as other did with Geographical names. I have identified four items, each of a few sentences in the WP:MOS article that do not appear in this article. Three are non-contraversial insofar as they do not contradict anything here, but one might need some discussion. Does anybody have any objection to me cutting and pasting the three non-contraversial items into this article without further discussion and to open up discussion about the fourth here? Martinvl ( talk) 11:46, 7 October 2010 (UTC)
"Avoid inconsistent usage. Write a 600-metre (2,000 ft) hill with a 650-metre (2,100 ft) hill"
And yet the parentheticals are non-hyphenational. In the above example I would 2000-ft hill as "two thousand foot hill" and "(2000 ft) hill" as two thousand feet hill" which is clearly(?) wrong.
(Brief) Comments?
Rich
Farmbrough, 13:42, 10 October 2010 (UTC).
Meters can be units of length or they can be gauges one installs into a control panel. Feet can be units roughly a third of a meter long or something attached below one's ankle. Yards can be units or something one grows grass on. There can be bridges for cars, and there are footbridges. There can be foothills. Ergo, when a measure is being used as modifier, “We have 200-foot bridges” is perfectly distinct from “We have 200 footbridges”. When the measure is used as a modifier, the hyphen nails down meaning and avoids having the readers’ eyes double back because of brief confusion. And rigorously adhering to the hyphenation practice helps the eye to parse occurrences where the expression is not being used as a modifier, like “We have 200 yard sales.” This hyphenation practice holds true for unusual units that don’t look like something else, like “radian” because our minds are accustomed to the convention. So it’s “A two-radian arc segment.” The need to clarify disappears with unit symbols like “ft”, “m”, “yd”. In fact, none of the SI’s unit symbols look like words (although “mol” looks a bit like “mole”). And the common U.S. Customary unit symbols generally don’t look like words either.
To state the obvious: a parenthetical like (2000 ft) is not a modifier and is unambiguous. And, IMO, “2000-ft hill” and “2000 ft hill” are both examples of poor writing; use the spelled out unit of measure with the hyphen. Unit symbols should never be used in a modifier for regular prose. To ensure we are all on the same wavelength, “The building had a height of 200 feet” does not have the “200 feet” being used as a modifier and therefore does not get the hyphen. Greg L ( talk) 14:17, 11 October 2010 (UTC)
As for your examples mentioning “China Daily” and its “we are the world” thrust; there are scores of Wikipedias in languages other than English. We write for readers whose first language is English. If we wrote otherwise, our articles would look like Simple English.Wikipedia. Oh, BTW, that link to “Simple English Wikipedia” is to the “Autobahn” article. Even there, they skip spelling out such familiar units of measure because the readers are assumed to be literate and have seen a speed-limit sign if they are actually interested in the Autobahn. Greg L ( talk) 20:09, 17 October 2010 (UTC)
If an article uses citation in the form
where the publication dates are consistently distinguished in format from accessdates, is this a "breach" of this MOS guideline for "consistency"? Is it necessary to convert all such references to
Some developed and even featured articles have citations in the former form, and have had so for years with stability. The intro to this guideline says: "If an article has been stable in a given style, it should not be converted without a style-independent reason." Comments? Gimmetoo ( talk) 03:20, 19 October 2010 (UTC)
I agree with Tony & Stephen that
is preferable to the example with both publication and accessdate in ISO. But that's not the question I'm asking. The question here is whether, in references, the publication and accessdate can be consistently distinguished by format, or whether they must have the same format. There are quite a few articles where the publication dates are in dmy or mdy, and the accessdates are in iso. As an aside, there is no ambiguity in the iso accessdate in the example, even for someone unfamiliar with iso; reading the accessdate as January 8 puts it before the publication date, which is obviously wrong. Gimmetoo ( talk) 13:20, 19 October 2010 (UTC)
The presence of the format YYYY-MM-DD does not demonstrate that the publication in which it appears has adopted ISO 8601. In the absence of an explicit definition of what the format means in a particular publication, such dates are ambiguous.
Also, if one were to apply ISO 8601 to the publication date and one wanted to give the publication date of a current monthly magazine, one would be obliged to write 2010-10, which most uninitiated readers would not understand. Jc3s5h ( talk) 16:48, 20 October 2010 (UTC)
Note the following:
It has been discussed before.
Regards Lightmouse ( talk) 16:26, 22 October 2010 (UTC)
If you have a car, take a look at the metric speed on the speedometer. What does it use? Lightmouse ( talk) 17:18, 22 October 2010 (UTC)
Isn't the real problem here en-masse conversions from one name of a unit to another because of some OCD compulsion about consistency? Does it really matter which one is more common? No. The meaning is clear either way. The policy on semi-automated edits is clear: Unless a change is completely non-controversial, it shouldn't be done in a semi-automated fashion. Gigs ( talk) 00:54, 23 October 2010 (UTC)
km/h is the scientific way of writing it. That or kmh-1. McLerristarr / Mclay1 08:56, 23 October 2010 (UTC)
Many editors use non-standard, verbal, or specialist terms when a more accessible and/or standard term will do the same job. It was a surprise to me to find 'km/h' being questioned. Janitorial edits, by definition touch many articles so surprise questions are a common experience. I'd be grateful for mosnum to have guidance on this. I propose changing:
to
Lightmouse ( talk) 10:45, 23 October 2010 (UTC)
According to the SI ( here), the abbreviation for "hour" is "h" and the abbreviation for "kilometre" is of course "km". In my opinion, it doesn't matter what some people may use, "km/h" is the only correct way of writing it, unless you use kmh-1, but that's too technical for common usage and would confuse some people. McLerristarr / Mclay1 10:51, 23 October 2010 (UTC)
When using metric units always follow the official SI standards absolutely strictly. No variation. No debate. Otherwise what is the point of even having any standards at all? Roger ( talk) 11:07, 23 October 2010 (UTC)
I think we have reached a consensus: "km/h unless there's a good reason for using kph"
What do other people think? Pdfpdf ( talk) 13:33, 23 October 2010 (UTC)
The phrase good reason is redundant (you may not be aware that wp:iar could be applied on the end of all mosnum guidance) and subjective (because we don't know what you think is a good reason). We've merely moved the debate from a main clause to a subclause. I see now that you (Pdfpdf) can't give an example of a Wikipedia article (other than unit definitions and quotes) where good reason applies. Would you mind looking at the articles you reverted and seeing if any of those shouldn't be changed to 'km/h'? In order to downgrade the temperature of such edits (in response to well-taken comments by people like Gigs and yourself), I'd like to have mosnum guidance that can be taken to BAG. Lightmouse ( talk) 12:47, 24 October 2010 (UTC)
As it applies to automotive-related articles, if (big ‘if’) “km/h” is most common for car manufacturers and current, reliable literature on the subject, then that is what Wikipedia should be doing for its automotive-related articles. That statement does not apply to the practices that are universally or near-universially observed in other disciplines, like ‘ Rocket sled’. Greg L ( talk) 17:24, 26 October 2010 (UTC)
The above discussion focused on km/h versus kph. But the automobile conventions as quoted above are in conflict with this page because they recommend rpm instead of rev/min, mpg instead of mi/gal, and mph instead of mi/h. I know only American usage, but I think rpm, mpg, and mph are all much more common than their alternatives. It seems to me that the current guideline needs an exception, something like: However, if reliable sources consistently use a different style, such as mph instead of mi/h, follow the sources instead. Ozob ( talk) 14:01, 24 October 2010 (UTC)
Some disciplines use units not approved by the BIPM, or write them differently from BIPM-prescribed format. When a clear majority of the sources relevant to those disciplines use such units, articles should follow this (e.g., using cc in automotive articles and not cm3). Such non-standard units are always linked on first use.
Headbomb { talk / contribs / physics / books} 14:16, 24 October 2010 (UTC)
My point—which I guess I failed to make clear above—is twofold. One, the "clear majority" provision is under "scientific and technical units", so it might be interpreted to not apply generally. Two, MOSNUM mentions mph and psi as exceptions to rule about division and then says "etc." It seems to me, judging from the conversation here, that the "clear majority" provision should apply more broadly, and that the "etc." should be taken to mean "clear majority". Currently MOSNUM doesn't do this. Does anyone else see this as a problem? Ozob ( talk) 00:59, 25 October 2010 (UTC)
The term 'micron' had an official status between 1879 and 1967. It was officially removed from SI 40 years or so ago. The terms 'centigrade' and 'micron' continue to be used by many people but I think it would be worth having mosnum guidance on the use of the both terms 'centigrade' and 'micron' within WP.
Here are some issues that occur to me:
Ability to guess the meaning
The benefits of SI are that they do away with special names that have to be learned or explained. It has a simple format (prefix plus unitname). From that simple format, you can guess the size and/or the unit. Somebody may not have heard the term microwatt before but they should be able to realise it's 'micro' plus 'watt'.
Accessibility - micrometre/er is universal, the term micron isn't
Scientists are aware of both terms and there is no domain or geographical region which doesn't use the SI term. The term 'micron' is used by some (the term 'some' meaning anything less than 100%) scientists in some technical domains and some geographical regions. However, some ordinary people don't know what a micron is (as is shown by the multiple cases where it has to be explained in text). Thus the SI term is more accessible.
Ambiguity The American spelling of micrometer is ambiguous as a single word. Metrology has several ambiguous words (e.g. 'foot', 'yard', 'minute', 'second', 'mole'). However, the meaning of micrometer is always clear from the text (e.g. "the wavelength is 54 micrometers", "we measured it with a micrometer"). That may apply with most of the ambiguous unit terms used in WP articles.
Similar terms as the scale changes e.g. nanometer, micrometer, millimeter It is convenient to be able to scale units using similar terms. This can be seen in text such as US NIST: "from deep violet at 400 nanometers (nm) to near infrared at 4 micrometers (μm)"
Guidance Style guides provide the benefit of consistency across the project. WP isn't tied to one particular domain or geographical region. As with guidance on several issues, we can come up with our own consistent guidance so editors don't have to debate the issue on each article. I propose the following guidance:
Comments welcome. Regards Lightmouse ( talk) 17:13, 20 October 2010 (UTC)
{{
cite journal}}
: |pages=
has extra text (
help); Unknown parameter |coauthors=
ignored (|author=
suggested) (
help)On the Corpus of Contemporary American English, even restricting the search to texts from the 2005–2010 period, there are 50 occurrences of micron, 43 of microns, 46 of micrometresmicrometers, and 32 of micrometremicrometer (and a few of the latter refer to the tool). That doesn't sound like obsolete to me. (OTOH, IMO the use of μ alone for the unit is dead: I've only ever seen μm except in publications several decades old.) Conversely, in the corpus and the same period, there are 147 occurrences of Celsius compared to 23 of centigrade, so I wouldn't object to discouraging the latter – providing it's actually used often on Wikipedia, per
WP:BEANS.
A. di M. (
talk) 13:58, 21 October 2010 (UTC)03:06, 22 October 2010 (UTC)
So I did a quick search using google to see how many times one or the other term popped up, with the results reported in 1000s of hits. I didn't take into account any overlap between the three terms in the same article (assuming they were usually consistent) but did search using both the singular and plural form. Now, the way Google works, you actually get more hits just searching on "Infrared micrometer" than searching on "Infrared micrometer OR micrometers" which is illogical, probably having to do with what it considers important in your search terms and how many you have specified. But since the three searches in each case used a parallel form, I would conjecture that their results are comparable and the percentage of use of the word "micron(s)" is indicative of the word's actual popularity.
It can be seen that there are some differences in this number between different fields, but that "micron" wins out over "micrometer/re" in each case. Some of the occurances of "micrometer" may have referred to the measuring instrument, and I avoided keywords relating to machining for that reason.
Finally, in every case the use of the symbol μm paired with the keyword was more frequent than any of the searches with the word, but that is not at issue: we all agree on using μm (as mandated by BIPM) rather than the obsolete version μ.
Google search term Hits × 1000 Percentage using "micron"
Infrared micron OR microns 1380 64%
Infrared micrometer OR micrometers 530
Infrared micrometre OR micrometres 230
interferometer micron OR microns 260 66%
interferometer micrometer OR micrometers 107
interferometer micrometre OR micrometres 28
Grating micron OR microns 1440 90%
Grating micrometer OR micrometers 150
Grating micrometres OR micrometres 11
X ray micron OR microns 1440 65%
X ray micrometer OR micrometers 685
X ray micrometre OR micrometres 99
Cellular micron OR microns 1480 88%
Cellular micrometers OR micrometers 174
Cellular micrometres OR micrometres 23
semiconductor wafer micron OR microns 743 71%
semiconductor wafer micrometer OR micrometers 228
semiconductor wafer micrometre OR micrometres 69
nanotechnology micron OR microns 274 57%
nanotechnology micrometer OR micrometers 141
nanotechnology micrometre OR micrometres 65
protein micron OR microns 1580 61%
protein micrometer OR micrometers 967
protein micrometre OR micrometres 45
No field specified:
micron OR microns 12600 77%
micrometer OR micrometers 3600
micrometre OR micrometres 268
Interferometrist (
talk) 18:58, 21 October 2010 (UTC)
In my opinion, micrometre is universally understood to anybody who has a basic knowledge of maths. Micron is far less common, in fact, I've never heard it used except when talking about the width of hairs. McLerristarr | Mclay1 12:01, 24 October 2010 (UTC)
wp:engvar says "Wikipedia tries to find words that are common to all varieties of English." Similarly, Wikipedia should use terms that are suited to the widest international audience including non-specialists. As Greg suggests, domain specialist terms constantly seeping out from in-house publications into wider domains by 'monkey see, monkey do'. Wikipedia benefits from using SI by default and deviating only if good reasons exist (and hopefully get documented here). Organisations like BIPM (SI units) and NIST (American units) were specifically created to provide stable references for inter-domain, inter-region communication. As Jc3s5h, suggests, anyone that understands 'micron' also understands 'micrometre/er' but the reverse isn't true. I propose the following guidance:
I hope that guidance encapsulates the issues. Lightmouse ( talk) 14:19, 27 October 2010 (UTC)
• Some disciplines use units not approved by the BIPM, or write them differently from BIPM-prescribed format. When a clear majority of the sources relevant to those disciplines use such units, articles should follow this (e.g., using cc in automotive articles and not cm3). Such non-standard units are always linked on first use.
You said "MOSNUM already has clear guidance that SI is preferred" and quoted some text from mosnum. Unfortunately it doesn't. If it did, I would have quoted mosnum at Pdfpdf when he swore at me for applying 'km/h' rather than 'kph'. Lightmouse ( talk) 18:46, 27 October 2010 (UTC)
*In general, put the units first that are in the most widespread use in the world. Usually, these are International System of Units (SI) units and non-SI units officially accepted for use with the SI; but there are various exceptions for some measurements, such as years for long periods of time or the use of feet in describing the altitude of aircraft.
* In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s−1.
P.P.S. Speaking of other industries that seem to be still using micron, I note this patent application by Apple for a vapor deposition nitriding coating to stainless steel. It speaks of a coating thickness of “15 microns”. It appears that the use of “microns” is another one of those things on which the the world may be soundly ignoring the BIPM; the proper use of the percent symbol (75% and not 75 %) being another one that immediately comes to mind. Greg L ( talk) 19:54, 29 October 2010 (UTC)
To get this conversation separate from the kph one, the policy is not merely the AWB instructions, it's Wikipedia:Bot_policy. Semi-automated edits that blindly change articles en-masse are covered by the bot policy. Specifically, "Contributors intending to make a large number of assisted edits are advised to first ensure that there is a clear consensus that such edits are desired." If reasonable people are complaining about it, there is not a clear consensus.
"Enforcing" the manual of style with thousands of edits absolutely falls under this. This is why the above conversations counting Google hits for one formatting of a unit vs another are irrelevant. If these changes are controversial enough that they require that sort of conversation, then they should never be done en-masse.
I suggest that complains like pdfpdf's be taken much more seriously. Yes, he degenerated into incivility in the end, but that was after trying to make many good faith efforts to explain that the changes were controversial and unwanted. Gigs ( talk) 18:25, 23 October 2010 (UTC)
User:Gigs defines controversy as one query on a talk page. Unfortunately, that definition is retrospective and disproportionate. None of us can predict that an edit will not result in a query from any editor. The correlation between query and controversy is much less than 1:1. Wikipedia would need to ban bots and janitorial editing because no admin or editor can guarantee in advance that queries won't be posted to somebody. I prefer something closer to that at wp:cont: "A controversial issue is one where its related articles are constantly being re-edited in a circular manner, or is otherwise the focus of edit warring. " There are editors that do good work by copy-editing and there are editors that do good work by widespread sub-editing. Consistency and house style actually require many small changes of detail which sometimes makes people with a local article focus ask questions. If sub-editors gave up, nobody would ever get into trouble, but Wikipedia would be worse and certainly less accessible to those without the local article focus. Despite public debates like this one, there's a lot of behind-the-scenes bot, script, and mass editing on Wikipedia and that is a good thing. Lightmouse ( talk) 12:27, 24 October 2010 (UTC)
Any automated changing of units should be done with care and consensus. Lightmouse has been overriding the default conversion for acres from ha to km2. I think there was a similar issue with nmi. Changes like this are clearly ones that need to be discussed. I will say that finding a good place to discuss these will always be an issue since no matter where it is announced, a good number of editors will be missed. Vegaswikian ( talk) 22:43, 26 October 2010 (UTC)
I'd like to do a sub-edit run (unit definition articles and quotes won't be included) to convert synonyms of the symbol of kilometre to lower case 'km', and the symbol of kilogram to lower case 'kg'. . See Wikipedia:Manual_of_Style_(dates_and_numbers)#Unit_symbols:
I'm being cautious so I'm checking here first and then taking it to BAG. Comments? Lightmouse ( talk) 13:09, 24 October 2010 (UTC)
As a courtesy for those who care, I'm hereby informing everyone (who cares) that I am busy for the next week and won't be responding to questions/comments/etc in a timely manner. If you REALLY want a response from me before next week, send me email, and then go to my talk page and warn me to look out for your email. (The email account I link to WP gets a lot of junk, which I generally ignore.) Pdfpdf ( talk) 10:22, 25 October 2010 (UTC)
This is spell-checking; bots should not be doing it (for precisely the reasons indicated in this section; bots cannot tell when an exception should be made). To quote policy; Bot processes may not fix spelling or grammar mistakes... in an unattended fashion, as accounting for all possible false positives is unfeasible. Lightmouse's record does not encourage me about an attended fix either; but if somebody is willing to check over his shoulder, that would be another question.
But fundamentally, why do this with a bot at all? If there is project-wide consensus for this fix, the normal process of fixing errors as they are noticed will take care of it, as it takes care of teh; if not, it should not be done at all. Septentrionalis PMAnderson 17:12, 27 October 2010 (UTC)
It appears uncontroversial that we should assist editors by adding the final sentence below.
“ | The symbols for the degree Celsius, the degree Fahrenheit and the kelvin are °C (not C), °F (not F), and K (not °K) respectively. (C and F are the symbols for the coulomb and the farad respectively; °K is the symbol for the degree Kelvin, the pre-1968 name of the kelvin.) Use the term 'degree Celsius' rather than 'degree centigrade' (except in text describing history of units). | ” |
Your thoughts, please? Lightmouse ( talk) 13:52, 28 October 2010 (UTC)
It's one of those colloquial words that people add from time to time. Trust me, there are editors out there that sub-edit articles to replace such terms and it'd be worth having a guideline to make it clear in case somebody ends up swearing at them. Lightmouse ( talk) 14:33, 28 October 2010 (UTC)
There's only 128 because editors like me keep changing it to Celsius. I do a run from time to time and even in my routine work, I pick them up. There are other editors that do it too. Google shows centigrade in 7 to 25% of hits (depending how you search), so it's not surprising that it finds its way into WP articles. I found the following instances just now:
We have some astonishing trivia in explicit detail on mosnum, yet routine stuff isn't. Gnoming editors are in a Catch 22 where one person can swear at them because mosnum doesn't document consensus for <insert standard term or format> but if the consensus is strong, it won't be documented. The way things are right now, we need to vote on everything. Lightmouse ( talk) 11:41, 29 October 2010 (UTC)
(arriving late to this discussion) Yes. “Centigrade” is beyond archaic and should only be used in direct quotes or when talking about the history of the temperature scale. Greg L ( talk) 19:59, 29 October 2010 (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 125 | ← | Archive 128 | Archive 129 | Archive 130 | Archive 131 | Archive 132 | → | Archive 135 |
Talk:Sharon Johnston lists the issues. Feel free to add to the discussion there. -- Walter Görlitz ( talk) 16:53, 7 August 2010 (UTC)
Wikipedia lists distances in American articles about roads. I added metric units but was reverted. When I queried this, I was told that it had been discussed in the a subsection of the manual of style:
There is nothing in the MOS that forbids it but I was told it was the de facto standard following those discussions. I read the discussions and still think that it should be permitted to use metric units for distances in a table. I can understand that there might be something special about "milepost 17" but I can't see what is special about "the second exit is 1.8 miles from the origin and the third exit is 2.4 miles from the origin". What do other people think? Lightmouse ( talk) 21:39, 1 August 2010 (UTC)
The phrase "every time it occurs" was intended to apply to repeats of the same value. This is not the case with a table of different distances. When you say that some felt that metric units clutter the table, were those people from metric countries? Lightmouse ( talk) 21:56, 1 August 2010 (UTC)
It is way too much clutter, especially for really lengthy junction lists. -- Rs chen 7754 00:11, 2 August 2010 (UTC)
Requiring the roads projects to include both units of measure in all junction lists amounts to requiring roads editors to do a lot of extra work (some junction lists have hundreds of junctions) that would provide a very small benefit, or none at all. -- Rs chen 7754 07:46, 2 August 2010 (UTC)
Ah, it sounds like a resolution is possible that doesn't include 'require' or 'forbid'. It's now merely a matter of preferring separate columns. Lightmouse ( talk) 11:10, 2 August 2010 (UTC)
I haven't kept up with this current issue about metric conversions, but I wonder why an exception should be made for just this field. I accept that space is at a premium in tables, but other tables manage metric and US customary conversions perfectly well. The slight addition to "clutter" is just something we have to live with internationally when English-speakers have a dual system.
The Capitol Loop table seems to be ideal for adding conversions: the first two sub-columns would need very minor increases in width, and there appears to be no space crisis in the other columns, which could be narrowed a little if people want to retain the current overall width.
I am particularly concerned about the "slippery slope" implications of denying the many international readers, including many native English-speakers, easy comprehension of the distances. Tony (talk) 15:40, 2 August 2010 (UTC)
To me, this seems like a clear case where having the conversions is excessive. I'd post the appropriate text of MOS:CONVERSIONS here, but someone's already done so. Also, I don't see why the lack of miles in, say, Canadian junction lists isn't being discussed as an "issue" here. If you're going to "suggest" junction lists using solely imperial units be saddled with metric clutter, I don't see why junction lists using just metric units shouldn't be saddled with imperial clutter. (As an aside, RJL-style, milepost-only tables have been brought through FAC 29 times, and if conversions for each milepost were truly mandatory, I'm sure someone would have required them by now.) – T M F 16:09, 2 August 2010 (UTC)
I'm not a fan of a footnote. For me, it makes the mile column unacceptably wide. It would also require the addition of a footnote section to every article that doesn't have one, and for the US alone, that number is in the several thousands. I also can't justify adding a section everywhere just for one short footnote. Perhaps a better option is to put the note in the table footer instead. – T M F 21:54, 2 August 2010 (UTC)
To all the people who are pushing for these useless metric conversions, I hope that you would be willing to update pages such as Interstate 5 in California, where the table is hardcoded, rather than just making more work for us editors who actually edit the road articles and who really don't see a need for metric conversions. If foreigners want to drive on American roads, they will have to deal with the US system of measurement already. -- Rs chen 7754 04:20, 3 August 2010 (UTC)
This is a perennial proposal; it was debated three years ago exactly. I agree with a lot of the points that were made there in opposition to requiring both mi and km. The perception that it results in "number soup" is one I share (I could see myself mixing up the columns upon reading them). I find Holderca's posts very relevant—as he says, the guide signs, odometers, and distance markers in the United States are all in miles, so the km conversions would be functionally useless to anyone attempting to apply them while visiting the road. km conversions are already listed in the infobox and route description, so users just wanting a conversion to "fix the distances in their head" would be adequately served by those. In any event, if this is forced through, I hope there's one of these pro-conversions people willing to apply the conversions to all 12,500 U.S. road articles. I doubt you're going to find anyone in the road project willing to spend their time doing something so menial resulting in such a marginal improvement to the articles. — Scott5114 ↗ [EXACT CHANGE ONLY] 05:11, 3 August 2010 (UTC)
Adding metric conversions to US articles will not increase their readership. The distances on the roads are based on miles, the speed limits are in miles, the government posts the lengths in miles (which if the fractions of lengths are converted to kilometres and added up, they probably would not be equal), and the cars show miles in larger print than kilometres. On the flip side, for every other country except basically the UK, metric is the ONLY system of measurement. I refuse to convert the Ontario articles to show imperial - Canada hasn't used in for 40 years, and 95% of the planet is in the same position. If you feel like converting all the distances at I-10 in Texas or Highway 401, be my guest... but I will probably revert it if it looks like crap and clutters the table with useless and repetitive information. - ʄɭoʏɗiaɲ τ ¢ 14:55, 3 August 2010 (UTC)
Let me make a good comparison using an example we all know. Angel Falls in Venezuela is the tallest single drop in the world. That drop is 807 metres of the 979 metre total drop. For me, this is fine and dandy. For an American, it means diddly, so we convert it to feet. AHHH! There we go, 2,648 ft out of a total of 3,212 ft. Makes sense now! By comparison, the distance I travelled along I-90 last spring through Pennsyvania was about 45 miles. The sign said it as soon as I got there. Did I sit there to convert it to km so I could say "Oh ok, now I can gauge that distance"? No, because the speed limit is in miles. If I converted one, I'd have to convert everything, but in the end I'd get the same result - About a 45 minute drive at the maximum speed limit. Knowing the km between two points measured in miles is pointless, because you can't use that converted value for any purpose. When you see the next sign saying "Ohio - 28", you're dealing with 28 miles, but you've already come 28 kilometres, but only 17 miles, so you have... hmmm... 28 miles to go until you're in Ohio. If the pure statistic of the kilometric distance is that important, you can pick an exit number and convert it. - ʄɭoʏɗiaɲ τ ¢ 16:31, 3 August 2010 (UTC)
I was just wondering is there a MOS guideline on timeline dates in contents lists. 2010 Russian wildfires and also an older version of 2010 Northumbria Police manhunt highlight the problem. Depending on the date formatting used, the numbers look very messy when you end up with a list like..
2 Timeline
2.1 29 July
2.2 31 July
2.3 1 August
2.4 2 August
2.5 4 August
2.6 5 August
2.7 6 August
2.8 7 August
I would think this has come up before, but can not find anything stating how these sorts of things are meant to be handled. thanks BritishWatcher ( talk) 21:16, 7 August 2010 (UTC)
It's a sequence of events. The heading should emphasise the event name, the time of the event is a characteristic of the event and is secondary. Lightmouse ( talk) 11:47, 8 August 2010 (UTC)
Thanks. I also agree with you that the 24 hour clock is useful, particularly for data, transport, sequences, tables, timestamps. Lightmouse ( talk) 12:38, 8 August 2010 (UTC)
In a recent edit summary Wjemather stated "it is ISO format regardless of whether WP has adopted the standard or not. Added clarification". As a counterexanple, consider Microsoft Excel for Windows. It treats text entered into the current cell in the YYYY-MM-DD format as dates provided the date is on or after 1900-01-01; it treats earlier dates as text strings. Thus this widely used format is not equivalent to ISO 8601.
One facet of this topic where I have had no luck finding reliable sources is whether the people or government of any country ever adopted the YYYY-MM-DD format independently of ISO 8601, with different or unstated rules. I would appreciate being informed of any sources that address this.
P.S.: yes, I know about Excel's leap year difficulties. Jc3s5h ( talk) 20:34, 12 August 2010 (UTC)
::VariantChangeType
to see whether that is an underlying feature of that API or specific to Excel, but I don't see how it matters to the argument anyway, since it manifests as a feature of the user input interface and has nothing to do with how dates are displayed or stored.
Si Trew (
talk) 20:58, 12 August 2010 (UTC)YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose [...] However, they may be useful [...] . Because it might be thought to be following the ISO 8601 standard, this format should only be used for dates expressed in the Gregorian calendar and for the years from 1583 through 9999.
{{
cite/doc}}
for that template's accessdate parameter, but no longer are; {{
cite book/doc}}
does show such a use in its examples, as does {{
cite journal/doc}}
, and I imagine others do too.)Months are expressed as whole words (February, not 2), except in the ISO 8601 format (YYYY-MM-DD)
Just a side comment that I feel I should make. It is only my opinion, but this whole argument is getting kinda lame in my book. Call the damn things "ISO style date format" and move on. The usage may not be 100% compliant with the applicable ISO standard nor have we formally adopted the standard. Personally, I think the things should be excised from display text except where appropriate. Use them to set up sorting in tables using {{
sort}} and display the content in another format, but get rid of them in most other cases. Running prose and footnotes should be using a single, consistent date format that's used in the sources appropriate to the topic. Rarely is space a concern in footnote formatting, unlike some tables. I can see using ISO style dates in some topics, but they really should not be in use in many topics.
Imzadi
1979
→ 01:17, 13 August 2010 (UTC)
Guy Fawkes Night, also known as Bonfire Night, is an annual celebration held on the evening of 5 November to mark the failure of the Gunpowder Plot of 1605-11-05.
{{
cite journal/doc}}
and {{
cite book/doc}}
not to use the YYYY-MM-DD format, and checked {{
cite news}}
, {{
cite/doc}}
({{Citation/doc}}
), {{
cite web/doc}}
and {{
cite thesis/doc}}
which were OK anyway. Any others?
Si Trew (
talk) 06:54, 13 August 2010 (UTC){{cite}}
templates used to stipulate YYYY-MM-DD format, now they do not (the ones I mentioned state that they should use the format used in the rest of the article.) I can't find where in the history this was changed, but I assume that the stipulation for YYYY-MM-DD was removed. In that case, considering that MOSNUM already discourages using this format, and that it is only the examples that uses it and not the description of the parameter, I imagine it was just an oversight not to change the example. In any case, I don't see how it pre-empts the outcome of this dicussion here; I mentioned the cite templates as an aside; this discussion is about whether the term "ISO 6801" is required or not.
Si Trew (
talk) 15:33, 13 August 2010 (UTC)The current state "the ISO 8601 compliant YYYY-MM-DD format" is perfect. -- Walter Görlitz ( talk) 13:58, 13 August 2010 (UTC)
Please permit me to take this conversation a step backward. The statement is about not padding month numbers except when used in YYYY-MM-DD format. How can we word it so that we exclude this ISO 8601 standard debate? -- Walter Görlitz ( talk) 21:35, 13 August 2010 (UTC)
IMO "from N1 to N2" and "N1..N2" should be preferred over "between N1 and N2" to avoid ambiguity, since "between N1 and N2" can be used colloquially to men either "greater than N1 and less than N2" or "equal or greater to N1 and less than or equal to N2" is used colloquially to mean could mean "between N1 and N2 exclusively" or "between N1 and N2 inclusively". It's generally not a problem with narrow ranges (for example it would be unusual for someone to use "between 2 and 4" as a verbose way of saying "3"), however it's less clear for broder ranges (for example the corvidae article contains the statement that "Corvids can lay between 3 and 10 eggs", which could be interpreted as either a needlessly awkward and ambiguous way of saying "3 to 10 eggs" or an even more needlessly awkward and ambiguous way of saying "4 to 9 eggs"). -- Gordon Ecker ( talk) 06:37, 11 August 2010 (UTC)
Use a non-breaking space (also known as a hard space) to prevent the end-of-line displacement of elements that would be awkward at the beginning of a new line:
When would you ever write "7 World Trade Center"? For one, "7" should be spelt out and two, why would you need a non-breaking space there? McLerristarr (Mclay1) ( talk) 12:44, 13 August 2010 (UTC)
There is a discussion at User talk:Art LaPella#Your AWB edits concerning whether WP:NBSP should be applied within date parameters of a citation template as in date={{Nowrap|6 November}} 2010. It also concerns whether hyphens within titles should be changed to dashes according to the WP:DASH rules that apply elsewhere, as in this previous discussion. LeadSongDog come howl! 15:10, 19 August 2010 (UTC)
Surely it would be more productive and less clutterous to handle this from inside the template, something like {{#time:j" "F Y|{{{date|}}}}}
in this. Try it. See also
mw:Help:Extension:ParserFunctions##time. ―
cobaltcigs 16:45, 19 August 2010 (UTC)
With appropriate conditionals you could make it follow the order of the input. A rudimentary attempt might look like this:
{{#switch:{{{date|}}}
| {{#time:j F Y|{{{date}}}}} = {{#time:j" "F Y|{{{date|}}}}}
| {{#time:F j, Y|{{{date}}}}} = {{#time:F" "j, Y|{{{date|}}}}}
| #default = {{{date|}}}
}}
Beyond that you could add a few more cases to catch abbreviated months, leading zeroes, missing or extra commas, and other common deviancies to achieve greater immediate penetration (fewer defaulting cases requiring preparatory clean-up).
Alternatively you could add a {{{df}}} parameter like those already present in {{ birth date and age}} and similar templates. This would simplify the code somewhat while allowing the {{#time}} func to catch nearly anything and reformat it according to {{{df}}}:
{{#if:{{{df|}}} <!-- day first -->
| {{#time:j" "F Y|{{{date|}}}}} <!-- 6 November 2010 -->
| {{#time:F" "j, Y|{{{date|}}}}} <!-- November 6, 2010 -->
}}
Yes, the ideal solution would be a way for one template to know which other templates are being used on the same page (namely whether they include {{ mdy}}/{{ dmy}}) and make decisions based on that, but it’s not possible with current software. Look on bugzilla for something about that. The next best solution may be for bots to add the {{{df}}} parameter to cite_foo template calls based on which format is declared on the page, but hey—if you already had planned to edit a bunch of pages… ― cobaltcigs 20:53, 19 August 2010 (UTC)
|dateformat=
it is unclear (at least to me) what function it performs towards defining the |Date=
parameter passed to
Template:Citation/core.
LeadSongDog
come howl! 16:13, 20 August 2010 (UTC)
I don’t believe the problems would be “endless”, but no-wrapping the entire parameter automatically within the template would be saner than no-wrapping the input manually in each article. I’d consider both options less than ideal, but the internal approach requires fewer edits and will be easier to adapt to whatever new software features come available. ― cobaltcigs 01:06, 22 August 2010 (UTC)
If you add the #iferror: function to the second example, you can default to the status quo when facing unformatted nonsense:
{{#iferror: <!-- return the following unless it produces an error… -->
{{#if:{{{df|}}} <!-- day first -->
| {{#time:j" "F Y|{{{date|}}}}} <!-- 6 November 2010 -->
| {{#time:F" "j, Y|{{{date|}}}}} <!-- November 6, 2010 -->
}}
| {{{date|}}} <!-- …in which case, act like nothing happened -->
}}
#iferror is not necessary in the first example as an error merely would cause the switch statement to #default. The disadvantage to the first is that it re-formats based on an exact match. The second example re-formats anything resembling a date, but requires instructions as to which format. A third way would benefit from some function to tell us quite simply the order in which the month and day appear in the input, or one which tells us which date format should be used in the article at large (by asking whether it transcludes {{ dmy}}/{{ mdy}}, etc.). ― cobaltcigs 01:52, 22 August 2010 (UTC)
If it isn't reverted, this edit probably, though not unambiguously, means that all date fields should be entirely Nowrapped. The edit only mentions a dd month yyyy date, leaving us guessing about month dd, yyyy. I think there is a parameter that does the same thing as Nowrap. The same should be done to the {{ date}} template itself. Art LaPella ( talk) 22:35, 22 August 2010 (UTC)
The price of plain text is inconsistent order of information and ambiguity with respect to which text is supposed to represent what. I think ideally we’d have a database table to catalogue reference citations, and thus be able for auditing purposes to pull up an immediate and exhaustive list of articles whose content depends upon a specific source, be it the Los Angeles Times or Poor Richard’s Almanack, with dates, authors, etc. in a similarly machine-readable format. For now all we have is the parameter list where each template is invoked. Some readers may enjoy having non-breaking spaces, spans of style="white-space:nowrap;" and other formatting quirks in the html output, but including them as part of the input (wiki-text) only will complicate attempts to parse said input. Same principle applies to infoboxes, succession chains, etc. as far as I’m concerned. ― cobaltcigs 06:12, 23 August 2010 (UTC)
|date=
fields in citation templates sounds like a sensible step. Art LaPella's recent edits to add lots of {{
nowrap}}s are in the right intention, but it's a 3,000,000 edit solution versus a single citation/core edit solution, and more nested templates in citations doesn't make them easier to read (maybe if citation/core is updated we can remove those manually added nowraps again). It's true that there are various incorrect formats in use out there, part of my contributions to
WP:AWB is to catch & tidy them. If there are more fixes to citation dates that AWB could make, let me know.
Rjwilmsi 23:01, 28 August 2010 (UTC)
There are several similar unit articles. Please see the merge discussions about the following unit articles:
Regards Lightmouse ( talk) 12:26, 20 August 2010 (UTC)
Rich, is there some reason the guidance should be changed to allow the spelling out of the number? Tony (talk) 00:47, 22 August 2010 (UTC)
Yes, there are a number of reasons that we should revert this change - which was a revert of this, which is a revert of this which changes the initial "may be expressed as numbers" introduced by you as part of your sweeping re-write in 2007, and later changed to "are". Prior to this the advice was explicit
As introduced by me, here in February 2006, and standing for a long time (apart form a brief words-only interregnum) pursuant to this discussion.
The previous apparent implicit advice to use numbers actually started out under this rubric:
In other words a description of page titles became, in time a prescription for a text style.
Having laid out the wiki-history (there are also historical discussions - see the archive) let us look at style:
Fist, usage - in books the words are almost always spelled out - picking up the two on my desk "Who's Who in the Bible" and "Flowers in Britain" both use this style - and the latter has many numerals in its text in the form of measurements.
Secondly style guides either support words or are agnostic.
Third, barbarism.
Fourth, consistency.
Fifth meaning - contrary to obvious expectation a century is not a mathematical construct, certainly there is a technical meaning 00:00 on the first day of 1901 to 24:00 on the last day of 2000, was the twentieth century, however it is also use to describe an era and can significantly over-lap or under-lap one or both of the official ends of the century, using a numerical format does not convey this meaning as well.
Sixthly layout - numerals disrupt the flow of the text, more so in some typefaces than others. And while they are welcome in scientific and technical contexts, which tend to be replete with tables and graphs, in discussions about humanities and arts they should be firmly kept in check (speaking as a mathematician).
Regards, Rich Farmbrough, 05:07, 3 September 2010 (UTC).
Here's few:
I've noticed most, if not all, of the articles on the planets and moons of the solar system do not give conversions in Imperial/US customary units. Is there a particular reason for this, and where is it covered in the MOS that this is permisible? Given that the bulk of EN.WP's readership is still in the US, this seems quite odd. Thanks. - BilCat ( talk) 07:49, 31 August 2010 (UTC)
"When there are different currencies using the same symbol, use the full abbreviation ... unless the currency which is meant is clear from the context." Using the same symbol in the world, or using the same symbol in the article? If we link and define "$" as the US dollar in an article that uses US dollars, is "$" good enough to represent the US dollar, even if that symbol means something else in a country closely tied to the article? (In this case, Argentinians use "$" for their peso and "US$" or similar for the U.S. dollar.) - Dank ( push to talk) 13:15, 20 August 2010 (UTC)
I have amended the point and put "in the article" back in. McLerristarr / Mclay1 04:47, 12 September 2010 (UTC)
MOSNUM and MoS are pretty similar, but there's a minor niggle, and it would be better to make the wording and order the same where there's an opportunity:
MOSNUM
MoS
Comments
The text used to read: Forms such as the 1700s are normally best avoided (although the difference in meaning should be noted: the 1700s is 1700–1799, whereas the 18th century is 1701–1800). 1700s is ambiguous, as it could also be confused for the first decade of the 1700s, 1700–1709.
This was changed to: Forms such as the 1700s are normally best avoided (although the difference in meaning should be noted: the 1700s may mean 1700–1799, whereas the 18th century is 1701–1800) 1700s is ambiguous, as it could also be confused for the first decade of the 1700s, 1700–1709. (The change being from "the 1700s is 1700–1799" to "1700s may mean 1700–1799")
Given the context is perfectly clear (highlighting that the 1700s and the 18th century are not the same thing, i.e do not cover the same years), 1700s can only mean 1700–1799, so the change to "may mean" is unnecessary at best and possibly just plain wrong. My reversion to the previous wording has been contested, so I seek clarification. Perhaps it would be best to reword it altogether. wjemather bigissue 09:30, 3 September 2010 (UTC)
This does keep coming up over [4] and over [5] and over [6] again, and it seems like everyone is loathe to actually provide guidance to editors on what to do the first decade of a century. I, myself, have been caught in a debate over the topic, in large part because I looked at WP:DECADE and WP:CENTURY and came up with a different answer than it seems most people reach. Based on the number of talk-page hits for "decade" [7], it seems I'm not alone. Instruction creep or no, we need a rule here to avoid confusion and ruffled feathers. How should one reword a sentence like "By the early 2000s, x happened" when one means the first few years of the decade spanning 2000 to 2009? If the answer is "it's okay if it's clear in context," I think that WP:CENTURY needs to say that. // ⌘macwhiz ( talk) 21:26, 18 September 2010 (UTC)
A question about SMS Goeben: "A total of thirteen men were killed and three were wounded." 13 and three? 13 and 3? Also, the addition I made to WP:MOSNUM to disambiguate, "in the article", that is mentioned up at #Currencies was apparently reverted ... anyone know why? - Dank ( push to talk) 03:19, 12 September 2010 (UTC)
It's like 2 × 2 = 4.1. You just can't argue it's wrong in some venues. Tony (talk) 12:57, 12 September 2010 (UTC)
Following the deletions of {{ st}}, {{ nd}}, {{ rd}} and {{ th}}, I've been looking through other misuse of superscripting in ordinals. this search suggests that over 10,000 articles are presently using "1st" for "1st", which is contrary to the general discouraging of superscripting present in the MoS for a couple of years. Any suggestions on the best way to move forward with correcting this? Chris Cunningham (user:thumperward: not at work) - talk 09:04, 16 September 2010 (UTC)
Use words for simple fractions; but use the numerical fraction form in a percentage, with an abbreviated unit, or mixed with whole numbers (an eighth of a millimetre, but 1⁄8 mm; 1+1⁄4 slices). Use figures for decimal fractions (0.025).
An eighth of a millimetre? Really? I won't bother to link to the brochure, but the SI explicitly says (this information may be out out of date) the fractions should never be used to represent the values of SI units.
This is almost promoting incorrect use (or representation, should I say) of metric units, it needs to be changed, in my opinion and there is truthfully little to argue against here for the ones who like picking fights. --
Γιάννης Α.
✆|
☑ 23:09, 20 September 2010 (UTC)
Fractions are compatible with SI. In fact, two of the seven SI base units (metre and kelvin) are defined as fractions. One of the definitions even uses the word 'fraction'. See the official SI website: www.bipm.org/en/si/base_units.
Regards Lightmouse ( talk) 09:02, 21 September 2010 (UTC)
—— Shakescene ( talk) 18:31, 21 September 2010 (UTC)Use words for simple fractions; but use the numerical fraction form in a percentage, with an abbreviated unit, or mixed with whole numbers (an eighth of an inch, but 1⁄8 in; 1+1⁄4 slices). Use figures for decimal fractions (0.025).
I think it's a bit too strong to say that every use of fractions with metric units should be avoided. When people go to the market or to a butcher's shop, they often buy a pound or half a pound of something, the pound being a metric pound defined as exactly half a kilogramme. But thinking in metric pounds is very slowly dying out, and younger people are more likely to buy half a kilogramme or a quarter kilogramme than older people. Similarly for distances. You would never see something like "1/2 kilometre" on a street sign in Germany or France, but it's what people say. IMO the important points are the following:
Fractions with metric units are usually inappropriate here, and that should be clear. But if we aren't careful with the formulation someone will go around and mechanically remove them even in the few cases where they are appropriate and better than the alternative. Hans Adler 00:20, 23 September 2010 (UTC)
MOS guidance is:
MOSNUM guidance is:
If you search for the word 'fraction', you'll find multiple references to fractions in MOSNUM. Some of which may be redundant. I don't know if MOS needs bringing into line with MOSNUM or vice versa. I think it's a guideline looking for a problem that doesn't exist. Editors appear to use decimal fractions for metric units anyway. The guidance could be removed and it wouldn't make the slightest difference to editor action. Lightmouse ( talk) 08:58, 23 September 2010 (UTC)
For proper disambiguation in date ranges between centuries I boldly edited from:
"The full closing year is acceptable, but abbreviating it to a single digit (1881–6) or three digits (1881–886) is not."
TO:
"In such case the full closing year is given, as abbreviating it to a single digit (1881–6) or two digits 1881–86) or three digits (1881–986) are not acceptable."—
Iknow23 (
talk) 06:44, 23 September 2010 (UTC)
Also, the prior one had a obvious error as the material was about (1881–1986), thus the three digit closing would be 986, not 886. —
Iknow23 (
talk) 06:49, 23 September 2010 (UTC)
Tony, I was wanting to take this as a two-step process. First I wanted to clear up what it is currently saying. Then I was planning to propose 'deprecating the two-digit closing range' in all cases. I didn't want to overscope this present discussion.—
Iknow23 (
talk) 21:29, 24 September 2010 (UTC)
Grk, THAT is how I was understanding it in that "The full closing year is acceptable" in all cases, but it was pointed out to me that it was in context ONLY with the 'different century' senario.—
Iknow23 (
talk) 21:35, 24 September 2010 (UTC)
From Wikipedia:Manual_of_Style_(dates_and_numbers)#Numbers_as_figures_or_words:
"Numbers that begin a sentence are spelled out, since using figures risks the period being read as a decimal point or abbreviation mark"
This looks to me like a hangover from the days of typewriters as it's a hugely implausible risk. There are already too many exceptions in this section and I suggest just removing this one. GDallimore ( Talk) 15:03, 25 September 2010 (UTC)
I would just like to point out that depricating two-digit years would violate ISO 8601, which would interpret 2008–10 as the tenth month in the year 2008. Using the dash in any case would not comply as ISO 8601 requires a solidus (as in 2008/2010) to represent time intervals, but perhaps two-digit years were discouraged at least to avoid ambiguity. — sroc ( talk) 13:13, 12 October 2010 (UTC)
I have been told that I'm not allowed to change BCE to the less ambiguously defined BC because of this "manual of style". Who can I go to if I want to discuss that rule?-- Axiom talk 22:44, 26 September 2010 (UTC)
To address the original question. If the article was created and past the stub staging using BCE/CE, then it should stay. If the article was changed to that after it was establish it should be discussed and the original format should be applied. This is the basic rule of the Manual of Style. BCE should not be changed to BC just for the fun of it or vice versa. -- Walter Görlitz ( talk) 04:14, 10 October 2010 (UTC)
Even for those who know what it means, I think readers tend to have a *neuron-trigger* of “something new” when they encounter instances of BCE. Accordingly, for articles directed to a general-interest readership (not the scientific papers to which our articles may refer), I think the newer “BCE” tends to be distracting just because more of us notice the choice of wording and that distracts from the thought. I am keen to avoid any writing style that calls attention to itself so I tend to avoid “BCE” to make the article read as fluidly as possible.
I know that those who like to use the new terminology probably find it more satisfying and will claim it is “natural” to them. But I honestly think that as writers, their minds are actually noticing the writing style and being pleased with the choices rather than not noticing the writing style and being absorbed in the thoughts being conveyed.
Finally, I don’t think “ambiguous” has anything to do with it. If one is reading an article on Egyptian pyramids, “It was built in 3000 BC” is just as clear as “It was built in 3000 BCE”. As far as I know, the admonition against changing one form to another is to avoid edit warring. Greg L ( talk) 16:48, 11 October 2010 (UTC)
Do you know the underlying reason for delimiting numbers with only the American-style commas? Seems rather chauvinistic, no? Because a given country in Europe might have three ways to delimit numbers and primary-school children are taught all three, including the American way (using commas). Americans are taught just one. So unless it is an especially scientific article (hopefully directed to a scientific readership), it is best to use commas for delimiting on en.Wikipedia because it causes the least confusion for its readership and allows articles to be read most quickly and naturally without brain (!) interruptions.
The same goes for the “ca” in scientific papers. Again, we think about the target readership. While it is certainly fun to write articles that look like they belong in a scientific journal, writing “approximately” is better.
The issue between “BC” and “BCE” is similar; though it is less so about “confusion” it is still about making articles read quickly and most naturally. For general-interest readerships I prefer BC as I have found through observation and experience that it is part of a writing style that least draws attention to itself. But this is just a generality—even for me. I agree with the use of BCE in a few rare cases, like “ Dating Creation” because it covers how a variety of religions date creation. For that particular article, concerns over religious sensibilities trump awkwardness (assuming one has already recovered from the cognitive dissonance of how the entire universe was created precisely 2,196,528 days ago on October 23, 4004 BCE). That article is quite the exception. Greg L ( talk) 21:53, 12 October 2010 (UTC)
The religious objection to BC/AD comes from their spelled out versions, In the year of (the/Our) Lord and Before Christ; non-Christian recognize Jesus neither as Lord nor Christ. Those are dealt with by the BCE/CE distinction, even if setting the zero-year is the same. See Anno Domini. The massive number of non-Christian English speakers suggests this is a serious issue for English Wikipedia. There are also massive numbers of Chinese, Japanese, Korean, and Eastern European users educated with "Common Era" or "Western Era" equivalents as their norm.
At a minimum, we could agree to exclude BC/AD from articles about the history of non-Christian cultures, about non-Christian religions, and from technical articles in the sciences where BCE/CE are used.
Rich, can't we deal with readability issues with a template link?-- Carwil ( talk) 15:06, 23 October 2010 (UTC)
On the WP:MOS page I proposed reducing the section Chronological items to a short paragraph that would serve as an introduction to the corresponding section in this article, much as I did with Units of measure and as other did with Geographical names. I have identified four items, each of a few sentences in the WP:MOS article that do not appear in this article. Three are non-contraversial insofar as they do not contradict anything here, but one might need some discussion. Does anybody have any objection to me cutting and pasting the three non-contraversial items into this article without further discussion and to open up discussion about the fourth here? Martinvl ( talk) 11:46, 7 October 2010 (UTC)
"Avoid inconsistent usage. Write a 600-metre (2,000 ft) hill with a 650-metre (2,100 ft) hill"
And yet the parentheticals are non-hyphenational. In the above example I would 2000-ft hill as "two thousand foot hill" and "(2000 ft) hill" as two thousand feet hill" which is clearly(?) wrong.
(Brief) Comments?
Rich
Farmbrough, 13:42, 10 October 2010 (UTC).
Meters can be units of length or they can be gauges one installs into a control panel. Feet can be units roughly a third of a meter long or something attached below one's ankle. Yards can be units or something one grows grass on. There can be bridges for cars, and there are footbridges. There can be foothills. Ergo, when a measure is being used as modifier, “We have 200-foot bridges” is perfectly distinct from “We have 200 footbridges”. When the measure is used as a modifier, the hyphen nails down meaning and avoids having the readers’ eyes double back because of brief confusion. And rigorously adhering to the hyphenation practice helps the eye to parse occurrences where the expression is not being used as a modifier, like “We have 200 yard sales.” This hyphenation practice holds true for unusual units that don’t look like something else, like “radian” because our minds are accustomed to the convention. So it’s “A two-radian arc segment.” The need to clarify disappears with unit symbols like “ft”, “m”, “yd”. In fact, none of the SI’s unit symbols look like words (although “mol” looks a bit like “mole”). And the common U.S. Customary unit symbols generally don’t look like words either.
To state the obvious: a parenthetical like (2000 ft) is not a modifier and is unambiguous. And, IMO, “2000-ft hill” and “2000 ft hill” are both examples of poor writing; use the spelled out unit of measure with the hyphen. Unit symbols should never be used in a modifier for regular prose. To ensure we are all on the same wavelength, “The building had a height of 200 feet” does not have the “200 feet” being used as a modifier and therefore does not get the hyphen. Greg L ( talk) 14:17, 11 October 2010 (UTC)
As for your examples mentioning “China Daily” and its “we are the world” thrust; there are scores of Wikipedias in languages other than English. We write for readers whose first language is English. If we wrote otherwise, our articles would look like Simple English.Wikipedia. Oh, BTW, that link to “Simple English Wikipedia” is to the “Autobahn” article. Even there, they skip spelling out such familiar units of measure because the readers are assumed to be literate and have seen a speed-limit sign if they are actually interested in the Autobahn. Greg L ( talk) 20:09, 17 October 2010 (UTC)
If an article uses citation in the form
where the publication dates are consistently distinguished in format from accessdates, is this a "breach" of this MOS guideline for "consistency"? Is it necessary to convert all such references to
Some developed and even featured articles have citations in the former form, and have had so for years with stability. The intro to this guideline says: "If an article has been stable in a given style, it should not be converted without a style-independent reason." Comments? Gimmetoo ( talk) 03:20, 19 October 2010 (UTC)
I agree with Tony & Stephen that
is preferable to the example with both publication and accessdate in ISO. But that's not the question I'm asking. The question here is whether, in references, the publication and accessdate can be consistently distinguished by format, or whether they must have the same format. There are quite a few articles where the publication dates are in dmy or mdy, and the accessdates are in iso. As an aside, there is no ambiguity in the iso accessdate in the example, even for someone unfamiliar with iso; reading the accessdate as January 8 puts it before the publication date, which is obviously wrong. Gimmetoo ( talk) 13:20, 19 October 2010 (UTC)
The presence of the format YYYY-MM-DD does not demonstrate that the publication in which it appears has adopted ISO 8601. In the absence of an explicit definition of what the format means in a particular publication, such dates are ambiguous.
Also, if one were to apply ISO 8601 to the publication date and one wanted to give the publication date of a current monthly magazine, one would be obliged to write 2010-10, which most uninitiated readers would not understand. Jc3s5h ( talk) 16:48, 20 October 2010 (UTC)
Note the following:
It has been discussed before.
Regards Lightmouse ( talk) 16:26, 22 October 2010 (UTC)
If you have a car, take a look at the metric speed on the speedometer. What does it use? Lightmouse ( talk) 17:18, 22 October 2010 (UTC)
Isn't the real problem here en-masse conversions from one name of a unit to another because of some OCD compulsion about consistency? Does it really matter which one is more common? No. The meaning is clear either way. The policy on semi-automated edits is clear: Unless a change is completely non-controversial, it shouldn't be done in a semi-automated fashion. Gigs ( talk) 00:54, 23 October 2010 (UTC)
km/h is the scientific way of writing it. That or kmh-1. McLerristarr / Mclay1 08:56, 23 October 2010 (UTC)
Many editors use non-standard, verbal, or specialist terms when a more accessible and/or standard term will do the same job. It was a surprise to me to find 'km/h' being questioned. Janitorial edits, by definition touch many articles so surprise questions are a common experience. I'd be grateful for mosnum to have guidance on this. I propose changing:
to
Lightmouse ( talk) 10:45, 23 October 2010 (UTC)
According to the SI ( here), the abbreviation for "hour" is "h" and the abbreviation for "kilometre" is of course "km". In my opinion, it doesn't matter what some people may use, "km/h" is the only correct way of writing it, unless you use kmh-1, but that's too technical for common usage and would confuse some people. McLerristarr / Mclay1 10:51, 23 October 2010 (UTC)
When using metric units always follow the official SI standards absolutely strictly. No variation. No debate. Otherwise what is the point of even having any standards at all? Roger ( talk) 11:07, 23 October 2010 (UTC)
I think we have reached a consensus: "km/h unless there's a good reason for using kph"
What do other people think? Pdfpdf ( talk) 13:33, 23 October 2010 (UTC)
The phrase good reason is redundant (you may not be aware that wp:iar could be applied on the end of all mosnum guidance) and subjective (because we don't know what you think is a good reason). We've merely moved the debate from a main clause to a subclause. I see now that you (Pdfpdf) can't give an example of a Wikipedia article (other than unit definitions and quotes) where good reason applies. Would you mind looking at the articles you reverted and seeing if any of those shouldn't be changed to 'km/h'? In order to downgrade the temperature of such edits (in response to well-taken comments by people like Gigs and yourself), I'd like to have mosnum guidance that can be taken to BAG. Lightmouse ( talk) 12:47, 24 October 2010 (UTC)
As it applies to automotive-related articles, if (big ‘if’) “km/h” is most common for car manufacturers and current, reliable literature on the subject, then that is what Wikipedia should be doing for its automotive-related articles. That statement does not apply to the practices that are universally or near-universially observed in other disciplines, like ‘ Rocket sled’. Greg L ( talk) 17:24, 26 October 2010 (UTC)
The above discussion focused on km/h versus kph. But the automobile conventions as quoted above are in conflict with this page because they recommend rpm instead of rev/min, mpg instead of mi/gal, and mph instead of mi/h. I know only American usage, but I think rpm, mpg, and mph are all much more common than their alternatives. It seems to me that the current guideline needs an exception, something like: However, if reliable sources consistently use a different style, such as mph instead of mi/h, follow the sources instead. Ozob ( talk) 14:01, 24 October 2010 (UTC)
Some disciplines use units not approved by the BIPM, or write them differently from BIPM-prescribed format. When a clear majority of the sources relevant to those disciplines use such units, articles should follow this (e.g., using cc in automotive articles and not cm3). Such non-standard units are always linked on first use.
Headbomb { talk / contribs / physics / books} 14:16, 24 October 2010 (UTC)
My point—which I guess I failed to make clear above—is twofold. One, the "clear majority" provision is under "scientific and technical units", so it might be interpreted to not apply generally. Two, MOSNUM mentions mph and psi as exceptions to rule about division and then says "etc." It seems to me, judging from the conversation here, that the "clear majority" provision should apply more broadly, and that the "etc." should be taken to mean "clear majority". Currently MOSNUM doesn't do this. Does anyone else see this as a problem? Ozob ( talk) 00:59, 25 October 2010 (UTC)
The term 'micron' had an official status between 1879 and 1967. It was officially removed from SI 40 years or so ago. The terms 'centigrade' and 'micron' continue to be used by many people but I think it would be worth having mosnum guidance on the use of the both terms 'centigrade' and 'micron' within WP.
Here are some issues that occur to me:
Ability to guess the meaning
The benefits of SI are that they do away with special names that have to be learned or explained. It has a simple format (prefix plus unitname). From that simple format, you can guess the size and/or the unit. Somebody may not have heard the term microwatt before but they should be able to realise it's 'micro' plus 'watt'.
Accessibility - micrometre/er is universal, the term micron isn't
Scientists are aware of both terms and there is no domain or geographical region which doesn't use the SI term. The term 'micron' is used by some (the term 'some' meaning anything less than 100%) scientists in some technical domains and some geographical regions. However, some ordinary people don't know what a micron is (as is shown by the multiple cases where it has to be explained in text). Thus the SI term is more accessible.
Ambiguity The American spelling of micrometer is ambiguous as a single word. Metrology has several ambiguous words (e.g. 'foot', 'yard', 'minute', 'second', 'mole'). However, the meaning of micrometer is always clear from the text (e.g. "the wavelength is 54 micrometers", "we measured it with a micrometer"). That may apply with most of the ambiguous unit terms used in WP articles.
Similar terms as the scale changes e.g. nanometer, micrometer, millimeter It is convenient to be able to scale units using similar terms. This can be seen in text such as US NIST: "from deep violet at 400 nanometers (nm) to near infrared at 4 micrometers (μm)"
Guidance Style guides provide the benefit of consistency across the project. WP isn't tied to one particular domain or geographical region. As with guidance on several issues, we can come up with our own consistent guidance so editors don't have to debate the issue on each article. I propose the following guidance:
Comments welcome. Regards Lightmouse ( talk) 17:13, 20 October 2010 (UTC)
{{
cite journal}}
: |pages=
has extra text (
help); Unknown parameter |coauthors=
ignored (|author=
suggested) (
help)On the Corpus of Contemporary American English, even restricting the search to texts from the 2005–2010 period, there are 50 occurrences of micron, 43 of microns, 46 of micrometresmicrometers, and 32 of micrometremicrometer (and a few of the latter refer to the tool). That doesn't sound like obsolete to me. (OTOH, IMO the use of μ alone for the unit is dead: I've only ever seen μm except in publications several decades old.) Conversely, in the corpus and the same period, there are 147 occurrences of Celsius compared to 23 of centigrade, so I wouldn't object to discouraging the latter – providing it's actually used often on Wikipedia, per
WP:BEANS.
A. di M. (
talk) 13:58, 21 October 2010 (UTC)03:06, 22 October 2010 (UTC)
So I did a quick search using google to see how many times one or the other term popped up, with the results reported in 1000s of hits. I didn't take into account any overlap between the three terms in the same article (assuming they were usually consistent) but did search using both the singular and plural form. Now, the way Google works, you actually get more hits just searching on "Infrared micrometer" than searching on "Infrared micrometer OR micrometers" which is illogical, probably having to do with what it considers important in your search terms and how many you have specified. But since the three searches in each case used a parallel form, I would conjecture that their results are comparable and the percentage of use of the word "micron(s)" is indicative of the word's actual popularity.
It can be seen that there are some differences in this number between different fields, but that "micron" wins out over "micrometer/re" in each case. Some of the occurances of "micrometer" may have referred to the measuring instrument, and I avoided keywords relating to machining for that reason.
Finally, in every case the use of the symbol μm paired with the keyword was more frequent than any of the searches with the word, but that is not at issue: we all agree on using μm (as mandated by BIPM) rather than the obsolete version μ.
Google search term Hits × 1000 Percentage using "micron"
Infrared micron OR microns 1380 64%
Infrared micrometer OR micrometers 530
Infrared micrometre OR micrometres 230
interferometer micron OR microns 260 66%
interferometer micrometer OR micrometers 107
interferometer micrometre OR micrometres 28
Grating micron OR microns 1440 90%
Grating micrometer OR micrometers 150
Grating micrometres OR micrometres 11
X ray micron OR microns 1440 65%
X ray micrometer OR micrometers 685
X ray micrometre OR micrometres 99
Cellular micron OR microns 1480 88%
Cellular micrometers OR micrometers 174
Cellular micrometres OR micrometres 23
semiconductor wafer micron OR microns 743 71%
semiconductor wafer micrometer OR micrometers 228
semiconductor wafer micrometre OR micrometres 69
nanotechnology micron OR microns 274 57%
nanotechnology micrometer OR micrometers 141
nanotechnology micrometre OR micrometres 65
protein micron OR microns 1580 61%
protein micrometer OR micrometers 967
protein micrometre OR micrometres 45
No field specified:
micron OR microns 12600 77%
micrometer OR micrometers 3600
micrometre OR micrometres 268
Interferometrist (
talk) 18:58, 21 October 2010 (UTC)
In my opinion, micrometre is universally understood to anybody who has a basic knowledge of maths. Micron is far less common, in fact, I've never heard it used except when talking about the width of hairs. McLerristarr | Mclay1 12:01, 24 October 2010 (UTC)
wp:engvar says "Wikipedia tries to find words that are common to all varieties of English." Similarly, Wikipedia should use terms that are suited to the widest international audience including non-specialists. As Greg suggests, domain specialist terms constantly seeping out from in-house publications into wider domains by 'monkey see, monkey do'. Wikipedia benefits from using SI by default and deviating only if good reasons exist (and hopefully get documented here). Organisations like BIPM (SI units) and NIST (American units) were specifically created to provide stable references for inter-domain, inter-region communication. As Jc3s5h, suggests, anyone that understands 'micron' also understands 'micrometre/er' but the reverse isn't true. I propose the following guidance:
I hope that guidance encapsulates the issues. Lightmouse ( talk) 14:19, 27 October 2010 (UTC)
• Some disciplines use units not approved by the BIPM, or write them differently from BIPM-prescribed format. When a clear majority of the sources relevant to those disciplines use such units, articles should follow this (e.g., using cc in automotive articles and not cm3). Such non-standard units are always linked on first use.
You said "MOSNUM already has clear guidance that SI is preferred" and quoted some text from mosnum. Unfortunately it doesn't. If it did, I would have quoted mosnum at Pdfpdf when he swore at me for applying 'km/h' rather than 'kph'. Lightmouse ( talk) 18:46, 27 October 2010 (UTC)
*In general, put the units first that are in the most widespread use in the world. Usually, these are International System of Units (SI) units and non-SI units officially accepted for use with the SI; but there are various exceptions for some measurements, such as years for long periods of time or the use of feet in describing the altitude of aircraft.
* In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s−1.
P.P.S. Speaking of other industries that seem to be still using micron, I note this patent application by Apple for a vapor deposition nitriding coating to stainless steel. It speaks of a coating thickness of “15 microns”. It appears that the use of “microns” is another one of those things on which the the world may be soundly ignoring the BIPM; the proper use of the percent symbol (75% and not 75 %) being another one that immediately comes to mind. Greg L ( talk) 19:54, 29 October 2010 (UTC)
To get this conversation separate from the kph one, the policy is not merely the AWB instructions, it's Wikipedia:Bot_policy. Semi-automated edits that blindly change articles en-masse are covered by the bot policy. Specifically, "Contributors intending to make a large number of assisted edits are advised to first ensure that there is a clear consensus that such edits are desired." If reasonable people are complaining about it, there is not a clear consensus.
"Enforcing" the manual of style with thousands of edits absolutely falls under this. This is why the above conversations counting Google hits for one formatting of a unit vs another are irrelevant. If these changes are controversial enough that they require that sort of conversation, then they should never be done en-masse.
I suggest that complains like pdfpdf's be taken much more seriously. Yes, he degenerated into incivility in the end, but that was after trying to make many good faith efforts to explain that the changes were controversial and unwanted. Gigs ( talk) 18:25, 23 October 2010 (UTC)
User:Gigs defines controversy as one query on a talk page. Unfortunately, that definition is retrospective and disproportionate. None of us can predict that an edit will not result in a query from any editor. The correlation between query and controversy is much less than 1:1. Wikipedia would need to ban bots and janitorial editing because no admin or editor can guarantee in advance that queries won't be posted to somebody. I prefer something closer to that at wp:cont: "A controversial issue is one where its related articles are constantly being re-edited in a circular manner, or is otherwise the focus of edit warring. " There are editors that do good work by copy-editing and there are editors that do good work by widespread sub-editing. Consistency and house style actually require many small changes of detail which sometimes makes people with a local article focus ask questions. If sub-editors gave up, nobody would ever get into trouble, but Wikipedia would be worse and certainly less accessible to those without the local article focus. Despite public debates like this one, there's a lot of behind-the-scenes bot, script, and mass editing on Wikipedia and that is a good thing. Lightmouse ( talk) 12:27, 24 October 2010 (UTC)
Any automated changing of units should be done with care and consensus. Lightmouse has been overriding the default conversion for acres from ha to km2. I think there was a similar issue with nmi. Changes like this are clearly ones that need to be discussed. I will say that finding a good place to discuss these will always be an issue since no matter where it is announced, a good number of editors will be missed. Vegaswikian ( talk) 22:43, 26 October 2010 (UTC)
I'd like to do a sub-edit run (unit definition articles and quotes won't be included) to convert synonyms of the symbol of kilometre to lower case 'km', and the symbol of kilogram to lower case 'kg'. . See Wikipedia:Manual_of_Style_(dates_and_numbers)#Unit_symbols:
I'm being cautious so I'm checking here first and then taking it to BAG. Comments? Lightmouse ( talk) 13:09, 24 October 2010 (UTC)
As a courtesy for those who care, I'm hereby informing everyone (who cares) that I am busy for the next week and won't be responding to questions/comments/etc in a timely manner. If you REALLY want a response from me before next week, send me email, and then go to my talk page and warn me to look out for your email. (The email account I link to WP gets a lot of junk, which I generally ignore.) Pdfpdf ( talk) 10:22, 25 October 2010 (UTC)
This is spell-checking; bots should not be doing it (for precisely the reasons indicated in this section; bots cannot tell when an exception should be made). To quote policy; Bot processes may not fix spelling or grammar mistakes... in an unattended fashion, as accounting for all possible false positives is unfeasible. Lightmouse's record does not encourage me about an attended fix either; but if somebody is willing to check over his shoulder, that would be another question.
But fundamentally, why do this with a bot at all? If there is project-wide consensus for this fix, the normal process of fixing errors as they are noticed will take care of it, as it takes care of teh; if not, it should not be done at all. Septentrionalis PMAnderson 17:12, 27 October 2010 (UTC)
It appears uncontroversial that we should assist editors by adding the final sentence below.
“ | The symbols for the degree Celsius, the degree Fahrenheit and the kelvin are °C (not C), °F (not F), and K (not °K) respectively. (C and F are the symbols for the coulomb and the farad respectively; °K is the symbol for the degree Kelvin, the pre-1968 name of the kelvin.) Use the term 'degree Celsius' rather than 'degree centigrade' (except in text describing history of units). | ” |
Your thoughts, please? Lightmouse ( talk) 13:52, 28 October 2010 (UTC)
It's one of those colloquial words that people add from time to time. Trust me, there are editors out there that sub-edit articles to replace such terms and it'd be worth having a guideline to make it clear in case somebody ends up swearing at them. Lightmouse ( talk) 14:33, 28 October 2010 (UTC)
There's only 128 because editors like me keep changing it to Celsius. I do a run from time to time and even in my routine work, I pick them up. There are other editors that do it too. Google shows centigrade in 7 to 25% of hits (depending how you search), so it's not surprising that it finds its way into WP articles. I found the following instances just now:
We have some astonishing trivia in explicit detail on mosnum, yet routine stuff isn't. Gnoming editors are in a Catch 22 where one person can swear at them because mosnum doesn't document consensus for <insert standard term or format> but if the consensus is strong, it won't be documented. The way things are right now, we need to vote on everything. Lightmouse ( talk) 11:41, 29 October 2010 (UTC)
(arriving late to this discussion) Yes. “Centigrade” is beyond archaic and should only be used in direct quotes or when talking about the history of the temperature scale. Greg L ( talk) 19:59, 29 October 2010 (UTC)