Jump to content

Wikipedia talk:Manual of Style/Dates and numbers

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style
This is an old revision of this page, as edited by CIS (talk | contribs) at 03:28, 28 July 2011 (→Permanent compromise for BCE/CE vs. BC/AD wars?: reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Template:DocumentHistory

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

This talk page is for discussion of the page WP:Manual of Style (dates and numbers). Please use it to make constructive suggestions as to the wording of that page.


−
This is a test
+
This was a test!

circa

The guideline exemplifies the preferred abbreviation in roman face, c., although italicises the spellings-out. I've often wondered which is correct for the single-letter abbreviation. A recently promoted article, Deusdedit of Canterbury, has the italics. Tony (talk) 10:18, 10 July 2011 (UTC)[reply]

According to one source:
It does suggest that circa is an exception to that rule. However, there's no point in Wikipedia having a guideline of such small detail that will be ignored frequently. Thus for consistency and pragmatic reasons, I think Wikipedia shouldn't make that exception i.e. it should be roman just like 'etc' and 'i.e.' Lightmouse (talk) 10:44, 10 July 2011 (UTC)[reply]
It's my gut reaction too; but other opinions are needed, I think. Tony (talk) 13:32, 10 July 2011 (UTC)[reply]
Parts of this discussion seem unaware of the existing WP:YEAR guideline: "the unitalicised abbreviation c. is preferred over circa". That is, we already specify unitalicized "c.", and deprecate "circa", so it doesn't matter whether the wrong way ("circa") should be italicized or not. Art LaPella (talk) 18:05, 10 July 2011 (UTC)[reply]
I agree that the WP:YEAR guideline already settles the question about "c.", and that it should be unitalicized. When the guideline uses italics for the spellings-out ("circa", etc.), I read that as an emphasis on those words, and not a recommendation that they be italicized. Similar to an earlier example (MOS:TIME) that uses italics to emphasize "a.m." and "p.m.", but it is not a recommendation to italicize them, as the examples show "a.m." and "p.m." as unitalicized. CuriousEric 19:44, 10 July 2011 (UTC)[reply]
The OED italicises circa in an example, plus the two quotations it gives that use circa also italicise it. If anyone can access the online OED, the link is this. McLerristarr | Mclay1 04:35, 11 July 2011 (UTC)[reply]
For whatever it might be worth, c. (unitalicized) is the accepted U.S. & Canadian (and perhaps Mexican) abbreviation for "cent" (or centavo) when the symbol ¢ is unavailable or hard to create (I just had to look it up in Windows' character map because it's not on computer keyboards as it was on American typewriter keyboards). But unlike $ and c. for circa, c. for "cents" comes after the numbers. I sometimes lean towards using ca without a full stop/period for circa, but that raises the British/American quandary about non-terminal periods/full stops. —— Shakescene (talk) 06:11, 21 July 2011 (UTC)[reply]

Conversion of acres: can we write a bit more detail into the guideline?

There's been discussion about the conversion of acres (again), and I appears that there's no easy solution. I do believe editors need more detail in the guidelines about whether to convert to hectares or square metres or what. I have no idea what the solution is, but I find this, from Symphony Park very reader-unfriendly—both the originals and the conversions. Can't the rat of zeros be avoided? And can't we identify areas in which the ability of readers to visualise the quantities suggests how to express them?

Your input would be appreciated. Tony (talk) 10:12, 12 July 2011 (UTC)[reply]

From my experience, the floor area of buildings is seldom expresed in hectares, but the area of land is expressed in hectares once irt becomes convenient. I, personally, would use hectares for land areas of over 10,000 m2 and display only the required number of significant digits. Martinvl (talk) 11:39, 12 July 2011 (UTC)[reply]
I'd go with the unit most closely matching the source one (i.e. convert square inches to square centimetres, square feet and square yards to square metres, acres to hectares, and square miles to square kilometres). ― A. di M.​plé​dréachtaí 11:49, 12 July 2011 (UTC)[reply]
I tend to agree, using different output units based on the resulting size would be confusing. So converting acres below 2.5 acres to use sqm and the others to use ha is confusing. Just use ha. For cases where the output unit is critical it can be specified, otherwise the default should just be used. In the example above, the lack of full implementation of million is the problem with the generated text, using e6 in the first case gives you 11×10^6 sq ft (1.0×10^6 m2) rather then the desired 11 million sq ft (1 million m2). Vegaswikian (talk) 18:53, 12 July 2011 (UTC)[reply]
Spelling out “million” before a unit symbol does look weird. I would either spell out the unit name as well or use ×106. (“The $6 billion project is projected to include 11 million square feet (about 1,000,000 m2) of space on 61 acres (25 ha). Plans call for 1,908 thousand square feet (177,300 m2) of office and medical space, 5,200 thousand square feet (483,100 m2) comprising 3,200 residential units, 3 hotels providing and estimated 1,800 to 2,300 rooms in 1,575 thousand square feet (146,300 m2) of space with 475 thousand square feet (44,100 m2) of retail. The area is also expected to include 60–100 thousand square feet (6,000–9,000 m2) of casino space.”) ― A. di M.​plé​dréachtaí 19:54, 12 July 2011 (UTC)[reply]
No lack of implementation in {{convert}} in this respect. That it doesn't spell out "million"" before the abbreviation was quite deliberate. As A. di M. says that looks weird. That's why we have a guideline against this: WP:MOSNUM#Unit symbols says "Units symbols are preceded by figures, not by spelled-out numbers: for example, 5 min, not five min." JIMp talk·cont 20:04, 12 July 2011 (UTC)[reply]
Commercial office space in the US is leased by the square foot but this has no connection to a 12 by 12 inch square. Some times it is the actual carpeted floor space in your office suite and some times it is the percentage of the entire building including lobbies, rest rooms, hallways, elevators, and utility rooms. The same size office may be leased as 4000 square feet or 5000 square feet. (And a whole range in between.) Do not assign too much precision to commercial office space area. -- SWTPC6800 (talk) 22:51, 12 July 2011 (UTC)[reply]

Acres: a brief search found these examples. WP's treatment of acres looks like a real mess. I'm so glad I don't write articles that involve such areas. I wouldn't know where to go for guidance.

Good examples. I'd be interested in what people think about the following similar sizes:
Lightmouse (talk) 13:20, 13 July 2011 (UTC)[reply]
If the original measure has a very high or low value, that already may make the unit ill chosen. It is not the task of the conversion template to correct that. The choice of target unit should be determined only by the input unit, not the size of the quantity. So sq mi to km2, acre to ha, sq ft to m2. Predictable output is important. The user can always override the default. −Woodstone (talk) 04:15, 14 July 2011 (UTC)[reply]

Date template

Is there any reason this page doesn't mention {{date}}? This can be used to automatically format dates like the old system but doesn't link them. We ought to think about when it should or shouldn't be used.--Doug.(talk • contribs) 23:25, 15 July 2011 (UTC)[reply]

We pick the appropriate format for the article. We don't attempt to present different versions of the article to different readers. So what reason would there be to use {{date}}?— Preceding unsigned comment added by Jc3s5h (talk • contribs) 02:58, 16 July 2011
Hmm, well we used to use linked dates just for that reason, so we could display dates as the user wanted to see them. We didn't get rid of that for the reasons you state, we got rid of it because linked dates are dumb and we were linking solely so we could get the date to auto-format. {{date}} does what linked dates did but without the link (though it can do that too).--Doug.(talk • contribs) 20:27, 17 July 2011 (UTC)[reply]
You are just wrong. We got rid of automatic formatting because automatic formatting is a bad idea. Jc3s5h (talk) 21:12, 17 July 2011 (UTC)[reply]
Ouch! Let's make that "I disagree. We actually ..." I've never used that template and can't imagine why I would, but if you click "What links here" and "transclusion count", it says the template has been transcluded 11475 times. Art LaPella (talk) 21:55, 17 July 2011 (UTC)[reply]
Could you try telling me why you think it's a bad idea? Even if you manage to get the date consistent and keep it that way in a single article, when I click on the next article it will inevitably look different if we don't auto-format (or set an across the wiki standard); however, with the template the date will always appear the same for each user, it just may appear different for two different users - but the information conveyed will be the same. Besides, my point wasn't why don't we tell everyone to use it all the time, it was why don't we address it. Auto formatting with wikilinks was a problem for years for many different reasons, it was easy to deprecate a process that didn't work. Notice that the current reference to autoformatting says that dates shouldn't be linked just for autoformatting but it doesn't say that they shouldn't be autoformatted. That's because it used to be the normal we did that. --Doug.(talk • contribs) 04:59, 18 July 2011 (UTC)[reply]
Did you mean me? As I said, I've never used it. But the date template document (assuming it can be fixed) doesn't match your description, especially "it just may appear different for two different users". The document says the second parameter choices are dmy, mdy, ymd, iso, and blank which defaults to dmy. So if the second parameter is dmy for instance, then won't everyone see dmy regardless of their Wikipedia:Preferences?
If not, date preferences never made much sense anyway. They only work if you have an account, and if you have an account you're almost certainly an editor, and if you're an editor you should look at dates the way most readers see them on Wikipedia, not how your country sees dates off Wikipedia.
As for "why don't we address it", I didn't rule that out. I said the template has been transcluded 11475 times. Therefore the template must be of interest to whoever is adding it to articles. Art LaPella (talk) 05:31, 18 July 2011 (UTC)[reply]
Not at all, I was responding to Jc3s5h's "You are just wrong . . . automatic formatting is a bad idea." (that's why I outdented). I want to know why is is automatic formatting such a bad idea? I do appreciate your further explanation of your position and you are right, I thought that the template was applying user preferences but that's apparently because it's default output is consistent with my user preferences ;). The question of mentioning the template is therefore less important. But the question of autoformatting remains. I don't see why it's so undesirable. No other encyclopedia has one article with one style and one article with another style depending on either 1) where or who the article is about or 2) who started the article and there is no really good reason to do that except that it's a good compromise for editors from different areas - it makes no sense for actual users of our Encyclopedia which editors often forget are really whom we are here for. --Doug.(talk • contribs) 09:54, 18 July 2011 (UTC)[reply]
In addition to the reason stated by Art LaPella, that most of our readers wouldn't benefit from date autoformatting because they don't have accounts, it's too complex to get it right. Consider the example taken from the Associated Press Stylebook being discussed at WT:MOS#Punctuation after date:

Feb. 14, 1987, was the target date.

(Of course Wikipedia chooses to spell out dates and AP chooses to abbreviate them, but that does not matter.) If this were changed to the day-first format, the sentence should become 14 Feb. 1987 was the target date, but no one likes to start a sentence with a numeral, so a human editor would rewrite the sentence as The target date was 14 Feb. 1987.
You'll never get an automatic system to do that on the fly, and you'll never get editors to imagine all the ways their writing might be presented and structure their writing so it will look right with any date format. Jc3s5h (talk) 12:33, 18 July 2011 (UTC)[reply]
This makes sense, thanks for the response.--Doug.(talk • contribs) 13:05, 18 July 2011 (UTC)[reply]

Transclusions: The template isn't used often. It only looks like that because it's embedded in several templates. Lightmouse (talk) 10:18, 18 July 2011 (UTC)[reply]

  • Is there any reason this template shouldn't be listed for deletion? It goes in the opposite direction to the community consensus established in 2008 and 2009 that dates shouldn't be auto-formatted. Please let's not introduce yet another hurdle for the new editors we really need to attract to en.WP; and the simple what-you-see-is-what-you-get has turned out to work very well. Tony (talk) 11:01, 18 July 2011 (UTC)[reply]
  • This should be addressed by a group consisting of (1) template authors who have used the date template and (2) expert template writers, to see if it actually provides any benefit in templates. I do not belong to either group. Jc3s5h (talk) 12:33, 18 July 2011 (UTC)[reply]

'Template:Infobox poker player' appears to be responsible for 60% of the transclusions. The date template was embedded in 2009. Its only function is to accept '2011-07-07' or '7 July 2011' in edit mode to get '7 July 2011' in read mode. Lightmouse (talk) 12:47, 18 July 2011 (UTC)[reply]

  • (ec response to Tony1) Because the template is largely intended for nesting in other templates as mentioned by Lightmouse. I brought it up here because I thought it did something it doesn't. It does autoformat, it doesn't autoformat according to user preferences, as Art LaPella pointed out to me.--Doug.(talk • contribs) 13:05, 18 July 2011 (UTC)[reply]

If I understand this date template correctly, it is an abortion that should never have been made. It only affects how the dates appear for A) registered editors, B) who change their date preferences from “No preference.” Well over 99% of our readership will just see a default format (18 July). The use of this template just allows registered editors (those responsible for ensuring text is consistent and appropriate) from seeing that there might be a hodge-podge of different date formats in an article because the template effectively says “Here crybaby, we won’t darken your doorstep with a date format you don’t like to be exposed to.” My recommendation is to discourage use of the {date} format and for all editors who actually care about what our readership is seeing to set their date preferences to “No preference.” Greg L (talk) 15:40, 18 July 2011 (UTC)[reply]

Actually, I'm not so sure now that it doesn't actually override user preferences and output 18 July 2011 no matter what format you prefer, which would make that 100% of readership. But, as it's intended for use inside of another template, it isn't really MOS issue in my opinion. I've learned a lot about the template and I no longer think it needs to be mentioned here. Whether the template should be canned (and I'm starting to lean in favor) is really a question for the template's talk page and/ort TfD.--Doug.(talk • contribs) 17:22, 18 July 2011 (UTC)[reply]
  • It’s right in its documentation that it formats dates per user preferences. The important thing to remember here is that regular visitors to Wikipedia don’t have user preferences. Making a tool like the {date} template was a way to appease editwarring editors years ago. The realization now is that any tool that gives some registered editors a different view of mainspace body text than what the rest of the world sees is bad ‘cess. I am in general agreement with you that it the tool isn’t worth a bucket of warm spit. But since this is a manual of style, and the use of that template affects how articles read, it is not at all wrong to *mention* the {date} template; but in this case, “mentioning” it would be to suggest that best practices is for editors to not use it (for the above-mentioned reasons). That might speed the thing to the grave, which is belated. Greg L (talk) 19:43, 18 July 2011 (UTC)[reply]

OK, Experiment time. This date: July 18, 2011 was coded as {{date|2011-07-18|mdy}}. Let me try this… (one moment, I’m in “Show preview” mode)…

With “No preference” in my date preferences, I see “July 18, 2011”. With my prefs set to “20:33, 18 July 2011”, I see the same thing. So…

Why would someone want to learn to use this template? What good is it? If I wanted a date to read July 18, 2011, why would I type {{date|2011-07-18|mdy}}?? Someone explain this to me, please. Greg L (talk) 20:38, 18 July 2011 (UTC)[reply]


P.S. Apparently, it has utility somewhere in obscure practices with dates in highly structured sections, such as tables and other templates. I agree with Doug; it doesn’t need to be mentioned here. Greg L (talk) 20:48, 18 July 2011 (UTC)[reply]

Yes, Greg is right. The template does not autoformat dates at all. It just formats them. It can be useful within another template to standardise output format when given varying input format. Also if you're converting the format of a date (say for consistency), using the template is quick and might be less prone to errors. JIMp talk·cont 00:27, 19 July 2011 (UTC)[reply]

The majority of cases are not useful. For an example of trivial use, see: 'Template:Infobox poker player'. If it has non-trivial uses, that's fine but trivial uses should be removed to simplify things for readers. Lightmouse (talk) 12:26, 19 July 2011 (UTC)[reply]

BC/BCE yearspan guideline issue

I don't believe the guideline is very clear... is it best to use the notation BC/BCE for both years in a span contained before the Christian Era (i.e. 20 BC – 10 BC), or just after the latter year (i.e. 20 – 10 BCE)? I ask this because I am coming across several articles across the main article space that use either or, and it could be confusing for readers. Especially if they aren't aware that BC years count backward as time moves forward. Thoughts? Should we decide on and clarify this?. — CIS (talk | stalk) 03:16, 17 July 2011 (UTC)[reply]

WP:YEAR says: "A closing BCE or BC year is given in full (2590–2550 BCE). While one era signifier at the end of a date range requires an unspaced en dash (12–5 BC), a spaced en dash is required when a signifier is used after the opening and closing years (5 BC – AD 29)." It doesn't explicitly state that the answer is the unspaced 20–10 BC (or BCE; don't forget the nbsp). But that's how the first example is formatted, and the only example where a "signifier is used after the opening and closing years" is where one signifier is BC and the other is AD. Art LaPella (talk) 05:17, 17 July 2011 (UTC)[reply]

Contradictory guidance on the symbol for litre

The guidance says:

and

These appear to contradict each other. What should it say? Lightmouse (talk) 18:55, 17 July 2011 (UTC)[reply]

  • This means that the MOSNUM would consider these entries correct, if they were in a table or another location where space was at a premium (and no conversions were appropriate): "15 ml", 2 L. The idea if using two symbols for the same unit in the same article seems like a bad idea to me. Jc3s5h (talk) 18:59, 17 July 2011 (UTC)[reply]

Ah yes. I see now. I'll delete the first phrase as a contradiction. For the second phrase in 'Specific units' I propose changing:

  • Symbol:Use upper case L when not preceded by a prefix. to Symbol: l or L when preceded by a prefix. L when not preceded by a prefix.
  • Comment: The solitary lower case l is avoided to reduce confusion with the digit 1. to Comment: The symbol l can look like the digit 1 when without prefix.

Does that make the meaning clearer? Lightmouse (talk) 19:25, 17 July 2011 (UTC)[reply]

That does make it clearer, but the bigger question is, should we allow different symbols for the same unit in the same article? I would change Use upper case L when not preceded by a prefix. to "Use upper case L when the symbol is not preceded by a prefix anywhere in the article.
I acknowledge my change would change the intent, not just clarify. Jc3s5h (talk) 13:10, 18 July 2011 (UTC)[reply]

A fair point. We have two issues:

  1. The existing guidance isn't clear. I'll update the text as described above, unless there's any objection.
  2. We need a debate to consider whether the guidance is what we want.

Lightmouse (talk) 13:30, 18 July 2011 (UTC)[reply]

Support I support this guidance. A solitary "l" can be mistaken for a "1", so it's fair that we disallow them. Consistency demands that we use "mL", "cL", "kL", etc. if we're using "L". JIMp talk·cont 00:38, 19 July 2011 (UTC)[reply]
Oppose. The capital in prefixed units "mL" and "cL" is relatively rare. We should not adopt it as the only approved version. In "ml" and "cl" no confusion is likely. Even the "l" by itself is not really confusing, because a single digit "1" cannot occur in a similar position. We should not deviate from the advice given by the official SI documentation. −Woodstone (talk) 05:18, 19 July 2011 (UTC)[reply]

Seems to be a solution looking for a problem. The only commonly used derived units are µL, mL, and L. Centiliters seem to be more common in Europe. Larger volumes are given in liters or cubic meters. --Rifleman 82 (talk) 05:51, 19 July 2011 (UTC)[reply]

Oppose - The current Wikipedia guidance is a rahash of the SI brouchure. In the United Kingdom millilitres are usually written "ml" rather than "mL" (at any rate the items in my fridge and store cupboard). I agree with User:Woodstone that we should not deviate from the SI Brochure unless there is good cause.

Ref: International Bureau of Weights and Measures (2006), The International System of Units (SI) (PDF) (8th ed.), ISBN 92-822-2213-6, archived (PDF) from the original on 2021-06-04, retrieved 2021-12-16

Martinvl (talk) 06:38, 19 July 2011 (UTC)[reply]

Comment I prefer the lower-case versions and would oppose banning them. I just would want to see "ml" alongside "L". Woodstone raises a good point that the "1" wouldn't appear in the same position. JIMp talk·cont 07:40, 19 July 2011 (UTC)[reply]

Stop voting. Nobody has presented proposed text to change the intent of the guidance. This thread is only about whether we need to eliminate a contradiction and failure of clarity in *existing* guidance. User:Jc3s5h suggested changing the intent of the guidance but before a vote, please take it to another thread. In the meantime, I'll update the *existing guidance* to make clarify (as far as I can) the *existing intent*. 10:25, 19 July 2011 (UTC)

Templates: height and convert

We have two templates: 'height' and convert. Although they are written differently, they have overlapping capabilities. Each has its own discussion page but there isn't a forum for discussion relating to the overlap. If the output is the same, when should an article use one rather than the other? Lightmouse (talk) 10:56, 19 July 2011 (UTC)[reply]

Note - Lightmouse (talk · contribs) has, with his bot Lightbot (talk · contribs), introduced massive, un-discussed changes to articles using these templates at least twice in the past. GiantSnowman 11:13, 19 July 2011 (UTC)[reply]
This doesn't seem to be a helpful comment, given LM's attempts to ask for community input here. Tony (talk) 12:41, 19 July 2011 (UTC)[reply]
Perhaps a little, but in fainess, he only asked for community input after two editors wrote on his talk page, questioning his actions. GiantSnowman 12:44, 19 July 2011 (UTC)[reply]
As I understand it, {{height}} is for use in infoboxes, and abbreviations of units and precision default to settings appropriate to such use. This makes it quicker and easier to use than the {{convert}} equivalent. In addition, using a simple template called "height" for a person's height is more intuitive for inexperienced editors, who make a significant proportion of edits to sportspeople's infoboxes. Compare {{height|ft=6|in=2}} with {{convert|6|ft|2|in|m|2|abbr=on}}. Which is why I was disappointed when Lightbot started going round infoboxes changing {{height}} to its {{convert}} equivalent, but assumed this would have been discussed somewhere...
This discussion arose from a thread at Lightmouse's talk page, concerning bot edits adding a precision=0 parameter to usages of {{height}} where the default precision had produced half-inches in the output (displayed as a vulgar fraction). If there actually is agreement that nowadays people's heights are generally measured to the nearest whole inch, then it's fair enough to display at that precision as the result of a conversion from metric. But maybe this should be implemented by changing the output default at the template itself, rather than by complicating matters with the added precision parameter. cheers, Struway2 (talk) 12:57, 19 July 2011 (UTC)[reply]
Forgive me. I do many janitorial edits across the whole of WP. Some pass without comment. Some produce comments merely as a result of curiousity, alternative opinions, lack of awareness, local custom, or whatever. U can't always predict which are regarded as noteworthy by any one of the many editors on the millions of articles. In this case, I brought it here as soon as I saw that the issue is sufficiently important to require community input. I don't think many people are aware that we have two templates with major overlap. A good outcome of this dialog is that people will be able to decide what to do about it.
I agree with the analysis/suggestion of User:Struway2. Thanks. Lightmouse (talk) 13:06, 19 July 2011 (UTC)[reply]

As far as I can tell, the following is true:

Height template Convert template Comment
{{height|ft=5|in=6}}
5 ft 6 in (1.68 m)		 {{convert|5|ft|6|in|2|abbr=on}}
5 ft 6 in (1.68 m)		 Identical.
Height template actually uses the convert template
{{height|m=1.68|precision=0}}
1.68 m (5 ft 6 in)		 {{convert|1.68|m|0|abbr=on}}
1.68 m (5 ft 6 in)		 Identical.

What are the reasons for choosing one template over another? Lightmouse (talk) 17:28, 23 July 2011 (UTC)[reply]

Guidance on symbol for litre

I think we've now resolved contradiction and clarity problems with current guidance on litre. Several people wanted to discuss changes in guidance. The following table summarises what I think people meant:

Permit 'l' without prefix Permit mix of 'L' and 'ml' in article Supporters Comment
No No Jimp, Jc3s5h
No Yes Current guidance
Follow guidance in BIPM SI brochure Woodstone
Martinvl		 SI guidance

If I've misunderstood, please make the appropriate changes. Lightmouse (talk) 15:14, 19 July 2011 (UTC)[reply]

There is a difference between "permitting XXXX" and "conselling against, but not prohibitting XXX". The SI brochure says that either "L" or "l" may be used as a symbol for the litre, but gives no further guidance. I usually use "L" and "ml" but am not dogmatic about it - this is the norm in the UK, I don't know what the norm is in the US. Martinvl (talk) 15:46, 19 July 2011 (UTC)[reply]
Since the brochure is not primarily a style manual, I would not expect it to give general writing advice, such as keeping symbols consistent within an article. Thus I wouldn't interpret silence on this topic as permission to be inconsistent. Jc3s5h (talk) 15:52, 19 July 2011 (UTC)[reply]
Looking at some products in my kitchen, I find 5 uses of "L", 4 uses of "ml", 5 uses of "mL", no uses of "l", and no units spelled out. This is in the USA. Jc3s5h (talk) 16:01, 19 July 2011 (UTC)[reply]

Interesting, thanks. Does the mosnum guidance over and above the SI brochure have any effect? Guidance that has no effect is probably a waste. Lightmouse (talk) 14:26, 20 July 2011 (UTC)[reply]

From a regulatory standpoint, weights and measures authorities only regulate goods in commerce, so Wikipedia has no obligation to pay any attention to any weights-and-measures standard-setting body.
Given that, I observe that both MOS and MOSNUM make suggestions that are widely available in grammar and style guides. So there is nothing to stop us from repeating information that is in the BIPM brochure, if we think editors are unlikely to bother reading the brochure but would read the suggestions if they are reproduced here.
If MOSNUM specifically endorses, through a hyperlink, the guidance in the BIPM brochure, that would disallow the script lower-case l which would otherwise be acceptable. Jc3s5h (talk) 15:33, 20 July 2011 (UTC)[reply]

Yes, I agree. WP mosnum repeats, contradicts, and goes beyond SI as we choose. I was merely suggesting that we look critically at the value of each repetition.

  • You appear to be suggesting that SI forbids the lower case 'l' for litre. But that's not true. See the official SI website and the footnote.
  • The current guidance in mosnum is that some of SI applies and some does not. I don't see any reason for that to change.

Forgive me for not understanding you. I agree with you that we can and should choose to repeat some of SI. We just need to ensure repetition adds value. Lightmouse (talk) 16:44, 20 July 2011 (UTC)[reply]

The liter symbol that is sometimes seen, but not endorsed by the BIPM brochure, is "ℓ". Jc3s5h (talk) 19:58, 20 July 2011 (UTC)[reply]

Ah. I seem to remember seeing "ℓ" mentioned somewhere before. But I don't think I've ever encountered it in Wikipedia. Forgive me for not following you, can we take it step by step. Are you saying mosnum should have guidance on "ℓ"? Lightmouse (talk) 20:58, 20 July 2011 (UTC)[reply]

I think the difficulty in typing "ℓ" is sufficient to protect us from it, but I would have no problem endorsing a guide that either says to avoid it, or implies it should be avoided by not listing it among the acceptable symbols. Jc3s5h (talk) 21:40, 20 July 2011 (UTC)[reply]

Your wish appears to be granted. Mosnum says:

  • Non-SI units in tables 6, 7, 8, and 9 of the SI brochure are written according to the SI standard unless otherwise specified in this Manual of Style (dates and numbers). For example see guidance on litre.

Table 6 of the SI brochure says:

The only remaining issue is whether there's a problem in WIkipedia that needs mosnum to say more than SI. User:Woodstone and User:Martinvl are happy with a one-to-one match between mosnum and SI guidance. If you are too, then so am I. Lightmouse (talk) 09:43, 22 July 2011 (UTC)[reply]

  • My first choice would be to adopt American usage in all cases, and always capitalize the "L". But I don't think I can persuade the community do that. My second choice would be to follow the BIPM brochure. However, retain the guidance that the spelling "liter" is allowed. Jc3s5h (talk) 11:31, 22 July 2011 (UTC)[reply]

I sympathise with your first choice but agree it's unlikely to succeed. Your second choice means keeping the 'Name' and 'Comment' columns the same and changing the 'Symbol' column to:

  • l or L

I'm ok with that. Lightmouse (talk) 15:25, 22 July 2011 (UTC)[reply]

Edit request from Jojotruth1, 20 July 2011

please change AD and BC to a more accurate scientific dating system

Jojotruth1 (talk) 17:36, 20 July 2011 (UTC)[reply]

That's a perennial issue, not something we forgot. Here's its most recent repetition. Art LaPella (talk) 21:33, 20 July 2011 (UTC)[reply]
No, we will not make this change in the foreseeable future. Jc3s5h (talk) 21:37, 20 July 2011 (UTC)[reply]
Which more scientific dating system are you referring to? Your edits at Israel seem to suggest that you aren't talking about BCE and CE?. — Steven Evens (contribs) 02:55, 22 July 2011 (UTC)[reply]

Permanent compromise for BCE/CE vs. BC/AD wars?

How about, instead of just allowing either notation in any given article, we take one of each and make it the standard. Most who complain about BC/AD being offensive cite the "Year of Our Lord" in AD, and most who complain about BCE/CE cite the 3 digits found in "BCE".

How about we make the new standard BC and CE? We will use "BC" all throughout Wikipedia for years before Year One, and we will use "CE" all throughout Wikipedia for years from 1 onward. For example, the contentious Jesus article would read, under this new Wikipedia system:

"Jesus of Nazareth, Yeshua in Hebrew or Aramaic (7-2 BC — 30-36 CE)"

Well, why not? I know that BC and CE are rarely paired in external sources, but why can't Wikipedia make a compromise to be as neutral as possible without also being as frustrating as possible by allowing both and having edit wars and reversions constantly? What's bad about this idea? Thoughts?. — Steven Evens (contribs) 02:52, 22 July 2011 (UTC)[reply]

It cannot be denied that the proposal has a certain elegance. Although it makes an unusual pair, it has a nicely balanced feel. I would support it. −Woodstone (talk) 05:37, 22 July 2011 (UTC)[reply]
There is already a fairly commonly used system that does not have any problem with bulky abbreviations or explicit religious references: astronomical year numbering. Jc3s5h (talk) 11:38, 22 July 2011 (UTC)[reply]
But with astronomical year numbering, Julius Caesar dies in –44 instead of 45 BC, which would change every established BC year we know, and the minus sign (–) would wreak havoc on date ranges. Imagine, if you will: ""Jesus of Nazareth, Yeshua in Hebrew or Aramaic (–6 - –1 — 30-36)". — Steven Evens (contribs) 21:02, 22 July 2011 (UTC)[reply]
What Steven Evens views as a disadvantage, I view as an advantage. It would be too complicated for someone to even think about using a bot to make the "correction". Bots never get it right, they always mess up on things like quotes and titles. Jc3s5h (talk) 21:38, 22 July 2011 (UTC)[reply]
Also, I think it's quite unfamiliar to most readers, so even if we get it right they might not realize the negative years are off by one wrt the more commonly used systems. ― A. di M.​plé​dréachtaí 20:02, 23 July 2011 (UTC)[reply]
Right, and it's not really commonly used at all. It's commonly used in some technical/academic fields, this is a general purpose, albeit highly detailed, encyclopedia. It's certainly no where near as common as BCE/CE. The BC/CE solution is interesting and possible because the BC/AD and BCE/CE systems are just different naming conventions for the same system. I'm not sure that this is the best solution but it deserves consideration. I'm not really sure why BCE is so disliked just for an extra letter, everyone knows the C in BC is "Christ" which makes the system remain problematic, though I suppose we could break new ground and suggest that it now is simply a shorter form of BCE.--Doug.(talk • contribs) 13:01, 24 July 2011 (UTC)[reply]
It seems a little strange but I see no reason why Wikipedia cannot invent its own system. Change has to start somewhere. Someone invented the BCE/CE system. Although I still don't understand why we use BC/AD seeing as how Christian articles use BCE/CE. All that being said, I have no problem with the extra letter in BCE. McLerristarr | Mclay1 13:06, 24 July 2011 (UTC)[reply]
The biggest obstacle to inventing our own system would be getting anyone to notice. The Manual of Style puts most editors to sleep long before they find out about its subpages. Art LaPella (talk) 15:39, 24 July 2011 (UTC)[reply]
We can't create our "own system", it's not notable or from reliable sources. It would be like creating an in-wiki alternative to the metric system instead of using either metric or imperial. The difference here is, we can mix a usage of BCE/CE and BC/AD without causing any problems. As for the "Christ" in BC making it problematic, I don't see why. It's educational. "Christ", despite its apparent religiosity, is widely used as a secular means of referring to Jesus of Nazareth anyway, as confirmed by its Wiki article. How many times have you heard non-Christians call Jesus simply "Christ" without implying he is a messiah? Look, it's simply a fact that the Dionysian era system is based on the (erroneously calculated) birth of Jesus, so as an encyclopedia dedicated to information, I don't understand the obsession with completely covering that up. Sure, "in the year of our Lord" is a bit icky, even for me as an atheist, but it's all the same mythology as Thor's Day, Woden's Day, etc. Plus, they're just initialisms, it's not like they're spelled out or anything.
I think the BC & CE combo proposal conveniently rids of the overtly religious "AD" proclamation (as well as the pesky way that it can be placed either before or after a year) as well as not going too PC in the other direction by keeping the reference to Jesus (Christ) for years before the Dionysian era, and keeping both initialisms at 2 letters. I don't see why this compromise shouldn't satisfy most people. Even for those who prefer BCE/CE, this proposal would promote the Common Era system even more on Wikipedia as it would be used in every article that spans the years 1—999 — Steven Evens (contribs) 16:16, 24 July 2011 (UTC)[reply]
  • So… eschewing the RSs isn’t enough, we would completely eschew both conventions used on this pale blue dot and instead invent our own hybrid house style that nobody else is using?? (♬♩“A little bit country! …And a little bit Rock and Roll!”♩♬). It’s been proven over and over again that Wikipedia does not have the power to Lead By Example To Change The World For A New And Brighter Future®™© and always manages to do nothing more than just looks foolish whenever it attempts to do so (witness the three-year-long “kilobyte” / “kibibyte” fiasco).

    It is common for many publications to use BCE/CE when trying to be politically correct and trip all over oneself to be as inoffensive as possible. However, I’ve yet to hear narrators on TV and film documentaries (like on Egyptian pyramids) use this new terminology; instead, they stick to the “BC” and “AD” forms. I assume this is because the customary terms are less distracting in audible form because saying “This pyramid was thought to have been built in 2500 bee see eee” would leave the viewer in “WTF-land” for 15 seconds.

    At risk of ticking off some of the 16-year-old wikipedians who might be looking in on this and who are all smitten with how wise and knowledgeable they have become in only two short years and who are trying to change the world; and in order to make peace on this issue using actual policy that underlies important principals of Wikipedia, I am all for just following the RSs for each particular article. For those articles where there is no guidance by the RSs, or the usage is mixed or unclear by the RSs, my personal preference is to use the BC/AD since I believe it least draws attention to itself for those who hear the words in their heads as they read. This philosophy comes from Technical Writing 101, which states that Thou shalt not use a writing style that draws undo attention to itself for the target readership.

    But, since the above might make too much sense and deprive people of their God-given entitlement to wikidrama, I suspect the best thing to do here on this issue is the standard solution for deadlocks: “Do whatever ya’ want.” Greg L (talk) 16:29, 27 July 2011 (UTC)[reply]

Fwiw, I first heard the usage BCE/CE (actually it was not the initialisms but the full words) nearly 30 years ago on a documentary on the US Public Broadcasting System. I believe the documentary was about the Holy Land, though I don't recall exactly. :) --Doug.(talk • contribs) 17:07, 27 July 2011 (UTC)[reply]
It's still quite a minority usage (though their frequencies are the same order of magnitude now, so that I think the current “pick-one-and-leave-it-alone” way is appropriate): http://ngrams.googlelabs.com/graph?content=753+BC%2C753+BCE&year_start=1970&year_end=2008&corpus=0&smoothing=3. ― A. di M.​plé​dréachtaí 17:50, 27 July 2011 (UTC)[reply]
Meh, whatever, I wasn't actually expecting this to go anywhere, just sparking discussion on it. In my perfect world, "BCE" could be meant to represent "Before Christian Epoch", and "CE" could be switched to "ACE" and mean "After Christian Epoch"; getting rid of the nonsense terms "Common" and "Era" and stripping it down to exactly what it really is, and also giving both notations 3 letters. Saying we're in the year 2011 CE ("Common Era") sounds stupid, but 2011 ACE ("After Christian Epoch") makes perfect sense, because that's exactly what it is. Two thousand and eleven years since the Christian epoch, without needing to get all religious about it. The main objection I have with "Common Era" is how vague and nonsensical it is. But "Christian Era" doesn't work either, because it sounds as if everything that the era itself since 1 AD is somehow Christian in nature. The term "epoch" only refers to the reference date, not the years following or preceding. I hate euphemisms and eschewing history, and so CE/BCE rub me the wrong way. — Steven Evens (contribs) 03:03, 28 July 2011 (UTC)[reply]
I’m not making fun of you, Steven, but I can’t resist: Since we are inventing house styles unique on this planet, why not “BYMRTCBCSETLEAFS”, which would stand for “Before Years Measured Relative To Christ But CALLED Something Else To Look Enlightened And Feel Smug”. Then “AYMRTCBCSETLEAFS” could mean the “after” version of all that. We’ll stand on a hilltop, join hands, and Change The World©™® with Coca-Cola. Or we could just follow the RSs where possible. Greg L (talk) 03:20, 28 July 2011 (UTC)[reply]
Don't worry, I understand what you're saying. I wasn't saying that I'd prefer this "perfect world" BCE/ACE over the traditional AD/BC, because that's not the case at all. If it were up to me, we'd use AD/BC exclusively. But we're not. It's the constant edit warring, reverting, time wasting and accusations of "Christian bias" that I can't stand with the current "use both systems wherever" compromise. People are constantly changing BC/AD to BCE/CE arbitrarily all 'round the encyclopedia for spurious politically correct reasons, and if you don't revert them "in time", it is considered that the silence has established consensus for BCE/CE. All sorts of ugly political and religious debates and shouting matches have resulted from fighting over this terminology. With my BC/CE compromise I was just offering an idea that might help quell that a bit. I knew it was unlikely to succeed, but it's worth throwing out there. — CIS (talk | stalk) 03:28, 28 July 2011 (UTC)[reply]

We have guidance that says:

Some units are neither common nor uncommon. They're in a middle commonality zone (e.g. nautical mile) where a link isn't required if a conversion is present. Can anyone suggest appropriate wording? Lightmouse (talk) 11:56, 27 July 2011 (UTC)[reply]

Given what MOSLINK says in its footnote 2, and common logic, it seems that the existence of a conversion significantly lessens the utility of a wikilink. Tony (talk) 12:50, 27 July 2011 (UTC)[reply]
Sometimes a unit has more utility for a certain field than one would guess just from the conversion factor. For example, a nautical mile is also close enough, for most navigation purposes, to a minute of latitude, so the left or right margins of a nautical chart can be used to set dividers to the desired distance. Depending on the primary audience of a particular article, a link may be appropriate. Jc3s5h (talk) 12:58, 27 July 2011 (UTC)[reply]
Well, that applies pretty much to all units of measurement. If I'm writing that some guy weighs 89 kilograms (196 lb) I don't link kilogram, but if I'm writing that the kilogram is the only SI unit still defined by an artefact I do link it. ― A. di M.​plé​dréachtaí 17:53, 27 July 2011 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=441811260"