Wikipedia talk:Manual of Style/Dates and numbers/Archive 146

Archive 140

←

Archive 144

Archive 145

Archive 146

Archive 147

Archive 148

→

Archive 150

Binary prefixes February 2014

About 10 days ago, Dondervogel 2 changed, without discussion,

... currently favours the retention of the more familiar but ambiguous units "KB", "MB", "GB", "TB", "PB", "EB", etc. over use of IEC binary prefixes. Use 256 MB of RAM, not 256 MiB of RAM.

to

... consensus on Wikipedia in computing-related contexts currently favours the retention of the more familiar but ambiguous units "KB", "MB", "GB", "TB", "PB", "EB", etc. over use of unambiguous (but less familiar) IEC binary prefixes. Use 256 MB of RAM, not 256 MiB of RAM.

I corrected it to

... consensus on Wikipedia in computing-related contexts currently favours the retention of the more familiar but ambiguous units "KB", "MB", "GB", "TB", "PB", "EB", etc. over use of unambiguous (but less familiar and virtually unused in reliable sources) IEC binary prefixes. Use 256 MB of RAM, not 256 MiB of RAM.

After being reverted, I restored the first version, per WP:BRD. Some might think the change is required by grammar, but I feel the second version implies that the consensus is because it is less familiar, rather than because it is rarely used in the real world, which was the real version of the consensus. — Arthur Rubin (talk) 11:28, 28 February 2014 (UTC)

After a little thought, just leaving the word "unambiguous" in place, with no further commentary, might be better. However, that may also change the meaning, so I don't want to do it without consensus. — Arthur Rubin (talk) 11:33, 28 February 2014 (UTC)

If the change I made then (which followed a discussion on the talk page about how to clarify the text, but this is incidental to my point) was considered controversial, I find it very strange that no one challenged it at the time, or even mentioned it on the talk page. By contrast, Arthur Rubin's assertion that IEC prefixes are "virtually unused in reliable sources" is highly controversial, which is why I reverted it, and presumably why he tones down the claim now to "rarely used in the real world". No one disputes that use of these prefixes is rare. I strongly dispute the notion that reliable sources do not use them. On the contrary, IEC prefixes are increasingly used in scientific publications, and are the nearly universal choice of disambiguation for those who choose to disambiguate. Dondervogel 2 (talk) 13:34, 28 February 2014 (UTC)

I couldn't find a discussion, going back two archives. Still, the clarification with just "unambiguous", rather than any parenthetical remarks, seems to cover the issue better. I disagree with your assertions later in the above paragraph; I have never seen the "binary" prefixes in a scientific publication. — Arthur Rubin (talk) 19:41, 28 February 2014 (UTC)

I agree the text "but less familiar" in brackets adds little and could be removed without changing the meaning. You can find hundreds of scientific publications that use IEC prefixes here of you are interested. The strange filter is to remove lots of spurious hits you would otherwise get that happen to use the abbreviations mib (e.g., men in black) or gib (Gibraltar). Dondervogel 2 (talk) 19:55, 28 February 2014 (UTC)

I see that, in December 2010, it was determined by consensus that you were, and had said, you would stop at nothing to get the IEC prefixes into Wikipedia. Your recent actions show no change in policy, except that you are toning down your actions to avoid immediate reverts and possible topic bans. Perhaps it is time to revive the topic ban proposal from 2010. — Arthur Rubin (talk) 19:59, 28 February 2014 (UTC)

The IEC binary prefixes were proposed almost 20 years ago and have failed to be adopted by the computer industry. Dondervogel 2 has been pushing for Wikipedia to adopt these "new and improved" IEC binary prefixes since 2008. Wikipedia uses the terminology that is commonly used in the real world. -- SWTPC6800 (talk) 03:01, 1 March 2014 (UTC)

Do either of you have any interest in the substance of the discussion? This is what happened: Arthur Rubin introduced a statement that Dondervogel 2 disagreed with and reverted; Arthur Rubin then proposed a change that Dondervogel 2 agreed to and Arthur Rubin implemented. Those are the facts, and that is how things are supposed to work. Wikipedia can manage quite well without the hot air. Dondervogel 2 (talk) 08:00, 1 March 2014 (UTC)

This strikes me as rather unfair. The IEC prefixes are certainly used in the real world (for example, my Linux desktop gives information in IEC units only). Their unambiguity is a strong argument in their favour: it's not unreasonable for Wikipedia to prefer rational formats, whether "reliable sources" use them or not (bear in mind that Wikipedia does not defer to sources for unit choice). Certainly, computer-literate people (the demographic to which computer-related articles are most relevant) should be familiar with the IEC prefixes. Archon 2488 (talk) 18:58, 1 March 2014 (UTC)

Certainly seems that in situations where the precise quantity of data is considered to be significant, it would be better to use unambiguous units. If it's just a ballpark figure, then the more familiar units will do. W. P. Uzer (talk) 21:14, 1 March 2014 (UTC)

The computer industry has not adopted the IEC prefixes. I just looked at Mainframes on the IBM site. This is from the zEnterprise EC12 (zEC12) Data sheet.

"All five models of the zEC12 are machine type 2827. The server supports up to a total of 3 terabytes (TB) of real memory. Beyond the customer-purchased memory, the zEC12 has doubled the amount of memory—32 gigabytes (GB) for the Hardware System Area (HSA) which holds the I/O configuration data for the server."

It doesn't matter if some professor from Sweden uses gibibyte, the computer industry doesn't. The vast majority of readers have never seen this notation. Wikipedia is not a crystal ball; it used the terminology found in the real world today. -- SWTPC6800 (talk) 01:58, 2 March 2014 (UTC)

This often repeated argument that these units must be banned from WP because nobody has seen them, has got to be ranking with the most ridiculous ideas anywhere. It's pure stupidity. It is analogous to banning the mentioning of the MC6800 everywhere because no one knows what that is. WP reflects knowledge and teaches, and has the purpose of introducing new terms to readers. That's why readers come here, and not to be taught obsolete concepts. These units are a fact, are international standards, are increasingly being used, and WP doesn't allow them. Absurd. It's time this bullshit ends, and that people like this are shown their way out, including the sock puppets of these people that have prevented progress, and dominated these decisions. Kbrose (talk) 06:51, 25 March 2014 (UTC)

Not universally adopted, perhaps, but nonetheless it is used — perhaps more by software engineers than by the electrical engineers who design the hardware. Marketing would generally prefer the decimal prefixes because they make storage devices sound bigger. My operating system tells me that my 4 TB external HDD has a capacity of "3.6 TiB", for example.

Suggested compromise: use the decimal notation in contexts where precision is not so important, but allow the binary prefixes in more technical computing-related articles where they might be useful for disambiguation. It might be useful to recommend linking to the article on IEC prefixes with the first use of a binary unit (this is general practice for generally-unfamiliar units used in certain specialist contexts such as megaparsecs, femtobarns, GeV or AU). Another option is to expand the convert template to allow conversion between decimal and binary notation, and simply show both. Perhaps this would ultimately be most useful. Archon 2488 (talk) 02:30, 2 March 2014 (UTC)

And my OS tells me my capacity in GB which shows that some OS versions use what we tend to use. So, in the end, which if any can be said to be right? Vegaswikian (talk) 03:43, 2 March 2014 (UTC)

The Software industry doesn't use the IEC binary prefixes either. The Adobe Photoshop Lightroom Tech Spec for Mac and PC states:

2GB of RAM (4GB recommended)

2GB of available hard-disk space

The IEC binary prefixes were proposed before Windows 95 was released; it is a dead letter technical specification. -- SWTPC6800 (talk) 05:23, 2 March 2014 (UTC)

Evidence cited above seems to contradict you - exhibiting one case in which something is not used does not constitute an argument that it is not used at all. W. P. Uzer (talk) 10:18, 2 March 2014 (UTC)

Not being universally used isn't equivalent to not being used. In this case (with RAM) I think what's happening is that the binary units are being used, but with decimal prefixes (this is exactly the kind of ambiguity we are talking about). So 2 GB of RAM means 2*(1024^3) B of RAM, not 2*(10^9) B. All we are suggesting is that it is generally helpful to show the binary and decimal quantities as different things, because they are. Like I say, the convert template already exists, and could be adapted to this purpose (bearing in mind that the conversion is somewhat non-trivial). Archon 2488 (talk) 13:05, 2 March 2014 (UTC)

Differences in the bytes can be can be shown without using IEC prefixes. Use the number written out long-hand or use power notation for example and are perfectly acceptable. Using IEC prefixes pushes a point of view that is contrary to commonly accepted and used terminology in the field. Fnagaton 13:35, 6 March 2014 (UTC)

It's a bit excessive to call IEC prefixes a POV push; they are just a different form of mathematical notation, which can be useful for disambiguation. But I agree that there are alternative ways of disambiguating. Archon 2488 (talk) 15:10, 11 March 2014 (UTC)

What I mean is that anybody who says "Wikipedia should use IEC prefixes for disambiguation" is pushing a non-neutral POV. This is because Wikipedia reflects the real world how it really is. In the real world IEC prefixes are not commonly used. What is commonly used are prefixes like KB used in the multiple of 1024 binary sense for RAM and multiple of 1000 sense for disk space. Since other real world use prevails then IEC prefixes shouldn't be used in Wikipedia articles. Prevailing real world use in this case being articles that use the number of bytes or power notation to clarify the precise number of bytes.Fnagaton 13:21, 14 March 2014 (UTC)

I think that the distinction between "less familiar" and "[far] less commonly used" is not relevant to MoS. The substantive question of how to accurately describe large binary amounts is one that does become more pressing as commonly used prefixes become larger and the differences between the binary and the base ten interpretations become larger, not just in absolute size but also as ratios. Remembering that MoS is merely a guideline, using the IEC prefixes is not completely ruled out in special circumstances, nor indeed is scientific notation. All the best, Rich Farmbrough, 18:46, 27 March 2014 (UTC).

This isn't just about MOS it's about other Wikipedia policies and it's those policies that prevent IEC prefixes from being used because those policies dictate very strongly how Wikipedia articles are written. Using IEC prefixes is ruled out for general purpose disambiguation because Wikipedia reports how the real world does things and doesn't try to rewrite history itself. The real world mostly does not use IEC prefixes, therefore Wikipedia doesn't either. The way to accurately describe large binary amounts (or other amounts) is to either write the precise number or use power notation which is what the real world does. Fnagaton 00:27, 29 March 2014 (UTC)

The policies in this case are WP:NPOV AND WP:NOR. NPOV Applies because it is biased to prefer to use IEC prefixes when the those prefixes are not widely used in the real world. To comply with NPOC disambiguation has to follow the style used in the majority of the real world and that means using numbers or power notation. NOR Applies because the IEC is a primary source but Wikipedia doesn't directly follow primary sources, what Wikipedia actually does is to follow the secondary sources because this gives a better indication of notability of something. In this case it would violate NOR because it's using a personal point of view that a method should be used which is contrary to what the secondary sources mostly use. Fnagaton 00:46, 29 March 2014 (UTC)

I don't believe these policies are supposed to apply directly to matters of style. Many of Wikipedia's style recommendations and practices are possibly out of line with what a majority of "secondary sources" (of various types) might use. Of course it's no bad thing to choose a style that readers are more likely to be familiar with from elsewhere; but that might be outweighed by other considerations, such as the need to convey information accurately and unambiguously. Whatever we decide to do in such matters will be a "personal point of view", but that doesn't matter; the only way in which we might be "violating NOR" would be if we were to invent a convention that no reliable sources use. W. P. Uzer (talk) 08:53, 29 March 2014 (UTC)

It's not a personal point of view to point out that people in general don't find the IEC prefixes familiar. Nor is it a personal point of view to point out the familiar use is KB/MB/GB etc used with RAM and drive sizes. This is just the way the secondary sources choose to use the prefixes. It's a violation of NOR to use IEC for disambiguation because it's a "synthesis of published material that serves to advance a position not clearly advanced by the sources themselves". It's also related to WP:UNDUE because to use IEC prefixes for disambiguation advances the idea that it's a method widely used by secondary sources when it's actually not. Fnagaton 13:42, 29 March 2014 (UTC)

I think you overstate yourself; it's perfectly reasonable to argue that these prefixes are not well enough known to justify their regular use in Wikipedia, but to claim that it goes against Wikipedia's fundamental policies to do otherwise is going a bit far. Using such prefixes isn't "advancing" any "idea" in the sense that the people who wrote those policies intended those words to mean. It's not as if no reliable sources use the prefixes. W. P. Uzer (talk) 16:41, 29 March 2014 (UTC)

I don't think I am overstating, I'm actually citing the consensus reached from the binary prefix archives. The "advancing an idea" from the policies isn't from no reliable sources to trying to put something in articles, the "advancing" in the policies actually talks about giving due weight to ideas. In this context this means that even though there are some sources uses the IEC prefixes the actual real world use is mostly not using them. Of course there were some in the archives that just could not drop the idea of forcing IEC prefixes to be used everywhere in Wikipedia, in other words they were set on "advancing an idea" that IEC should be commonly used, hence they would deny that there was even a consensus. However thankfully the guidelines and policies are clear that those who stand in the way of good consensus by flogging a dead horse will eventually face sanctions. That's basically a short history of the binary prefixes archive available on this page. I was there from the very beginning of the archive. Fnagaton 08:14, 30 March 2014 (UTC)

The Wikipedia IEC binary prefix debacle began in July 2005 when a group of editors decided that Wikipedia would advocate the use of KiB and MiB to specify memory size. It was immaterial that the computer industry had ignored this decade old standard. Wikipedia could educate the world on the correct way to measure computer memory. [1]

Soon after, zealots began widespread changing articles to use the KiB, MiB and so on. When other editors tried to undo the changes they were told to see the Manual of Style. [2]

At MOSNUM they were told that the IEC Binary Prefixes were consensus and required.

"For the last time. If you have an issue with this policy, take it up in the appropriate place: Wikipedia talk:Manual of Style (dates and numbers). Neither the administrator notice board nor revert summaries nor user talk pages are correct places to get this policy changed. I suggest you first read up on the five or so previous times this has come up, been discussed thorougly, and still maintained significant consensus to keep. Believe it or not, there are a lot of valid reasons for using IEC prefixes. Irregardless, please do not revert articles to your liking until such a time as the current MOS guideline changes. You can drop the persecution complex. Nobody has bullied you, it's you who is demanding that your opinion is more valid than that of the users who established and have maintained this particular policy. There are other users who disagree with the policy, if you have anything to add to the lengthy discussion, by all means do so in the appropriate place." [3]

This "IEC binary prefix" dispute lasted about 3 years and was an extreme case of advocacy for a minority view point.-- SWTPC6800 (talk)

According to the vote on the old talk page that you link to, it was actually very much a majority viewpoint (though that vote might have been rigged in some way, I suppose). In any case, past actions by a particular group of people should not be relevant to our discussion now about whether and when use of these prefixes may be appropriate. W. P. Uzer (talk) 21:48, 30 March 2014 (UTC)

The talk page on MOSNUM is not read by a majority of Wikipedia Editors. When a change that passed 20 to 6 on a talk page generates hundreds of complaints, it does not represent the majority position. The binary prefixes are still not used by the computer industry. The majority of the real world is still opposed to them. -- SWTPC6800 (talk) 22:47, 30 March 2014 (UTC)

So was there a later vote that reversed the result of that previous one? W. P. Uzer (talk) 07:20, 31 March 2014 (UTC)

A vote isn't good consensus because some people can turn up and vote for bad ideas. The original vote was basically "I like IEC prefixes so let's use them" WP:ILIKEIT. The point about a good consensus is that the reasons have to be logically sound, something missed by the original vote. Since the IEC prefixes are not used by the majority of secondary sources (for disambiguation) then simply Wikipedia shouldn't either. A later good consensus (archived in the later binary prefix archive) was reached that basically discussed MOSNUM in the context of the Wikipedia policies I mentioned earlier on. Once those policies are considered the case for not using IEC prefixes is clear. Fnagaton 13:47, 31 March 2014 (UTC)

Numbers as words expressible in two words

• Integers greater than nine expressible in one or two words may be expressed either in numerals or in words (16 or sixteen, 84 or eighty-four, 200 or two hundred). In spelling out numbers, "components" from 21 to 99 are hyphenated; larger ones are not:

  •  fifty-six

  •  five hundred

  •  four hundred seven or four hundred and seven

  •  two thousand four hundred sixty-six or two thousand four hundred and sixty-six

Shouldn't the last two examples be in red since they are expressed in more than two words? If not, perhaps this language can be clarified? czar ♔ 00:10, 30 March 2014 (UTC)

I think the longer examples were added by me, unthinkingly, when I was rewriting the section a few months ago. Seems I forgot I was illustrating the rule that only small numbers should be written in words (in articles) and slid into giving examples of how to write out any integer (as if explaining how to write out a money amount on a bank check). Oops.

Using "and" is completely wrong (in writing, though in informal speech it's certainly heard) -- someone else must have added those alternatives later. [I spoke hastily, and apparently from ignorance...] Someone else added the alternative versions using and and apparently this is accepted usage in some circumstances. Luckily (thank God) we don't need to deal with this since it comes up only for numbers that can't be written in "one or two words", and three-words-or-more numbers shouldn't be written in words anyway. Do I have that right?

EEng (talk) 22:43, 31 March 2014 (UTC)

It looks like two separate, independant lists of examples in different formats, which is confusing. The first list only applies to certain integers, without saying anything about integers requiring three or more words, or single digits. Is spelling out "five" wrong or preferred, for instance? It should probably be split into two lists, to better cover the possibilities. Then, better examples for the second list could be formed, if needed. —PC-XT+ 00:35, 30 March 2014 (UTC) 00:58, 30 March 2014 (UTC)

Nevermind. The first list is clear enough. I missed the first item. The examples in question seem to be too long, and should rather be in the next item in the list. —PC-XT+ 00:58, 30 March 2014 (UTC)

Using "and" in "four hundred and seven" is incorrect. When you speak 400.7 you would say "four hundred and seven-tenths", but that's too much to write out in Wikipedia. GoingBatty (talk) 12:44, 30 March 2014 (UTC)

The way I'm reading this section, "four hundred seven" is three words, not expressible in "one or two words" and should be written in numerals. I wanted to verify and, if correct, ask whether the last two bullets should be made red instead of green to show "no good". czar ♔ 12:59, 30 March 2014 (UTC)

As I understand it (and this was clearer in older versions of the guideline, though still confusing overall) the listed examples are intended to illustrate the point about hyphenation, not the point about choosing figures or words. Suggest the final two examples simply be deleted. ("Four hundred and seven" is not incorrect; it's normal in British English. But there's no need for either form to be listed here in fact - the rule as stated will be perfectly sufficient for people to know how to hyphenate on the rare occasions when they need to deviate from the advice to write such numbers in figures.) W. P. Uzer (talk) 18:17, 30 March 2014 (UTC)

I agree. Just delete them. —PC-XT+ 22:58, 30 March 2014 (UTC)

When I, as an Australian, hear 'four hundred and seven' I naturally think of 407.
400.7 would be 'four hundred point seven', or '400+7⁄10' or 'four hundred and seven tenths'.  Stepho  talk  23:08, 30 March 2014 (UTC)

✓ Removed  czar ♔ 16:51, 31 March 2014 (UTC)

Another contradiction

Another apparent inconsistency (which I flagged a while ago, but no-one has attempted to address) is in the fractions section, where it says that nouns following fractions between -1 and +1 should be singular, but gives as an example "3/2 dose". Should this be plural, or should the rule be rewritten? W. P. Uzer (talk) 18:49, 30 March 2014 (UTC)

Is it supposed to say 2/3 dose? The intention appears to be to contrast 1 1/2 doses in magnitude, which 3/2 simply can not do. —PC-XT+ 22:58, 30 March 2014 (UTC)

Or possibly the rule is supposed to be that any simple fraction (i.e. not a mixed number with a whole integer part before the fraction) takes a singular. I don't know; I would never write anything like that in prose anyway, it might come up in tables in medical articles (or other types of articles if the noun was something other than "dose"). W. P. Uzer (talk) 07:15, 31 March 2014 (UTC)

Common in (cooking) recipes. Fix the example to be "2/3 dose". —[AlanM1(talk)]— 07:47, 31 March 2014 (UTC)

I'd say that the simple-fraction-verses-mixed-number distinction it better (i.e. more in conformance with normal rules of English) than the one based on numbers between -1 and +1. Jimp 09:15, 31 March 2014 (UTC)

Wither style guide

I wonder which style guide these guys use... They write: "Meanwhile, aviators said MH 370 was safely cruising at about 40,000ft (about 12,121.2m) on the airways and had passed the Igari checkpoint" -- Ohc ^¡digame! 04:56, 22 March 2014 (UTC)

Even the presence of the "about" doesn't seem to have alerted them... On that subject though, our article about the plane, in line with news reports such as the above, gives flying altitudes in feet first, while according to this style guide it should be metric first. Assuming this is an exception that we would accept, and considering we already list obscure exceptions like milk bottles and horses' heights, how come this one isn't listed? W. P. Uzer (talk) 08:00, 22 March 2014 (UTC)

It's not listed there because it's not a UK-only exception, but applies pretty much everywhere.

It's not listed elsewhere because, as a result of wrangling similar to that found above, the old rule to use the units in most common use internationally in a given context - which far more accurately reflected the aim of the guideline - was replaced with a general instruction to use SI. Kahastok talk 08:39, 22 March 2014 (UTC)

Seems a bit irrational to list exceptions with very limited scope (UK-only), but not those with worldwide scope (and applicable to fields like aviation that we write about much more frequently than milk bottling and horse measurement). What you describe as the "old rule" sounds to me a more sensible solution, and probably closer to what editors do naturally. W. P. Uzer (talk) 09:32, 22 March 2014 (UTC)

The about 40,000 is probably right as aircraft heights are actually measured in Flight Levels, so FL400 is about 40,000 feet but it depends on the air pressure at the time as Flight Levels use a standard pressure rather than actual pressure, fwiw. MilborneOne (talk) 23:06, 27 March 2014 (UTC)

What exactly is the question? To me, the sentence has many problems:

1. Space-separate a value from its "symbol" (e.g. 40,000 ft)
2. Aviation globally uses feet for altitude, right? No need for meters.
3. If conversion to meters were necessary, while you can't generally discern the original precision of a number with four trailing zeros, in this instance, as mentioned, flight levels are usually given in hundreds of feet, so in the absence of evidence to the contrary, 3 sigfigs makes sense: {{Convert|40000|ft|m|sigfig=3|abbr=on}} → 40,000 ft (12,200 m).
4. Navigational aids, waypoints, etc. should be in all-caps (e.g. IGARI, BITOD, ESPOB) by convention.

—[AlanM1(talk)]— 10:18, 31 March 2014 (UTC)

Not quite true. Some countries (mainly former Soviet countries and China) use metres for altitude in aviation. Strictly speaking, feet are meant to be deprecated and replaced by metres at some unspecified point in the future. Anyway, the conversion to SI units is supposed to be provided in accordance with the MOS. You might as well say that because US hydrologists talk in acres and square miles, acre-feet and cu ft/s, there's no need for articles on lakes and rivers in the USA to provide SI conversions, even tho this would make these articles barely intelligible to anyone outside America. Archon 2488 (talk) 11:46, 1 April 2014 (UTC)

I think people here have missed the point. FWIW I took the original message as a humorous response to our units debates.

The source for the quote was the New Straits Times, which clearly is under no obligation to follow MOSNUM. It appears that if they have any style guide, it's not been followed or it's not worth the paper it's written on. They convert 40000 feet to metres and quote the answer to six significant figures. The original measurement is only quoted to at most two significant figures, so six significant figures is far too precise.

But even if the 40000 feet was precise, the six significant figures is still far too much. Because they've gone and assumed 3.3 feet to the metre, rather than the exact figure. As a result their quoted conversion is actually 70.8 metres (232 ft) short of 40000 feet. An approximate conversion is fine if you use an appropriate rounding - if they'd said 12000 metres, 71 metres either way wouldn't have made a difference. But if you're giving a precise result you need a precise conversion. Kahastok talk 21:07, 1 April 2014 (UTC)

Excess examples

User:This is not my last name has been adding many extra examples, as seen in this edit. I believe this is undoing the work of many editors in making this guide concise. There is considerable concern that most editors ignore this guide because it is too long; making it longer will drive off more editors.

I want to know if other editors think these examples are excessive. Jc3s5h (talk) 16:56, 2 April 2014 (UTC)

Since this is Talk:MOS you will excuse a correction: surely you mean excessive examples? Anyway, I agree with you. In any writing, every word added necessarily dilutes the power of all the others, by requiring the reader to spread his attention that much more thinly, and as you point out it's even more important to keep this in mind in crafting MOS. These examples add very little by way of helping the reader understand these specific points, and take away too much by bloating the guideline overall. EEng (talk) 18:48, 2 April 2014 (UTC)

Rfc: Is YYYY-MM an acceptable date format? Part 4

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There is no consensus that YYYY-MM is an acceptable format, nor any consensus that it is an unacceptable format. I would recommend against any mass changes being made purely on the basis of this RfC. HJ Mitchell | Penny for your thoughts? 23:44, 29 March 2014 (UTC) Clarified per request at 22:01, 2 April 2014 (UTC)

---

Continuing on from Part 2 and Part 3 above, I will restate it so that contributors brought in for the RFC can see the problem.

The recent (29 Nov 2013) banning of the yyyy-mm format brings about a conflict between parts of MOS but also highlights that the conflict was waiting in the wings as an unknown consequence. The guidelines state:

1. WP:DATEFORMAT - various formats with spelt out months are allowed (no problem). yyyy-mm-dd (all numbers) is allowed in tables, references and similar places where conciseness is needed. No mention of year and month combos (ie no day of month) at all. It points to Wikipedia:Citing Sources § Citation style, which explicitly allows yyyy-mm-dd.
2. WP:BADDATEFORMAT - lists various bad formats and the recommended replacement. yyyy-mm was unobtrusively added to the list on 29 Nov 2013 as a single line in a table with no reasoning or rationale given.
3. MOS:DATEUNIFY - states that only a single format is to be used within an article (some reading between the lines allows the main text to use spelt out months and tables/references/etc to use yyyy-mm-dd.

Articles are free to use references in the yyyy-mm-dd format. This is explicitly allowed. The conflict comes when we get a reference that has only year and month (typical of magazine references). Since BADDATEFORMAT disallows yyyy-mm, we must replace it with a spelt out format such as Dec 2013. But then this causes a conflict with DATEUNIFY, which forces us to replace each and every reference with a spelt out format. In effect, that single line disallowing yyyy-mm means that every article using yyyy-mm-dd in references has a very good probability of being forced to change to a spelt out format. That's a wide ranging effect for a single sentence fragment with no rationale given in the guideline. The rationale given on the talk page is that it can be confused with the date ranges like 2002-03 (ie from 2002 to 2003).

The talk page discussion was only among a small set of contributors over a short period of time, so the repercussions were not obvious and were not thrashed out. After two months of looking for acceptable solutions, none of the solutions presented in Part 2 found consensus and only the following were found to have any followers:

1. Ban yyyy-mm-dd altogether. Some editors were very much in favour of this and some were very much against it. Unlikely to gain consensus.
2. Ban yyyy-mm but allow yyyy-mm-dd. Needs an explanation that all yyyy-mm-dd references are allowed but will need to be changed to spelt out dates (eg 7 January 2012 or January 7, 2012) as soon as the first year+month combo is added.
3. Allow yyyy-mm and hope that readers can use context to understand that it is year and month, not a year range.

Since the December 2013 addition of the banning of yyyy-mm triggered the conflict, I will hide that in the guideline until a result is found.  Stepho  talk  23:06, 3 February 2014 (UTC)

Survey

Note: 'Support' and 'Oppose' don't work for a 3 way choice; please specify 'Ban yyyy-mm-dd', 'Ban yyyy-mm' or 'Context'

• Context Most readers that care enough about the date can figure it out without too much stress.  Stepho  talk  23:06, 3 February 2014 (UTC)
• Ban yyyy-mm. A reader may not bring the entire article to the library when following up a citation; (s)he may just write down what the reader thinks the date means, for example, write 2010-11 as Nov. 2010. When the issue written down does not exist, reader may have difficulty figuring out the reason for the error. Jc3s5h (talk) 23:22, 3 February 2014 (UTC)
• Ban yyyy-mm. We are supposed to be writing articles which are clear and unambiguous, this is not clear and is certainly not unambiguous. People should not have to read the MOS to find out the meaning of something in an article it should be obvious. For similar reasons I would also support a Ban yyyy-mm-dd. Keith D (talk) 01:42, 4 February 2014 (UTC)
• Ban yyyy-mm. and any format where the month is not clear and unambiguously represented by its proper name (and not some notional number) -- Ohc ^¡digame! 02:07, 4 February 2014 (UTC)
• Ban yyyy-mm. It's just too ambiguous and prone to confusion with yyyy-yy (a year range). I can see why people are opposed to yyyy-mm-dd as needing to be interpreted and as more ambiguous than dd mmm yyyy, but I can't work up adequate passion against it. – Jonesey95 (talk) 05:15, 4 February 2014 (UTC)
• What is the problem that needs to be solved?  As per Wikipedia:MOSNUM#Ranges, yyyy–yy uses an en dash.  I checked http://reftag.appspot.com/, and curiously it has two different modes (possibly a bug) when asked to convert July 2009 into y-m-d format.  One is "July 2009" and the other is "2009-07".  I also recall contexts in which software deems "July 2009" to occur on the first day of the month.  Since it doesn't seem to be clear, I'd recommend specifying that mmm yyyy format is acceptable in the yyyy-mm-dd context.  Unscintillating (talk) 03:03, 6 February 2014 (UTC)
• YYYY-yy should be banned, it causes confusion with YYYY-MM, and that format is used in the world at large. We shouldn't engender confusion just because we are Wikipedia. We can avoid confusion by using YYYY-YYYY. -- 70.24.244.161 (talk) 12:24, 11 February 2014 (UTC)
• Context – If the area in question previously uses YYYY-MM-DD especially, or if the prose speaks of months not year-ranges, the reader will be able to infer the correct meaning. If anything should be banned, it would be YYYY–YY, which is purposeless and easily avoided by YYYY–YYYY. Also en dashes are not hyphens. startswithj (talk) 00:36, 13 February 2014 (UTC)
• Allow YYYY-MM and ban YYYY-YY. Year ranges should not be using a hyphen, anyway. YYYY-MM is the standard way of representing years and months, as specified by the ISO 8601 international standard, and its national variants. In the case of conflicts, YYYY-MM and YYYY-MM-DD date formats should be preferred. --Joshua Issac (talk) 11:41, 6 March 2014 (UTC)

@Joshua Issac: Year ranges are already supposed to use an endash, not a hyphen (though I don't think this does enough to resolve the ambiguity). —[AlanM1(talk)]— 23:15, 8 March 2014 (UTC)

• Allow YYYY-MM and ban YYYY-YY. I am in agreement with Joshua Issac. We should allow YYYY-MM and ban YYYY-YY. I also agree with AlanM1 that the use of a en-dash does not do enough to resolve ambiguity. Those who need to do a year range should spell the full four digit year YYYY–YYYY and preferably use an en-dash. This seems dis-ambiguous enough as there are no four digit months. Zell Faze (talk) 14:58, 11 March 2014 (UTC)
• Context While YYYY-MM is not ideal in most places, in a table that has a row for each month of several years, it makes sense, and avoids the burden of a hidden sort key. For clarity, I'd add "(YYYY-MM)" in the header. —[AlanM1(talk)]— 23:15, 8 March 2014 (UTC)
• Context The immediately preceding is logical. So "Allow YYYY-MM (allowed particularly within tabular / sorting settings, and disfavored in "open text" settings) and ban YYYY-YY (for which there is no "utility" value)" is also logical. The overall logic is driven by the ability to autosort descending hierarchicals. Conversely, banning YYYY-MM as a conceptual step toward banning YYYY-MM-DD (or YYYMMDD) is counterproductive prejudice, and also indirectly raises the irresolvable: MM-DD-YYYY versus DD-MM-YYYY. FeatherPluma (talk) 17:37, 13 March 2014 (UTC)

Threaded discussion

• The most likely place for the problem to occur is in references. A date like 2003-08 is unlikely to mean a publication covering multiple years. A date like 2003-04 could mean April 2003 or an anniversary issue covering 2003-2004 but it is usually clear from the context which it is. The majority of readers won't care anyway and for the few that want to look it up it will become obvious quite quickly. For the few times where it does represent a problem (eg the magazine had both an April 2003 issue and a 2003-2004 anniversary issue), then that article can choose one of the other date formats.  Stepho  talk  23:06, 3 February 2014 (UTC)
• I know this is a personal opinion, but to my eye, "2003-08" just looks like a typo. My eye comes to a complete halt and my brain is forced to wonder if someone simply made a mistake of some sort. Did they mean "2003-04"? "2007-08"? Did they forget the day (or the second half of the year) in a YYYY-MM-DD date, like "2001-03-08"? I don't have a grammar or style argument here, it's just a visceral thing that happens when I encounter one of these odd creatures. – Jonesey95 (talk) 05:20, 4 February 2014 (UTC)

(This appears to be the freshest part of the discussions, feel free to move my comment to a better place.) Thanks to Trappist_the_monk for the pointer on Category talk:CS1 errors: dates, I haven't looked into any MOS pages for ages, replacing GB by GiBi gibberish would annoy me; and some ISO "standards" are certainly crap. However, RFC 3339 and the 1997-09 note published by the W3C are no nonsense, and it's the job of the MediaWiki software to display YYYY-MM-DD or YYYY-MM in the form chosen in the preferences or some default chosen by the site admins for editors without an account or preferring to edit without logging in. It's not the job of MOS guidelines. My 0,02€ –Be..anyone (talk) 14:18, 5 February 2014 (UTC)

Date autoformatting has been resoundingly rejected by the community for many reasons, see footnote 7 of MOSNUM. One of the reasons is you can't get the commas right. Consider "the meeting is set for July 22, 2014, at Grand Central Terminal." If "22 July 2014" is substituted for "July 22, 2014" there will be an incorrect comma. Jc3s5h (talk) 14:43, 5 February 2014 (UTC)

What is incorrect about the comma in the clause "the meeting is set for 22 July 2014, at Grand Central Terminal"? --Joshua Issac (talk) 12:17, 6 March 2014 (UTC)

• Seems like the yyyy-mm-dd haters have all chimed in for 'Ban yyyy-mm'. So be it. Now we are back to where we were 2 months ago. What do we do when we want to add a month magazine as a reference in an article chock full of yyyy-mm-dd references? Since yyyy-mm is not allowed then we are forced to use mmm yyyy. MOS:DATEUNIFY then forces us to change each and every other reference over to a spelt out form. That's a rather radical change that is not obvious from the current text of the guideline. Two solutions are:
  • Add text in the guideline to make it clear that yyyy-mm-dd dates are okay only until the first year+month reference is added, then they become illegal due to MOS:DATEUNIFY.
  • Relax MOS:DATEUNIFY so that July 2006 and 2006-06-01 can sit side-by-side.

Both of these solutions were proposed in Part 2 and neither found favour. But since yyyy-mm is banned, we have to select one of them.  Stepho  talk  23:02, 6 February 2014 (UTC)

History

Our use of YYYY-MM-DD dates is pretty much an accident. In the early days of Wikipedia, the concept was to use YYYY-MM-DD dates and link them— the user date preference would then show them in the users desired format. As early as 2006, it was realized that readers who were not logged in would see dates in the YYYY-MM-DD format. In late 2008, the consensus was to stop linking dates— dates were delinked and sometimes reformatted, but no changes to the MoS was made as to formats. There have been several discussions about YYYY-MM-DD date formatting over the years, with little or no result.

For discussions on date formats, mainly in the context of citation templates, see User:Gadget850/FAQ/YYYY-MM-DD dates. --  Gadget850 ^talk 20:45, 27 February 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Writing SI unit names

The current guidelines on pluralising unit names seem to be incomplete. I'd suggest incorporating the advice in this NIST guide, at least for metric units: thus units combined with values below 1 are considered grammatically singular (e.g. 0.25 metre, 10^-3 watt). Phrasing such as "0.1 of a metre" should also be avoided.

In addition, it should be specified that numbers with unit symbols should not be hyphenated (e.g. "100-m bridge"), and periods with unit symbols ("100 m.") should be avoided — I cannot see this in the current guidance.

It might be worthwhile to emphasise that the prefixes are always attached to the unit name (never spaced or hyphenated as in "milli gram" or "kilo-pascal"), and are uncontracted except in the case of: kilohm, megohm and hectare. The plural of "henry" is written "henries" since it's considered a regular noun for English grammatical purposes. Archon 2488 (talk) 16:47, 5 March 2014 (UTC)

Or Henry's. --2 potatoe's (talk) 07:27, 6 March 2014 (UTC)

Sounds good to me. The plural of hertz (hertz) might also be worth a mention if not there already. Dondervogel 2 (talk) 18:19, 5 March 2014 (UTC)

I've added the invariant unit names to my proposal and put it in my sandbox with a couple of minor fixes. I didn't look closely enough: it already says not to use periods. Let me know what you think. Archon 2488 (talk) 21:37, 5 March 2014 (UTC)

I would oppose pluralising English words - be they units or otherwise - in a way that does not conform with English grammar. According to your proposal, it appears to me that we are to talk about zero cakes and 0.75 dollars, but zero kilogram and 0.75 kilometre. I do not believe that this would be grammatical. Kahastok talk 22:19, 5 March 2014 (UTC)

I agree in opposing this. Standard English usage would be 0.25 metres and 10^-3 watts, regardless of what NIST advocates. Wikipedia follows actual use, not official standards. —sroc 💬 23:26, 5 March 2014 (UTC)

This is quite a thorny question, I think. The rules of English grammar are very weird with fractions: when you use vulgar fractions you'd always use the singular: 3/4 dollar, not 3/4 dollars. Likewise, "a half litre", not "a half litres"; I suspect we instinctively don't like the sound of "0.5 litre" because the numeral next to "litre" is "5" which makes us think "plural", even if it's not really logical. Since decimal fractions are just a different way of representing the same numbers it's not obvious why they have to be treated differently, and style guides aren't consistent. The number zero is a separate case of its own: I think it should probably always take the plural (obviously 0 is neither singular nor plural, but grammar is a bit illogical), however the degree Celsius (or for what it's worth, the degree Fahrenheit) is the only unit you'd commonly use with a zero (because 0 °C is just an arbitrary temperature, not the true physical zero point of temperature). There's not too much sense in talking about "zero kilometres" because if something has no length (or mass, or whatever) then units aren't really relevant: 0 km = 0 Mpc = 0 Å. To add to the complication, it's formally permissible to write the SI unit names in the singular even when the value is greater than 1, so you'll commonly encounter strange-sounding things like "the magnetic field has a strength of 2 tesla". Absolute zero is commonly referred to as both "zero kelvin" and "zero kelvins" so it's a bit of a coin-flip really. Derived units without special names, such as kJ/(mol K), are supposed to be read as invariant singulars, but this rule is commonly ignored: most people don't say "100 kilometre per hour".

All that being said, the guidelines are just NIST's interpretation of how to say and write SI units in (American) English: they're not an intrinsic part of the SI. For the purposes of Wikipedia it might be best to pick a more simple and consistent set of rules: for all metric units, with values other than ±1, use the plural form; otherwise use the singular (so you would also write "negative/minus one degree Celsius" for example). Imperial/USC units written with vulgar fractions should use the singular: "5/16 inch", not "5/16 inches" (metric units are never written with vulgar fractions, so this rule doesn't apply to them). Opinions? Archon 2488 (talk) 23:36, 5 March 2014 (UTC)

I have modified the proposed changes in my sandbox in line with the suggestions above. I've also added a bullet point on how to write the names of units containing powers. Archon 2488 (talk) 00:26, 6 March 2014 (UTC)

I would say half a litre but .5 litres. Linguistically, it is easy to say that something is "half" or "quarter" of a whole ("a litre") because these are basic divisions, but it's not as easy to do this with decimals. If we said .5 litre, then would we also say .6 litre or .521 litre? We would not say five hundred and twenty-one thousandths of a litre in words, so as a corollary, the equivalent in numerals seems odd. —sroc 💬 01:00, 6 March 2014 (UTC)

Archon, you write "Since decimal fractions are just a different way of representing the same numbers it's not obvious why they have to be treated differently". I agree, it's not obvious. However, what is obvious is that they are treated differently. It's not obvious why "I" is always capitalised whereas "he", "she", "me", etc. are not. It's not obvious why it's "himself" and "themselves" (not "hisself" and "theirselves") whereas we have "myself" and "yourself". It's not obvious why we don't spell "yacht" as "yot", "friend" as "frend", "head" as "hed", etc. Decimals and fractions may represent the same things but they are different things. When you see "3⁄4 metre" you read it as "three quarters of a litre" (just as you read "on 6 February" as "on the sixth of February") but when you see "0.75 litres" you read it as "zero point seven five litres". I suspect that it was some failure along the way to see the distinction between fractions and decimals that lead to the artificial rule that they should be treated as equivalent. Wikipedia is not bound by outside style guides (nor need it be nor even should it be). We are free to make and follow our own rules. In creating such rules it would seem that normal English usage should trump the dictates of some organisation like the US NIST. In normal English usage we don't make any special exception for metric unit names when it comes to pluralisation: they are simply treated as ordinary nouns. This is what we should follow. It is possible to combine fractions with metric units (albeit less common) just as it's possible to combine fractions with imperial/US customary units; in fact fractions and decimals can be combined with many things (not just units). You write "For the purposes of Wikipedia it might be best to pick a more simple and consistent set of rules" and I agree but the rules you suggest are more complicated and inconsistent for my liking. I suggest units be they metric, imperial, US customary or otherwise be treated as any other noun for the purpose of pluralisation and that for ±1 and fractions (but not decimals) between the noun be singular and for other numbers it be plural. Jimp 08:36, 6 March 2014 (UTC)

I've revised my proposed changes in line with other people's suggestions. Some of the NIST guidance is still useful, even if their pluralisation advice is a bit strange, and it covers some points which the existing MOSNUM version does not — I think this should be included, at least for the sake of completeness.

Metric units aren't supposed to be written with vulgar fractions in general, and this is already covered by MOSNUM:

Unless there is sound reason to the contrary, fractional parts of metric units should be expressed as decimal fractions (5.25 mm), not vulgar fractions (51⁄4 mm). However Imperial, English, avoirdupois, and United States customary units may use either form – both (5.25 inches) and (51⁄4 inches) are acceptable, provided that there is consistency in the way that the fractions are represented.

Archon 2488 (talk) 12:02, 6 March 2014 (UTC)

I'm fairly certain that, with regard to imperial, one should not write "5.25 inches" or whatever. This is contrary to how the system was designed, and how it was meant to be used. It should be "51⁄4 inches". RGloucester — ☎ 16:46, 6 March 2014 (UTC)

Traditionally, you would be correct, but (at least in the USA) the convention of decimalising inches (and other such units) is well-established. American firearms are typically described in terms of their nominal caliber in decimal inches (.308 Winchester, etc.). For machining in USC units, it's common to subdivide inches into thousandths (or "mils"). There's no real contemporary guidance on how imperial/USC units should be used, so you'd just follow the use that was conventional in the relevant field, whether that be fractional or decimal inches. This is why MOSNUM allows both formats. Archon 2488 (talk) 17:48, 6 March 2014 (UTC)

I suppose so. It feels weird, however, to use a system meant to be used with vulgar fractions, but use decimalised fractions instead. RGloucester — ☎ 18:07, 6 March 2014 (UTC)

I agree with it feeling "weird" every time I take a measurement with a ruler and convert 1/4 to 0.250, but I think computers have pushed us towards doing it because of not having the 1/4 and 1/2 (let alone 3/16) characters in the standard 7-bit ASCII character set or keyboards any more, the "ugliness" of having to insert a space for the fraction when not written in a smaller font (i.e. 5 1/4) and the result still not being as "clean" as 51⁄4, etc. So, we just get used to converting to 5.25 because it's easier to type, see, and store in a database. There are a few special limited circumstances that still work better retaining values as fractions, like some financial instrument pricing (and not even there for much longer, with most markets having been decimalized), and we should retain them in quotes as well.

As far as plurals, it seems the best "sounding" rules are those that follow how one would read it aloud: 1⁄4 liter, but 0.25 liters; ¾ [of an] inch, but 0.75 inches; 1⁄2 [an] acre, but 0.5 acres. —[AlanM1(talk)]— 18:54, 6 March 2014 (UTC)

The Daily Telegraph, which is quite biased in favour of Imperial units (which it calls "British units"), recommends the following:

"Fractions: use half, quarter, three quarters, third, fifth, eighth in preference to decimals in general copy. Use decimals when they aid comprehension or comparison, but not with imperial measurements: e.g. write 3ft 9in rather than 3.75 feet, or 6lb 8oz not 6.5lb. Do not use decimals and fractions in the same story except when necessary in financial copy. In money markets all dealings are in fractions. Write 2¼, but one-quarter per cent."Link

I tend to agree with recommending "3ft 9in" over "3.75 feet". RGloucester — ☎ 19:05, 7 March 2014 (UTC)

Generally, yes, but this is another reason why we need to bear in mind that a style guide is not holy writ. Being too strict about the details of usage (as opposed to purely stylistic things, such as not pluralising unit symbols and needing to insert a space between value and unit) can lead to editors being recommended to write about the "Winchester 77⁄250" (or, indeed, a "6.2-mile race"). It's important to bear in mind that these rules have to cover a myriad of cases from many different disciplines.

Now that the discussion seems to have quietened down, can I assume that there are no further objections to my proposal? I'll leave another few days for comments, then incorporate my sandbox version into the MOS. Mostly, they are just stylistic advice included for the sake of completeness, so I don't imagine they could cause problems in practice. Archon 2488 (talk) 16:10, 10 March 2014 (UTC)

I'd prefer "mixed units are traditionally used for most measurements in the imperial and US customary systems". I'd also like an example given for weight and liquid volume, as well as for length. RGloucester — ☎ 18:43, 10 March 2014 (UTC)

OK, changes made. Archon 2488 (talk) 19:38, 10 March 2014 (UTC)

It looks pretty good to me. RGloucester — ☎ 20:42, 10 March 2014 (UTC)

I don't believe that there is consensus for all of the changes that have been made. I stick by my comments above. Also see the various comments by other most other regarding the notion that units names are somehow special nouns for the purpose of pluralisation. Here is the inserted/modified text. (I've numbered the the points for reference.)

1. Only the unit of appropriate magnitude, or the unit generally used in the relevant context, should be used: thus 10 metres not 0.01 kilometres. In particular, measurements in metric units should not be given using mixed units: 1500 metres or 1.5 kilometres, as context dictates, but never 1 kilometre and 500 metres. Mixed units are traditionally used for most measurements of appropriate magnitude in imperial and US customary units: 10 feet 5 inches, 3 pounds 2 ounces, 1 pint 8 fluid ounces.
2. The SI prefixes centi-, deci-, deca-, and hecto- are rarely used, and thus should be avoided, in most contexts: exceptions include the centimetre, the decibel, the hectolitre, the hectare and the hectopascal. Thus: 100 metres, not 1 hectometre.
3. Measurements in metric units consisting of values other than ±1 should use the plural form of the unit name; otherwise the singular form is used. Thus: negative one degree Celsius, 10^-3 watts and 0.25 metres, not 10^-3 watt, 0.25 metre or 0.25 of a metre. In the case of imperial or US customary units with values in vulgar fractions less than 1, the singular form is used. Thus: 5⁄16 inch, not 5⁄16 inches or 5⁄16 of an inch.
4. Unit names are typically considered to be regular nouns for the purposes of English grammar. Thus their plurals are most commonly formed by appending an s: 10 metres. The exceptions are the henry: 10 henries, not 10 henrys, as well as the hertz, the lux, and the siemens: these are invariant, so their plural forms are always the same as their singular forms: 10 hertz, 10 lux, 10 siemens.
5. Unit prefixes are considered to be part of the unit name, and should never be separated by spaces or hyphens, thus: 25 kilopascals, never 25 kilo pascals or 25 kilo-pascals.
6. Unit prefixes should be written without contraction; the exceptions are the kilohm, the megohm, and the hectare (not kiloohm, megaohm, or hectoare).
7. The "metre-newton" as a unit of energy is properly and commonly called the joule in the SI: thus 10 joules, not 10 metre-newtons.
8. When unit symbols are combined by division, use a slash ... Common exceptions in imperial and US customary units include mph for the mile per hour and psi for pounds per square inch; metric unit symbols should always be written according to SI convention, thus g/m² not gsm.

Most of this seems okay; however, there are a couple of problems. Here are the main ones.

• I wonder whether some of this is fixing a problem which doesn't exist. Most of the advice is sensible but it seem obvious enough not to need mentioning.
• "Avoid this" and "only use that" seems a bit strict, exceptions do exist.
• It looks like we're proposing one set of special rules for the names of metric units and another set for the names of imperial/US units which differ from how ordinary nouns are to be treated. Unit names are just nouns and should be treated as such.

Here are a few more detailed comments.

1. Whilst generally, yes, we'd use the unit of appropriate magnitude exceptions may exist (e.g. if elsewhere in a paragraph you're using hectares for the size of parks but one or two of them are larger than 100 ha, you wouldn't switch to square kilometres). Isn't this just common sense though? Also I don't recall seeing the likes of "1 metre 45 centimetres" on WP. So need we advise against this?
2. This isn't really a big problem. These are rarely used out there, it's true, and they're therefore rarely used in here. I'm just not sure that we need to mention this but if we do we needn't be as strict as to say "avoid". They are used, albeit rarely, since there are some occasions where they are appropriate. So they should be used where appropriate. Do we need to mention that appropriate units should be used?
3. We follow the rules of English when it comes to pluralisation. These rules do not distinguish between metric units, imperial units, US customary units, other units or other things in general. This has nothing to do with what system of measurement you're using. Forget talk about metric vs imperial/US, we need only state that 1, −1 and fractions (but not decimals) between are singular and anything else is plural.
4. The phrasing is a bit confusing here. It's not clear whether you mean that the henry, hertz, lux and siemens are exceptions to the rule of forming a plural by adding an "s" or to being typically considered to be regular nouns for the purposes of English grammar. Units names are nouns. It's common for an word ending in "y" to be pluralised by turning the "y" into an "i" and adding "es" (e.g. "party"→"parties", "story"→"stories", "lorry"→"lorries", etc.) and it's not that uncommon for a plural to have the same form as it's singular (e.g. "fish", "sheep", "deer", etc.).
5. I'm not sure that we need to mention every possible misspelling.
6. Again, you might find that it's common knowledge that unit prefixes are considered to be part of the unit name (that's what a prefix is). Do we need to spell this out? I don't recall seeing this mistake.
7. Again, I haven't seen a joule being called a "metre-newton". Do we need to mention this?
8. This clearer than what was there before.

So, like I said, it's mostly fine though a bit over-the-top in parts and seems to imply that unit names are somehow special noun that defy the rules of grammar. Jimp 15:19, 12 March 2014 (UTC)

Thanks for your feedback. Like I say, most of this is included for the sake of completeness and unambiguity. The advice on what not to write covers things that are certainly wrong; it's not about which units to use in which context, which is a more subtle question.

1. This is why I added the phrasing "or the unit generally used in the relevant context". If you're talking about aircraft flight levels, you'll give numbers in feet and metres, even though the numbers are large, without switching to miles and kilometres. Sometimes people who apparently don't understand how to use the metric system properly will say things like "1 metre 45 centimetres"; it's useful to clarify that this is incorrect usage.
2. It says "should be avoided in most contexts", which I think is fair. You should switch directly from metres to kilometres without using decametres or hectometres. Nobody talks about centigrams. Perhaps this could be changed to "... are rarely used in most contexts" to remove the "avoid" phrasing, if you think it's too strong.
3. Yes, I think your phrasing is clearer. My original phrasing was intended to emphasise that only imperial/USC units should be written with vulgar fractions, but this could probably be clarified.
4. I should clarify that I abandoned the position that unit names are in any way "special nouns" for the purposes of pluralisation (my added text says they are "regular nouns"). The henry deserves special mention because people can sometimes get confused by unit names derived from proper nouns: the unit is not considered a proper noun. It's useful to name the three SI units with invariant names.
5. If by "misspelling" you mean "kiloohm" etc., then those are the only three cases where the unit name should be written with a contracted prefix. It's an exclusive list.
6. Maybe this is spelling things out in too much detail.
7. The phrasing of this in the original was a bit odd: saying that for torque units have force unit first and energy is length-first, is relevant advice only for imperial/USC. The SI doesn't have this problem because the energy unit has another name. I could rephrase it so that it's clear it applies only to foot-pounds and pound-feet.

Archon 2488 (talk) 11:54, 13 March 2014 (UTC)

Perhaps we could add some advice recommending decimals with metric and fractions with imperial/US but I wouldn't make it a hard-and-fast rule. Sometimes it's useful to do the opposite, e.g. the "1.6" in "about a mile (1.6 km)" seems to imply more precision than it should whereas "about a mile (1+1⁄2 km)" avoids this, on the other hand, "3.1453 centimetres (1.2383 in)" would generally be far better than "3.1453 centimetres (1+1952⁄8192 in)".

Oddly it seems that your sensible (if possibly unnecessary) advice disallowing metre-newton has evolved into a comment merely calling it less common than the equivalent joule. The current wording seems to imply that it's okay. It's surely not but this is probably a topic of its own. Jimp 08:07, 17 March 2014 (UTC)

Incidentally, in Australia and New Zealand—possibly elsewhere—it's standard practice to close the 12-hour clock number and the am or pm: 3pm, 9am. Tony (talk) 14:34, 29 March 2014 (UTC)

Adding examples of both correct and incorrect usage can help greatly, especially if the reader's English comprehension is not the best (and for whom the guide is most useful). While I agree there are exceptions to the prescription of correct units to use, mentioning those may well be too much. Looks good to me. —[AlanM1(talk)]— 06:49, 5 April 2014 (UTC)

UK horses' heights

At the moment MOSNUM says that horses and other equines are measured in hands. This may be true, but it doesn't seem to be the whole truth.

Equine World UK says:

The term used for height measurement of a horse is "hands high" or "hh". Often the height is just over a number of hands eg 16 hands and 2 inches and the height is therefore referred to as 16.2 hh. With Europeanisation horses are also now being measured in centimetres, particularly small ponies. See conversion table for horse's height in hh and cm. [4]

The Joint Measurement Board website doesn't appear to mention hands but its references to measurements seem to be centimetres first.

7. The animal must be positioned for measurement with the front legs parallel and perpendicular; the toes of the front feet should be in line, allowing not more than 1.5 cm (½ in) difference. Both hind- feet must be taking weight and as near perpendicular as possible; the toes of the hind feet should be not more than 15 cm (6 in) out of line with each other.

8. The animal’s head must be in its natural position in relation to its neck, positioned so that the eye is neither more than 8 cm (3in) below, nor more than 8 cm (3 in) above the highest point of the withers.

British Showjumping has this question and answer on its website:

If a pony (148cms or smaller) has been registered as a horse can it be registered back as a pony?

Yes, however the request must be sent to the British Showjumping office in writing and must be accompanied by a valid up to date JMB Height Certificate stating that the animal is 148cms or below.

On the other hand, Blue Cross uses hands. Even when it appears to use kilograms for their weights (but they work it out with a weight tape in inches that works out an approximate weight in pounds that is divided by 2.2 to give you kilograms!) see [5]

Scottish Horse had this headline: Measuring Horses and Ponies - ongoing controversies [6]

Here were some problems:

• ...it is the inescapable fact that there is no rigid anatomical connection between the withers and the feet that touch the ground. *...simply allowing an excited pony to stand and relaxed can, in my experience, cause the height to drop by as much as 6cm. *...Measurements are taken without shoes and simply trimming the heels and leaving the toes long can reduce height by more than cm. (sic)
• Lowering the head to the ground can significantly reduce the height at the withers – by nearly 2cm – whereas raising the head can increase height by over 2cm.

Then there was this passage:

I distinctly remember, in the line of ponies waiting to be measured at Avenches, Switzerland in 2008, a grey horse that looked at least 15.2hh. Fearful of creating an international incident I anxiously awaited its arrival at my station. It settled into the stable and when I put the stick onto its withers the horizontal bar read over 156cm. But the withers instantly started to shrink under the bar – as if contact with the stick had triggered a reflex – and kept sinking until, within a couple of minutes, the pony measured 151.5cm. Many of the ponies at this year’s championships showed similar reactions, no doubt the results of months of training at home. Why go to all that effort? Putting it bluntly, a European team pony might be worth several hundred thousand Euros, whereas a pony that won’t measure 151cm is practically worthless.

There is no way that I can be dogmatic about ponies and horses. However, it would seem that "Hands for horses and other equines" is perhaps an over-simplification. Michael Glass (talk) 13:52, 8 March 2014 (UTC)

In whatever units the horse may be measured, I think we can all agree that it is dead. Please stop flogging it. Kahastok talk 14:25, 8 March 2014 (UTC)

Like Montanabw^(talk) 19:26, 10 March 2014 (UTC)

OK, but where's your evidence to justify the present policy? Michael Glass (talk) 21:26, 8 March 2014 (UTC)

The whole section on UK units is more than a bit arbitrary and overly simplistic, but it's the product of an uneasy political compromise between editors. Until our country actually does something to sort out the bizarre non-system of units in use here, the situation will not change. Archon 2488 (talk) 16:34, 10 March 2014 (UTC)

Actually, in the particular case of units for measurement of horses in the UK there was no compromise or indeed discussion; the present text was added by Montanabw with this edit. Since what it says seems to be at variance with the usage of bodies such as the Joint Measurement Board and the National Pony Society], some discussion is probably called for. Justlettersandnumbers (talk) 18:26, 10 March 2014 (UTC)

There are now four discussions on UK-related units on this page, three of them started by the same editor. I think they all ought to be combined.

I don't accept your link as relevant because you're inferring a policy from individual instances of usage. All of Michael's "evidence" is in the same category. We have no reason to assume that all or any other documents use the same units as the ones you have found. Demonstrate a policy and that might make a difference, though I would note that it would be surprising if more than a small minority of horses actually took part in competition. I note that there is no actual proposal here at all, and that in a previous discussion (still on this page) the proposal was to add a qualification ("most") that achieved nothing but to make an already little-used rule harder to follow.

This is all standard stuff and Michael has heard all of it before, because he has opened similar sections here on dozens of occasions. Kahastok talk 19:05, 10 March 2014 (UTC)

• I did add the hands material here, believing in good faith that it reflected the consensus of WikiProject Equine. This issue was debated quite extensively at WikiProject Equine, with the UK-resident editors all in agreement with the USA editors on this matter: horses are generally (though not exclusively) measures in hands in most (though not all) of the English-speaking world, including the UK. We have gone on to do a lot of work on the convert height template so that it displays in hands, inches and centimeters, and editors may choose which default to go first; those editors who wish to begin with metric measurements and then have the conversion work in that direction can do so on the articles where they are doing most of the work and/or have a clear consensus on the matter. This was a situation where we seem to have reached a workable solution everyone can live with. But there were a lot of strong feelings on all sides before we got there and I believe we are all rather weary of it now and yes, WP:STICK is my feeling as well. JLAN's comment above about pony measurements outlines a couple of situations, 1) some ponies, especially the smaller ones, are often measured in inches or cm than hands, (also true of donkeys) and 2) the FEI uses centimeters for most of their height regulations, due to the international nature of this organization. I don't think it will benefit the wiki to reopen this whole situation again, though if we want to refine the instructions here to reflect the occasional exceptions (i.e. some ponies and donkeys if their governing organizations so state and if editors reach consensus on the matter, basically) Montanabw^(talk) 19:26, 10 March 2014 (UTC)

The issue with spelling all of this out ad nauseam is that it threatens to produce instruction creep. As I said before, why do we bother to tell WP editors how to talk about bottled milk in one country? This isn't a dairy. Archon 2488 (talk) 20:38, 10 March 2014 (UTC)

I agree with you Archon, but I am also open to a spirit of compromise if it seems helpful. Most of these types of disputes usually wind up being decided on an article by article basis in the long run, anyway. Montanabw^(talk) 20:46, 10 March 2014 (UTC)

If usage is somewhat divided and these questions are usually decided on an article by article basis, why not qualify the general statement with many or most? Michael Glass (talk) 00:46, 11 March 2014 (UTC)

Adding words like "many" or "most" doesn't change the substance of the statement, so there is little point. It introduces a degree of vagueness which isn't helpful; if you want to provide more detailed information on usage in different contexts, that would be far better. Archon 2488 (talk) 17:38, 11 March 2014 (UTC)

I propose that both the milk-bottles and the horse heights be removed from the guideline, mostly for the good reasons such as WP:CREEP given above, also because the former is unlikely to be used outside Milk bottling in the United Kingdom, the latter because it does not accurately reflect the actual practice of British institutions concerned with horse measurement (unless of course Kahastok can cite a policy to the effect that it does?). Justlettersandnumbers (talk) 21:09, 11 March 2014 (UTC)

I'm of mixed feelings; I'm no fan of WP:CREEP, but OTOH the chart seems to have many other exceptions, troy ounces, carats, (and karats), knots, etc... My sense is that one reason to keep it is to avoid future fights like the one we had about four or five years ago where someone (not anyone involved in this discussion) wanted to eliminate use of hands altogether and replace every article with SI units, citing, if I recall, this page of guidelines. Montanabw^(talk) 23:30, 11 March 2014 (UTC)

Groan, oh no, not again. Suggest the guideline stays and the WP:STICK is dropped. Wee Curry Monster talk 08:47, 12 March 2014 (UTC)

The milk bottle thing is pretty much a waste of space, and it strikes me as boring editors with trivia. Even if the arch-demon Michael Glass were to get his wicked way and banish the milk exception from MOSNUM, I doubt it would make a difference to a single article. If the need arose, you would describe the milk bottle in terms of pints or litres, depending on whether it was an imperial or metric bottle. That's common sense, it already falls under the rule to give nominal/defined quantities in the original units first, and does not need a separate rule.

Regarding the hands, if it's the normal notation used to express horse heights in the English-speaking world, why is it positioned so that it seems to apply exclusively to the UK, and not even mentioned in the context of other Anglophone countries? That's a bit odd. Archon 2488 (talk) 11:22, 13 March 2014 (UTC)

Didn't know it was positioned only as a UK measurement; it's also the default in the USA and Australia. Montanabw^(talk) 18:44, 14 March 2014 (UTC)

Please lend a hand

Since you horsey people have dropped in to visit, could you clarify something while you're here? At WP:Manual_of_Style/Dates_and_numbers#Specific_units it says "Hand... A dot followed by additional inches specifies intermediate heights." Can someone clarify that, maybe with an example (in addition to doing whatever needed, if anything, to incorporate the withering discussion here above)? EEng (talk) 15:15, 11 March 2014 (UTC)

I'll take a peek, may need rewording. See Hand (measurement).

What it means is that you have notation such as "16.1 hh", meaning a height of 16 hands and 1 inch (or 16.25 hands in decimal notation). It's not a decimal point, which is very confusing. My own feelings on the recommendation to use hands are somewhat mixed: I generally support having as the primary quantity the unit that is most used in the real world, even if it's otherwise quite unfamiliar (I'm not so persuaded by the "this might disadvantage our readers" argument, because that is why we provide conversions), but on the other "hand", it seems to me that Wikipedia should generally prefer SI units for most things, because they're the "gold standard" of international measurement.

Most people who aren't horse types would think about horses' heights in cm or inches, so conversions are provided to those units. This seems like a reasonable compromise. I don't think the hand notation should be primary in articles about (say) horse biology, but should be OK for racing horses etc. Archon 2488 (talk) 16:04, 11 March 2014 (UTC)

Horse heights would never be stated as "16.25" hands under any set of circumstances - the period is a radix point not a decimal point. If someone was wanting to explain to non-horse poeple they might say "16.1 hands of 65 inches" or if a horse was a half-inch between hand measurements, it might be 16.1-1/2 hands. Hands is used as a measurement in both sport and even in some general science/biology articles in English-language works, with the caveat that in certain types of studies, yes, centimeters might be used. But hands is the general default. We've been over and over this at least five times since I've been on wiki, in various contexts, and like other oddball measurements, such as the nautical mile, there are IAR exceptions all over the place, as below. WikiProject Equine has hashed this out pretty thoroughly, as noted above, mostly in our desire that whichever unit is preferred, that convert templates are used so that everyone gets it. We have been quite meticulous to be sure to use {{hands}} and its relatives to convert any hands measurements to both inches and centimeters, so all can understand. Montanabw^(talk) 23:20, 11 March 2014 (UTC)

I know that "16.25 hands" is nonstandard, but if you're not very accustomed to the non-decimal arithmetic of imperial units, it's a bit more intuitive. Likewise with other imperial units: "16.25 miles" would more traditionally be rendered as "16 mi 440 yd" or "16 miles 2 furlongs", but most people understand the decimal notation much more readily, especially if they're more used to working with metric units. Archon 2488 (talk) 23:56, 11 March 2014 (UTC)

But completely incorrect and not to ever be used! For example, when surfing Craigslist for horses, a lot of people who try to sell a horse that is, say, 15.2 hands - i.e halfway between 15 and 16 hands - will advertise it in a decimal as "15.5 hands" which will get them labeled as a) a total idiot who knows nothing about horses, or b) a slimeball trying to pass off a 15.2 hand (62 inch) horse as one that is 16.1 hands (66 inches). Of course, these same people usually have ads that read something like "well-bread mare with gud confirmashun, 15.5 hands, we havnt riden her in 10 yrs but she likes to eat carrots and we kin ketch her 2x yr to trim her feets." So, do with that as you will (LOL) Montanabw^(talk) 03:10, 12 March 2014 (UTC)

Thanks. For the record, I'm not interested in the argument about whether or where hand should be recommended/required, just making the table clear in its explanation of what the unit is. And also for the record, I don't know why I didn't just look in the article linked from the table. BTW, yes the use of the "point" is unfortunate, but then I've always thought that the American colon for time-of-day (3:05pm) makes much more sense than the more international 3.05pm, for the same reason. But then no one seems to have seriously suggested decimalizing time for some reason, so maybe time measurement has some kind of reform immunity. EEng (talk) 19:53, 11 March 2014 (UTC)

American baseball statistics use a similar faux decimal notation for innings pitched. Innings pitched are measured in thirds, since there are three outs per inning (per half-inning, really, but let's not get into that), so a pitcher who pitches seven full innings and gets one out in the eighth inning will be shown as having pitched "7 1/3" or "7.1" innings, depending on the style guide of the publication in question. – Jonesey95 (talk) 20:01, 11 March 2014 (UTC)

I don't know that 3.15 pm is a more international notation for times... everywhere I know of in the English-speaking world would use a colon, and the international date-time standard ISO 8601 mandates the use of the colon for hour-minute separation in times. Also, most parts of the world would prefer 24-hour time notation (most languages don't even have an equivalent of am/pm). So I'd say 15:15 would be the most international way of writing that time.

Decimal time has been proposed occasionally throughout history (most famously during the French revolution) but it never really caught on. Archon 2488 (talk) 20:09, 11 March 2014 (UTC)

(ec) The same happens for balls in an over in cricket. There are six balls to an over, so "11.5 overs" means 11 full overs and 5 balls. Kahastok talk 20:17, 11 March 2014 (UTC)

The French Revolution reference is particularly apt since it provides so many striking precedents for what we see at Talk_MOS -- calls for heads to be chopped off and so on.

It turns out the Tower of London is open "Tuesday - Saturday 09:00 - 16:30" but "The last Yeoman Warder tour starts at 14.30" so the jury seems still to be out even in that most English patch of the English-speaking world. Meanwhile the first weekday Bakerloo train leaves Elephant & Castle at "0537", so go figure.

Jonesey and Kahastok, please add all the baseball and cricket units to the table, working in Gunter's chain if you can.
EEng (talk) 20:48, 11 March 2014 (UTC)

Great examples! Montanabw^(talk) 23:24, 11 March 2014 (UTC)

@Archon 2488: British-influenced West African nations seems to commonly use the 12-hour time with a point separator (e.g. "11.15pm"): GBC TV schedule (Ghana), GRTS schedule (The Gambia). French-influenced countries tend to use a 24-hour format with an 'h' (or 'H') as a separator (e.g. "23h15"): RTI (Côte d'Ivoire). In both cases, the part after the separator is in minutes, not decimal hours, as expected. —[AlanM1(talk)]— 00:53, 12 March 2014 (UTC)

I'm aware of the French "h" convention. I think the use of the period to separate hours and minutes is an older British notation, but you don't see so much of it any more in the UK (obviously, real-life usage isn't going to be so consistent, which is why I pointed to the ISO standard as a meaningful guide to international convention). Computers, for example, almost invariably use the colon. Archon 2488 (talk) 00:57, 12 March 2014 (UTC)

@ EEng

• Unfortunately we use that as a standard time notation for bus/train timetables in the UK. Bus, Firstbus, whole of UK (this one is England), Bus, Citylink, Scotland, Train, Translink, Northern Ireland.
• I have mailed the HRP webmaster to change/explain the use of the non-standard "15.30"

The ones you chose were probably 50% of the incorrect usage.

@ all
As a copyditor working on a horse article for GOCE, I would use this process:

• Is it about horses in general?

Yes, use MoS - refer to biology related horse projects for guidance on standard practices for height.

No, it's about olympic horse riding competition/steeplechasing/equine care - MoS & olympics projects discussions on horse measurement/use MoS & sports projects (horse racing) discussions/use MoS & horse riding/rearing projects for height.

As an aside, Londoners do NOT speak English ... "innit", "yeah man" and "call me a cab" are rarely used outside the "Big Smoke", where the terms "it is", "ok/sure/why not/yes/yup", and "call me a taxi" are more regularly used. Chaosdruid (talk) 23:18, 13 March 2014 (UTC)

Um, Chaosdruid, how about consulting WikiProject Equine for guidance? (smile) Hands is the default for measuring horse height across all wikipedia horse articles - biology, sport, or otherwise - and is standard in the English language unless there is some very compelling reason to measure height in some other fashion, such as, e.g. Miniature horse or something where there is a clear choice made to deviate from that standard. Montanabw^(talk) 18:50, 14 March 2014 (UTC) (interesting about London - "init" is also slang in a lot of northwestern US Native American communities too!)

It isn't slang. It is dialect. There is no reason to denigrate the diversity of our language. RGloucester — ☎ 19:16, 14 March 2014 (UTC)

You sir, are a cab! All the best, Rich Farmbrough, 22:35, 6 April 2014 (UTC).

Do not use words

Why not add something about not naming decades in just words, as in the sixties? This is not my last name (talk) 16:31, 2 April 2014 (UTC)

Do you mean we shouldn't refer to the period from the years from 60 through 69 as the sixties? Or were you thinking of 1960 through 1969? Do you intend to just prohibit "the sixties" as referring to 1960 through 1969, or maybe you also want to prohibit calling that period "the nineteen sixties"?

The current guidance is

For a social era or cultural phenomenon associated with a particular decade two digits (with a preceding apostrophe) may be used, but only if this is a well-established phrase seen in reliable sources (the Roaring '20s,  the Gay '90s,  condemnation of the '60s counterculture

I think we would apply the spirit of this guidance; if it turned out that reliable sources frequently refer to a certain social era or cultural phenomenon with number words, we should allow that usage. I think the present guidance already prohibits "the twelve twenties" if that phrase isn't already found in reliable sources. Jc3s5h (talk) 16:49, 2 April 2014 (UTC)

It's probably best to avoid such phrases at first-use, but allow them subsequently:

Pink Floyd were active from the 1960s to the 1990s; in the 60s their frontman was Syd Barrett...

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 18 April 2014 (UTC)

Revisit: the use of "×" and "x" for indicating "by" in arrays and dimensions

From recent changes in various places in MOS, and a growing use of terms such as "4 × 4", "4×4", or "1920×1080" it appears the time has come to revisit the use of "×" and "x" when substituting for "by".

My understanding of the current consensus from reading the the various MOS pages (prior to the changes made in the last 36 hours) and reading through a few of the threads in the archives on this topic is that the consensus as of the last time this was discussed was:

• "x" can be used as a substitute for "by", but only unspaced. Example: "1920x1080".
• "×" can be used as a substitute for "by", but only if units are specified, and spaces must be used. Example: "1920 pixels × 1080 pixels". The primary concern expressed was the possible confusion by a naive reader of reading "×" as multiplication.

My personal interpretation of the consensus has been that "×" is acceptable in some other situations if the use in that instance has been explicitly defined as "by". Thus, in some editing situations I have let the use of "×" stand when a naive reader could not confuse the use of "×" with multiplication. Examples:

1. Tables where the units were specified in the header but the actual text in the table did not have units (e.g. "1920 × 1200" where the header states "x (px) × y (px)".
2. The four-wheel drive article uses "4×4", instead of 4x4. The use of "4×4" is clear in that article because it is explicitly stated in the first sentence of the article that "4×4" is being used in that manner within the article.

However, my interpretation in these instances is from reading the concerns expressed in the discussions of the issue, not the actual statement of the consensus.

Some of the history of earlier discussions on this issue is contained in the following archives:

• Wikipedia talk:Manual of Style (dates and numbers)/Archive 77#How to write "four by four" (source of 4x4 example, original discussion initiated about arrays of pixels)
• Wikipedia talk:Manual of Style (dates and numbers)/Archive 100#2 by 4 inches (50 mm × 100 mm)
• Wikipedia talk:Manual of Style/Archive 108#Letter X vs. multiplication sign (very brief)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 138#Two by five chains is no furlong
• Wikipedia talk:Manual of Style (dates and numbers)/Archive 120#Proposal: Delete guideline that bans "70 × 90 cm" and mandates "70 cm × 90 cm"
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 134#5.7×28mm
• Wikipedia talk:Manual of Style/Archive 97#Common mathematical symbols: spacing (tangential)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 143#Width first or height for screen sizes? And inches again.. (tangential)
• Wikipedia talk:Manual of Style (dates and numbers)/Archive 24#Seventh attempt at a revised wording for the 'Units' section (brief on this issue, but first use)

I believe I recall reading at least one more longer discussion which I am just not finding right now. Search seems less effective than it used to be, or my search-fu is low.

The problems are (at least):

• We have a significant number of articles which now use the "1920×1080", "1920 × 1080", and "1920 × 1080 pixel" formats.
• We have some editors who prefer the "1920×1080" format, and some who prefer the "1920x1080" format. There have been times when articles have been changed back and forth between formats. It would be nice to have a bit more clarity.

The formats we currently have as acceptable are:

1. "1920x1080"
2. "1920 pixels × 1080 pixels"
3. "1920 by 1080" (if no actual units), "1920 by 1080 pixels", and "1920 pixels by 1080 pixels"

Do we want to add additional acceptable formats? If so, which ones? — Makyen (talk) 13:07, 12 March 2014 (UTC)

Personally I'd gravitate towards using "x" (e.g. "1920x1080"), as display resolutions are not mathematical formulae (so WP:⋅ doesn't really apply). The pixel counts are generally not given for the purposes of multiplication, and are almost universally pronounced with "by", so "x" seems more appropriate. I'm not necessarily opposed to using × either, but it seems to me like the extra requirements for it (spaced and accompanied by a unit) would introduce extra maintenance overhead, whereas most people (especially novice editors) don't need to read guidelines to be able to correctly write "1920x1080".

So long as consistency within each article is maintained and change for the sake of change (like some recent edits) is discouraged, I'd be fine with sticking with the currently accepted formats as listed above. Indrek (talk) 13:31, 12 March 2014 (UTC)

I would prefer "×" in all cases. Although "1920 pixels × 1080 pixels" is not generally seen as a mathematical calculation, in essence, it is one: it describes a display consisting of 2,073,600 pixels, which is calculated by multiplying the numbers. That's what the symbol represents. It has no semantic meaning related to the letter "x"; it just happens that the graphic representations of these characters are so similar that "x" is commonly used for "×" (also because the former is easier to type), but strictly speaking, "×" is the correct symbol. It should be spaced, too, as with mathematical equations. —sroc 💬 15:54, 12 March 2014 (UTC)

Agreed. "x" should only be used because you don't have font support for "×". It can be difficult to read, for one thing: "1920x1080" looks like one long number in my display font. Whenever I come across "x" I correct it, just as I correct double hyphens used as a shortcut for dashes. — kwami (talk) 22:02, 12 March 2014 (UTC)

Agreeing with sroc and kwami. Disagreeing with Makyen's examples (more in the edit history and user talk page) and I don't believe the MOS or consensus supports them.

However, to better guide good faith users such as Makyen in interpreting the MOS I suggest we add clarification in the following four areas:

1) An example should point out that statements such as "1920 × 1080" re display resolutions do in fact imply multiplication whether you are interested in calculating the resulting total number or not, therefore "×" is the correct symbol.

2) There must be nothing to confuse editors to believe that just because something is pronounced "by" there is no multiplication and therefore somehow letter "x" would be ok. The unfortunate "4x4" drivetrain example has had that effect. If that example is to survive, we may need to emphasize its word "may" and its restriction "common terms".

3) Regarding units, I believe "1920 × 1080 pixels" is correct and in fact preferable to "1920 pixels × 1080 pixels". I don't consider it analogous to examples such as "2 in × 4 in" because a pixel is an inherently two-dimensional physical entity and its counts in a graphics array are simple dimensionless numbers which therefore themselves don't have units.

I suggest we avoid unreasonable interpretations of the MOS's statement that "[w]hen the multiplication sign is used, each number should be followed by a unit name or symbol" by adding something like "unless a number indicates a simple count (which is dimensionless, i.e. inherently has no unit)" and at least one example such as:

* "The multiplication table says 5 × 5 = 25"

* "She walked 7 km 12 times. Therefore she walked 12 × 7 km = 84 km"

* "The display uses pixels arranged in an array of 1920 columns and 1080 rows. The display resolution can be calculated with the formula: 1920 × 1080 pixels = 2,073,600 pixels (around 2 megapixels)"

* "Each tile measures 2 ft × 2 ft = 4 sq ft. If you arrange them in a 2 × 3  rectangle you cover 2 × 3 × 4 sq ft = 24 sq ft"

4) Re spaces surrounding "×", I personally believe they should be used where they make formulae more readable but they shouldn't be strictly required. They should be optional in a compact context such as "The LCD shows 2×16 characters of 8×8 pixels". (And a minor benefit is not risking editors forget to use nonbreaking spaces.) I do however agree that spaces should be explicitly forbidden if the unfortunate "4x4" drive train example is to remain because otherwise they would break that up so that it is no longer a "common term", but we may need clarification that that is not to be read as to use the letter "x" if you don't want to use spaces, which someone may have beleived.WinTakeAll (talk) 00:25, 13 March 2014 (UTC)

Agreed, except that I would use much simpler examples:

"a 1080×720-pixel screen",

"a 2×3 rectangle" (or "two-by-three rectangle").

As for mandating multiple tokens of the unit, consider {{val}}, which departs from ISO standards by not repeating the unit. That template is used in physics and astronomy articles, where you might expect people to get uptight about units. We even had a big argument over an unrelated issue that focused a good amount of attention on how it formats numbers and units. At 4 Vesta, for example, we give the dimensions as

(572.6 × 557.2 × 446.4) ± 0.2 km.

If a little common sense is okay there, it should be okay here.

We might want to think about the spacing a bit. Spacing is clearly beneficial to legibility in equations and examples like Vesta. However, when used attributively, they become a problem, because we can't use hyphens and it starts getting confusing where the attributive phrase begins. Imagine:

? "a 2 × 3 rectangle" [Seems like an oversimplification. Would need expansion e.g. to "a 2 × 3 rectangle of tiles" to point out there are no units of length. -WinTakeAll]

? "a 1080 × 720-pixel screen" (or should that be "a 1080 × 720–pixel screen" with an en dash?)

That is, "4×4" without spaces is equivalent to "four-by-four" with hyphens: Both strategies bind the phrase together so that it's obvious what is modifying what. — kwami (talk) 00:39, 13 March 2014 (UTC)

Multiple comments here have demonstrated one of the reasons I have serious concerns about the use of "×" in these abbreviated formats. The concern is that when "×" is used multiple possible interpretations exist for the text. Even sophisticated readers have an increased tendency to conflate the possible meanings being represented. Multiple people above have stated that "1920 pixels * 1080 pixels display" is also talking about multiplication. It is most certainly not talking about multiplication (an action), it is talking about display containing a 2 dimensional, rectangular array of pixels (an object). The fact that you can use multiplication (action) to determine another property of the array, the total number of pixels, is just how it works, but the multiplication (action) and the array (object) are two very separate things. Overloading the use of "×" for "by" blurs that distinction. It is quite possible to be talking about one and not the other. In fact, I believe it to be much more prevalent to be talking only about one interpretation rather than both at the same time. Using "×" in both manners adds ambiguity when doing so is just not needed and the added ambiguity makes it inappropriate.

My personal opinion is:

• Neither "x" nor "×" should be generally used in this manner in prose, or where space is not at a premium. Using a spaced "×" instead of "by" saves all of one character. The cost of the ambiguity is not worth it. "By" should be used in almost all cases.
• The use of whatever abbreviated format(s) we decide upon should be considered for use only:

• In locations where space is at a premium. For example, some tables.
• When a large number of such objects are being referred to throughout the text. The use of an alternate format can make the text flow and read smoother in some cases.

As to formats: I tend to use an unspaced "x", mostly out of long habit. However, having thought about it quite a bit, I prefer the unspaced "x" because it leaves no ambiguity as to what is being referred. "1920x1080" is not confused with multiplication. Is it the best possible solution? No. It would be nice if there was a specific character which had as its only use to mean the separation of two numeric values in the description of an array or dimension. Unfortunately, there is not such a character.

I agree that "1920x1080" does not visually separate the numbers as well as "1920×1080" does. I just don't think that the extra visual appeal of "1920×1080" justifies the potential ambiguity introduced by the use of the "×" character. In situations where the format has been clearly stated to be representing something other than multiplication, I do not have a problem with it. My original post has two examples of that type of situation. The problem is that we are defining a style that will be used throughout the English Wikipedia. We can not control each instance where a format will be used to be sure that the writer has provided enough extra explanatory material to make it clear as to what is being represented by a format that has multiple potential interpretations, which are often all reasonably valid interpretations of the text when read by a naive reader.

@WinTakeAll: As to your arguments wrt. my misinterpretation of what MOS currently states and the consensus behind those words: I believe you are wrong. I suggest that you actually read the discussions linked in the original post to see the discussion which went on to form the current consensus. While you do so, I would hope that you set aside your current point of view and try to understand the conversations without bias. My point of view is that you have made statements in various places that directly contradict the very explicit text and examples contained on the MOS pages, and you have tried to make changes to those pages because they do not say what you want them to. However, continuing a discussion as to my, your, or anyone's understanding of the current consensus is not as productive a use of our time as might be possible. We have begun a discussion from which will, hopefully, arise a consensus which we can use moving forward until such time as it is appropriate to revisit it again.

— Makyen (talk) 02:19, 13 March 2014 (UTC)

To sum up: Does anyone share Makyen's POV that "1920x1080" is preferable to "1920×1080" for reasons of disambiguation? I don't.

Can we remove the "4x4" drive train example used to promote letter "x" for other cases of "m-by-n"? After all, the consensus on its page is clearly to write it "4×4", never mind that it is quite a confused term on its own. -WinTakeAll (talk) 06:57, 13 March 2014 (UTC)

I agree that for disambiguation purposes the letter "x" is a better choice, and disagree with User:WinTakeAll that multiplication is the implied purpose of listing pixel counts. Yes, the total number of pixels can be useful, depending on the context, but in such cases it is always given explicitly, in appropriate units (e.g. megapixels), precisely because readers are not meant to multiply the pixel counts themselves.

If you think about it, dividing the pixel counts is just as useful an operation as multiplication (to determine the aspect ratio), but that doesn't mean we should start writing resolutions as "1920/1080" or "1920÷1080".

I don't think that readability is much of an issue with common fonts. Maybe if the letter "x" was uppercase ("1920X1080"), but a lowercase "x" is a pretty clear delimiter.

As for the "4x4" example, are we sure it refers to the type of drivetrain? I was sure I read somewhere (possibly by User:Makyen) that it was originally meant to describe pixel arrays. Even if the example does refer to a drivetrain, then I think it should stay and the article be updated instead, because in that case there is even less reason to use the multiplication sign than with display resolutions, because the result of the multiplication (16) is not even a useful number (a 4x4 car does not have 16 wheels). See also Tractor unit, which uses "x" to describe drivetrain configurations.

Indrek (talk) 07:34, 13 March 2014 (UTC)

Thanks for your comments. I believe they are wrong on the following points:

"disambiguation purposes": There is no disambiguation because "x" and "×" are used all over the place to mean the same—multiplication. However the former is not supported by MOS since it is incorrect. (Although it is a tolerated approximation in cases outside of WP where "×" is unavailable, such as US ASCII constrained text files or old mechanical typewriters.)

"disagree with ... that multiplication is the implied purpose of listing pixel counts": It is, because the definition of a pixel based device's resolution is tied to its total count of pixels. A pixel resolution is considered higher than another if it has a higher total count of pixels, which you get to by multiplying.

"total number of pixels can be useful ... but in such cases it is always given explicitly ... (e.g. megapixels): It is very often not given explicitly. There are countless examples such "the new model's resolution is quadrupled—from 320×480 to 640×960"

"dividing the pixel counts is just as useful ... as multiplication": Dividing is not useful for specifying resolution; it is however useful for specifying aspect ratios but that is beyond the scope of this discussion. "1280×800" is not the same resolution as "1440×900" just because they share the same aspect ratio of 1.6.

"don't think that readability is much of an issue with common fonts": It is. "×" visibly separates numbers much better than "x" in every font because it is positioned differently and uses a different line stroke than numbers. Particularly valuable in fonts with text figures such as Georgia, WP's standard example font (part of Core fonts for the Web), cf. 32x24 vs 32×24. But even if the "x" or any other symbol did happen to better separate the numbers, I wouldn't use that to justify an incorrect notation.

"are we sure it refers to the type of drivetrain": Yes we are because that's where the editor has linked it and because of the mention of "common terms such as 4x4". The myriads of resolutions out there aren't common terms, and a tiny resolution of 4×4 pixels would have been a poor choice of one to use as an example. -WinTakeAll (talk) 08:51, 13 March 2014 (UTC)

There is no disambiguation because "x" and "×" are used all over the place to mean the same—multiplication. That is clearly not the case, as the "four-by-four" example demonstrates. There is ambiguity, which should be resolved by not using the multiplication sign where multiplication is not intended. The main issue, then, is whether or not multiplication is intended when describing display resolutions (or pixel-based devices in general).

It is, because the definition of a pixel based device's resolution is tied to its total count of pixels. Incorrect. The resolution of a pixel-based device is defined by the number of distinct pixels in each dimension (see display resolution), not the total pixel count. For instance, 480x250 and 400x300 are distinct resolutions, despite having the same total pixel count (120000). Ditto for 1600x768 vs. 1280x960, and probably more.

Dividing is not useful for specifying resolution I didn't say it was, I simply said that it was useful, period. We shouldn't assume that multiplying the pixel counts is the default operation when division is just as useful and common (arguably even more common, at least with display devices). My point was that "1920x1080" doesn't (and shouldn't) specify a mathematical operation of 1920 × 1080 anymore that it specifies a mathematical operation of 1920 ÷ 1080.

It is. "×" visibly separates numbers much better than "x" in every font because it is positionened higher than numbers. Oh, I agree that "×" is a slightly better separator. What I was saying was that "x" is good enough.

Yes we are because that's where the editor has linked it and because of the mention of "common terms such as 4x4". Fair enough, I guess. The rest of my point still stands, though, with regards to not using the multiplication sign in that particular case.

Indrek (talk) 09:56, 13 March 2014 (UTC)

The original discussion in which the 4x4 example was generated is the first link I provided to the history of this discussion. The first sentence, written by SandyGeorgia includes "...we find: Sprites can be 8x8, 16x16, 32x32, or 64x64 pixels, ... is that correct and is it covered?" The "4x4" example comes into the thread slightly later and is unspecified as to its intended meaning. However, the paragraph in which it is located talks mainly about wood (e.g. 2x4, 4x6).

@WinTakeAll: Your logic that the fact "4x4" is linked to the Four-wheel drive article is proof that "4x4" is supposed to mean "drive train" in this instance is flawed. Among other flaws, it rests on the assumption that text "4x4" was linked by the original editor to the Four-wheel drive. People add links to articles all the time; often just because that person thinks of an association, not because the specific text actually is intended to mean what is then linked to. The text "4x4" was originally entered on 30 July 2007. It existed on the project page not linked for 6.5 years until linked 2 days ago on 11 March 2014 by EEng. So, yes, to EEng, who is also the person who changed the wording to "conventional terms" from "terms", the text "4x4" is associated with drive trains. However, using similar logic to yours, then the converse must be true and the fact that it was not linked for 6.5 years – throughout which time the 4x4 redirect page did exist and could have been linked – means that it it was certainly not intended to mean drive trains, or at least not to be limited to that.

@WinTakeAll: Two requests: First, please do not put new comments within other people's posts on the same line as their text. It borders on editing the posts of someone else which is seriously frowned upon. Second, please do not edit your own posts, even to make grammar or spelling corrections, after they have been replied to by others without indicating that the post has been changed. While the changes you made to your own post(s) here were not that significant, you have made such changes more extensively elsewhere. There are some good reasons to edit your own posts. WP:REDACT has a list of such reasons, and suggestions how to make such edits. I would suggest you read all of WP:TALK.

Prior to this conversation, I was almost ambivalent as to possibly changing over to using "×". This conversation has convinced me that its use as a separator in text describing two dimensional rectangular arrays helps generate confusion which is significantly more widespread than I previously believed. It is clear that this confusion exists and is detrimental. In order to reduce this confusion, I would strongly prefer to not use "×" at all for this purpose (perhaps continuing its use in the fully spaced and with both units version). The additional cost of, at most, 3 characters per instance to use the full, spaced "1920 by 1080" format is trivial when compared to the ambiguity introduced, and increased confusion generated by the use of "×" for this purpose. This cost of 3 characters assumes the the unspaced "x" format is eventually deemed unacceptable, if it is acceptable, then the benefit of using "×" is either one to three characters, or slightly enhanced readability. None of those benefits outweighs the cost in ambiguity and confusion. — Makyen (talk) 11:24, 13 March 2014 (UTC)

• For what it's worth, I prefer "×" in all cases on Wikipedia. The "x" is shorthand for "×" in contexts where it cannot be generated (typewriters, marquees, ads where the "×", even if available, would be misread by the typesetter, etc.). The ambiguity is minimal. In other words: Unspaced "x" represents unspaced "×"; it's acceptable for entry, but should be repoaced by bot. Spaced "x" is unacceptable. Spaced or unspaced "×" is acceptable. Spaced "by" is usually acceptable. I would like to see evidence than anyone except Makyen is confused. — Arthur Rubin (talk) 18:24, 13 March 2014 (UTC)

• It's worth noting that "x" is widely used for specifying resolutions of pixel-based devices outside of Wikipedia - tech news and reviews, spec sheets for displays and image sensors, and so on. In many of those cases I don't think the argument that "×" is unavailable or inconvenient holds water, as similar special symbols (e.g. superscript numbers or non-Latin letters) are also used. The fact seems to be that "x" is acceptable in a lot of contexts, it isn't just "shorthand that should be replaced". I'm not saying that Wikipedia necessarily needs to follow the herd, so to speak, but at the very least I think it allows us to discard any remaining concerns about the legibility of "x" as a separator, given the wide variety of fonts and text sizes it's been used in, apparently with no problems whatsoever. Indrek (talk) 09:37, 14 March 2014 (UTC)

• @Sroc: "Anyway, the argument that we could easily use "m÷n pixels" because it can be useful (in determining aspect ratio) is invalid because that's not how people specify resolution (which is the intended meaning of "m×n pixels" in the real world)." (Responding here because the below subsection where you posted this is hopelessly derailed.) I wasn't actually suggesting that we should write resolutions using the division sign (indeed, I explicitly stated that this shouldn't be done), I was just pointing out that just because we can multiply the numbers doesn't mean we must use the multiplication sign. In fact, by your own logic, we shouldn't use the multiplication sign, because "that's not how people specify resolution" - the most commonly used symbol is the lowercase letter "x". Yes, you can argue that "x" is just a convenient shorthand for "×" (debatable), but at the very most that's an argument for using "×", not against using "x". Personally, I would argue that "x" is shorthand for "by" and there are cases where it doesn't necessarily mean multiplication. Drivetrain configurations like the oft-mentioned "4x4" are a good example (clearly a 4x4 vehicle does not have 4 × 4 wheels), and I see no reason why resolutions of pixel-based devices couldn't also be considered such. After all, as I've explained above, resolution is defined by pixel counts in each dimension, not their product. In other words, it's the individual numbers that matter, and the primary purpose of the symbol between them is to visually separate the numbers (of which "x" is doing a good enough job). Any mathematical operations that the symbol might imply and that might yield a useful result are of secondary importance at best. Indrek (talk) 21:58, 14 March 2014 (UTC)

• See also Wiktionary where the applicable definition (13) of "by" is "Used to separate dimensions when describing the size of something" (emphasis mine). TheFreeDictionary and Dictionary.com also give essentially the same definition (12b and 18, respectively), and distinguish this use from mathematical operations like multiplication and division. Resolutions are read with simply "by", e.g. "nineteen-twenty by ten-eighty", not "nineteen-twenty multiplied by ten-eighty". Indrek (talk) 22:07, 14 March 2014 (UTC)

@Indrek: "Yes, you can argue that 'x' is just a convenient shorthand for '×' (debatable), but at the very most that's an argument for using '×', not against using 'x'." That is, in fact, what I argued. It is evident that "×" is the correct symbol in cases of "m × n pixels" and "4 × 4" because it is derived from the concept of multiplication, even if it is not directly advising the reader to multiply the numbers. Indeed, Multiplication sign#Uses states:

In mathematics, the symbol × (read as times or multiplied by) is primarily used to denote the

• Multiplication of two numbers
• Cross product of two vectors
• Cartesian product of two sets
• Geometric dimension of an object, such as noting that a room is 10 feet × 12 feet in area, where it is usually read as "by" (for example: "10 feet by 12 feet")
• Dimensions of a matrix

Conversely, I have yet to see any argument that the letter "x" has any semantic or etymological relation to such uses, other that the glpyhs looking similar. I have read no cogent argument why "x" is preferable to "×" other than being easier to type.

Similarly, Merriam-Webster's definition of "by" states:

10 —used as a function word in multiplication, in division, and in measurements <divide a by b> <multiply 10 by 4> <a room 15 feet by 20 feet>

Thus, it is clear that the "by" in "m by n pixels" and "4 by 4" is indeed related to multiplication and that measurement dimensions are treated in the same way as multiplication. —sroc 💬 04:44, 15 March 2014 (UTC)

"Thus, it is clear that the "by" in "m by n pixels" and "4 by 4" is indeed related to multiplication and that measurement dimensions are treated in the same way as multiplication." I've explained multiple times that the "by" in terms like "four-by-four" is in fact not related to multiplication. If you disagree, kindly explain in what way is the product of that multiplication (4 × 4 = 16) related to four-wheel-drive. Likewise, a 6x4 tractor unit is supposed to have 24 of what, exactly?

Also, we have two sources distinguishing use for array dimensions from use for multiplication/division, one source not distinguishing them, and one not even mentioning multiplication/division. I wouldn't exactly call that situation "clear". But thanks for the Merriam-Webster link.

As for reasons to prefer (or at least allow) "x"? A) It's what people actually use to denote resolutions (an important consideration, by your own admission); B) it's just as easy to read as "×"; and C) it's not subject to the same strict requirements as "×" (which needs to be spaced and each number followed by a unit). And yes, of course that it's easier to type. To clarify, as far as resolutions are concerned, I'm not arguing that "×" is incorrect and should be forbidden. It was primarily Makyen who expressed concerns about using "×", and that's a subject I'd like to see addressed in a bit more detail. But those concerns notwithstanding, my opinion (as I've stated above) is that both "x" and "×" are OK, so long as consistency within each article is maintained. Getting the ambiguities in the various MOS pages cleared up would also be nice. Indrek (talk) 08:17, 15 March 2014 (UTC)

Regarding 6x4 tractors and such, I think that this represents an evolution in language. Originally, "by" was used for dimensions, in rooms, lumber, arrays and probably other things where it made sense to multiply the numbers to get an area (square feet or square yards, etc.) or number of elements (arrays). As time passed and the use of "x", and later "×" to mean "(multiply) by", became solidly embedded in the language, only then did newer uses (multiplied-by) to describe the number of drive axles or drive wheels on tractors came into use. I'd be interested to know when this usage for drive-wheels started. Wbm1058 (talk) 14:02, 15 March 2014 (UTC)

No one gives a shit

This is a typical Talk:MOS waste of time and brainpower. In nailing a 2x4 or driving a 4x4 an alphabetic x is just fine—everyone knows what it means and how it would be read out, because these are conventional ways for writing such things. Trying to legislate such usage away is spitting in the wind, and is just another opportunity for editors to busy themselves making trivial "corrections" all over the place while tsk-tsking at people who actually dare to contribute content prior to crowding their brains MOS' minute hyperprescriptions.

Other than that I will only say that no one's going to be confused or misled by any of these formats, nor is there any grammatical or mathematical blunder, by which WP's reputation might be besmirched, to be avoided here. Arguing about whether a mathematical operation is implied is ridiculous. The choice of format is a matter of aesthetics, and it matters little if different articles adopt different formats, though each article should be internally consistent. The endash-emdash (or is it endash–emdash?) guideline (WP:EMDASH) is the right analogy here.

The problem with these conversations is that they are so bloated, relative to the importance of the issue at hand, that all are dissuaded from participating except obsessed zealots, who after endless arguing come up with some convoluted prescription everyone else ignores. No one gives a shit.

EEng (talk) 14:56, 13 March 2014 (UTC)

Modifying final comment: I should have said No one else (i.e. other than the obsessed zealots) gives a shit. EEng (talk) 19:04, 19 April 2014 (UTC)

Please don't use bad language. My view is that the use of the proper mathematical symbol should be maximised. Apart from other reasons expressed above, it looks better. Tony (talk) 15:07, 13 March 2014 (UTC)

Please don't fuss about "good" or "bad" language. You seem to recognize that this question is, at least to a large degree, just a matter of taste, so I say again that WP:EMDASH is the right model. EEng (talk) 15:27, 13 March 2014 (UTC)

@EEng: The thing is, you clearly "give a shit". If you did not care significantly about this then you would not have changed the wording on the project page from "terms" to "conventional terms" and made the change bold. It is ridiculous to harangue other people in the manner you have done above when your intentional actions – not just a copy & paste – clearly indicate that you have a stake in this issue. — Makyen (talk) 01:12, 14 March 2014 (UTC)

I inserted conventional to clarify the use of alphabetic x in writing names of things which are, well, conventionally spoken as "something-by-something" -- two-by-four lumber, three-by-five file cards, etc., which I thought was the intention of the guideline. I added the bold because -- as even a brief review of the edit history will show -- I've been bolding key phrases systematically, throughout the page, to make it easier for editors to locate the guideline on any particular point. That you are able to infuse such innocent changes with dark and malignant motives adds to the impression of paranoid alarmism warned of by Wbm1058 below. EEng (talk) 04:49, 14 March 2014 (UTC)

EEng, I have never thought you have had dark and malignant motives. I don't believe anyone around here has dark and malignant motives. I have thought, multiple times, the work you've done is excellent and that you have put in a huge amount of time and effort, which has been less than fully appreciated.

If the specific changes at issue had not been used as the basis of, and reason for, propagating changes by others elsewhere, or used as the basis for arguments (above), I would have had no problem with them. Frankly, I did not think about those changes much until WinTakeAll started using the exact wording and emphasis (linking) as a basis for arguments (above, and on my talk page). I certainly did not, and do not, believe you had any motive beyond improving Wikipedia. My mentioning that the changes had been made recently was not intended to have anything to do with it being you that had made the changes, only that the changes were recent, days, and had not had enough time pass to indicate that they were so firmly a part of the consensus that the details changed should be used as the basis for arguing that other changes should be made. [NOTE: exactly such an argument was made above (the meaning of "4x4" being linked), and the argument accepted by another editor.]

Frankly, my assumption had been that the changes you made were basically for the reasons you detail above – bolding for convenience, etc. – and that they were not intended to change the meaning. My issue was not with you or your changes. My issue was with someone else using the specific details in your changes, which had been made with no intent to change meaning, as the basis for arguments.

Perhaps I should not have mention you by name as the editor who happened to make those changes. At the time, I did state you as the author of the changes because I did not feel it appropriate to reference the change without giving attribution.

Reading parts of what I wrote over again, it does appear that my tendency to be overly verbose led to too much text indicating you as the contributor. It should have been trimmed prior to saving. I also realize now, that I used you as the subject in a rhetorical argument intended to show the fallacies in the original argument based on the fact that "4x4" was linked. I'm sorry about doing so. I should have kept your name out of any involvement in that.

On the other hand, I did feel your statement that begins this section, and your titling the section "No one gives a shit" was beyond what was appropriate in its tone, although I understand the sentiment. Perhaps my reaction above to the tone of both of those was a bit strong, and for that I apologize. — Makyen (talk) 09:11, 14 March 2014 (UTC)

And I apologize as well, but you gotta compress your posts or people are going to judge you, in advance, as crazy -- TLDR. I suggest you take a long break, then start over with a simple, short-as-possible post. EEng (talk) 12:50, 14 March 2014 (UTC)

@EEng: As you suggested, I have taken a month-long break from this discussion. I will attempt to make my responses less verbose to meet your, and others, concepts of what a response should be. However, I would suggest that you allow more variation into your preconceived notions of what a response should be in order to accommodate a wider variety of writing styles on on the part of other editors. — Makyen (talk) 00:25, 19 April 2014 (UTC)

Even in expressing future personal resolve, appertaining to determination to eschew excessively verbose expression of technical opinions/positions, the prior writer (just above, ultimate to this missive) nonetheless achieves and managemes to addenduate in a manner unappreciable moderated in prior-mentioned verbosity.

It's not a preconceived notion, Makyen. It's a postconceived notion, borne of years of WP discussion: people won't read long, overwrought arguments about minor issues. EEng (talk) 02:05, 19 April 2014 (UTC)

Nice 8-).

@EEng:, there is a big difference between saying "people won't read it" and "judging you as crazy". I understand there is a issue with respect to "people won't read it". We all have a point where we just don't read something because it is too long.

However, I was talking about the point at which you were "judging [someone] as crazy". There is a wide variation in how people express themselves. I was suggesting that you not prejudge someone as "crazy" based on the length of their posts at quite the point you implied.

I am going to try to make my posts shorter. I hope I will be successful, and that it helps. — Makyen (talk) 05:00, 19 April 2014 (UTC)

@Makyen: For what it's worth, I don't have a problem with reading longer posts. And, I suspect, neither do many others who have managed to participate in this discussion without resorting to expletives and childish histrionics. If that makes me an obsessed zealot, then so be it. I'd encourage you to leave this particular subsection alone so that those who profess not to give a shit can continue to do so without the distraction of other editors trying to reach a consensus. Indrek (talk) 13:03, 20 April 2014 (UTC)

The problem is that, while the great silent majority don't give a shit about what x is used, they do give a shit about being clubbed over the head later by the zealot-developed micromanagement provision insisting that this trivial thing be done some particular way -- we care about not have one more thing to worry about. Some things are too trivial to warrant a long discussion and resulting rule. As with endash-emdash, in-article consistency is enough. EEng (talk) 15:27, 20 April 2014 (UTC)

The problem is ... being clubbed over the head later by the zealot-developed micromanagement provision insisting that this trivial thing be done some particular way No, the problem is joining the discussion with a preconceived notion regarding its end result and then berating people for it.

That aside, if it's your opinion that in-article consistency is enough and no rules prescribing the use of one symbol over another are necessary or even desirable (a position I agree with, BTW), then please, feel free to voice that opinion in the #Change proposal section. Be sure to mention the great silent majority, because the small vocal minority in that section currently seem to favour "insisting that this trivial thing be done some particular way". Hope to hear from you there. Indrek (talk) 16:25, 20 April 2014 (UTC)

I am in the same line as EEng. Clear wording notwithstanding. FeatherPluma (talk) 01:15, 14 March 2014 (UTC)

• I give a shit. ISO provides good, authoritative guidance on style and there is no reason to go against it in WP's house style. × is ×. Not x. Tony (talk) 07:45, 19 April 2014 (UTC)

As I said earlier: The problem with these conversations is that they are so bloated, relative to the importance of the issue at hand, that all are dissuaded from participating except obsessed zealots, who after endless arguing come up with some convoluted prescription everyone else ignores. No one [else] gives a shit. If I may say, my crystal ball has told truly. And see my next comment immediately below. EEng (talk) 19:04, 19 April 2014 (UTC)

• I give a shit. ISO provides good, authoritative guidance on style and there is no reason to go against it in WP's house style. 1 MB is 10⁶ B. Not 1024² B. Dondervogel 2 (talk) 16:35, 19 April 2014 (UTC)

What could prove my point (just above) better than that, apparently, Dondervogel has so lost his way, in this miasmic labyrinth, that he thinks we're discussing that perennial thorn, the Mega-means-what conundrum. Sorry, D, wrong section -- this is the when-is-an-x-not-an-x inquisition. EEng (talk) 19:04, 19 April 2014 (UTC)

You have completely missed my point, which was perhaps not clearly made, so let me repeat the same point with less cryptic language. ISO Standards, without exception, follow a peer review process out of which they must emerge with the support of a broad consensus of experts. Without that broad support they do not see the light of day. This is completely the opposite with Wikipedia, which can be (and is) edited by all and sundry. That's not a bad thing - on the contrary, it is WP's great strength - but it is something that mosnum should bear in mind very carefully every time an ignoramus chooses to knock the advice of ISO. I am not saying that WP should follow all ISO standards blindly, because not all ISO standards are applicable. But when there is an applicable ISO standard, there needs to be a very clear and broad consensus on WP to *not* follow that standard. I do not see that clear and broad consensus here, and that is why I support Tony's point of view. Dondervogel 2 (talk) 12:14, 20 April 2014 (UTC)

You mean like the ignoramuses (ignorami?) at ANSI describing here [7] how they decide the extent to which they do/don't use ISO material in their own standards. Even ISO itself ([8] - "Are standards mandatory") says modestly, "A number of ISO standards - mainly those concerned with health, safety or the environment - have been adopted in some countries as part of their regulatory framework, or are referred to in legislation..." -- hardly evidence that all but the ignorant adopt ISO standards unquestioningly. You're sure you understand we're talking about what x to use, right, not the color codes on the nuclear power plant emergency switches? EEng (talk) 15:16, 20 April 2014 (UTC)

ISO is not in a position to mandate any of its standards. Only legislators can do that. I am not advocating the unquestioning adoption of any standard. What mosnum can (and should) do is adopt ISO standards where appropriate, and not otherwise. Of course ISO standards should be questioned. If having questioned them they are considered suitable, that is when they should be followed. What is a sign of ignorance is not to adopt or not adopt, but to so (either way) unquestioningly. Dondervogel 2 (talk) 15:40, 20 April 2014 (UTC)

You said there better be a broad consensus if we're not gonna follow ISO -- so ISO is the default? As someone said, let's drop this line of inquiry, but please, think about CREEP. Is this really a problem that needs fixing? That's a rhetorical question -- please don't answer. EEng (talk) 16:03, 20 April 2014 (UTC)

Disagree with Makyen, the originator of this discussion

• "Even sophisticated readers have an increased tendency to conflate the possible meanings being represented. Multiple people above have stated that "1920 pixels * 1080 pixels display" is also talking about multiplication. It is most certainly not talking about multiplication (an action), it is talking about display containing a 2 dimensional, rectangular array of pixels (an object). The fact that you can use multiplication (action) to determine another property of the array, the total number of pixels, is just how it works, but the multiplication (action) and the array (object) are two very separate things. Overloading the use of "×" for "by" blurs that distinction. It is quite possible to be talking about one and not the other. In fact, I believe it to be much more prevalent to be talking only about one interpretation rather than both at the same time. Using "×" in both manners adds ambiguity when doing so is just not needed and the added ambiguity makes it inappropriate." Please. You have taken something relatively simple, that I thought even most "Randys" understood, and just twisted it up so much that my mind is spinning. You're insisting on creating a significant and important distinction where no relevant or material distinction actually exists.
• Does "1920 pixels by 1080 pixels" mean "1920 pixels in close proximity to 1080 pixels, as in "by" meaning nearby? Wouldn't using an × avoid that confusion?
• The unspaced "x" indeed leaves no ambiguity as to what is being referred. "1920x1080" is not confused with multiplication. 1920x1080 is clearly a model number (and the next generation of that product has model number 1920y1080).
• I do not believe that your interpretation of the only three currently acceptable formats is correct. Perhaps all three of your examples may be acceptable, but none of them are ideal in certain contexts and usage.
• If you push on this issue too hard, you risk gaining a reputation similar Apteva's regarding hyphens and dashes, where "Hyphens can be used for initial entry of any of the above, and replacement with a more precise form may be done by other subsequent editors. Disrupting Wikipedia to constantly complain about the consensus for the more precise forms can be annoying." Here I might say that "by" and "x" may be used for initial entry of array dimensions, and replacement with "×" may be done by other subsequent editors. Disrupting Wikipedia to constantly complain about the consensus for "×" can be annoying. – Wbm1058 (talk) 16:20, 13 March 2014 (UTC)

• Is the "by" in "4×4" or "2×4" etymologically derived from "multiplied by"? Anyway, the argument that we could easily use "m÷n pixels" because it can be useful (in determining aspect ratio) is invalid because that's not how people specify resolution (which is the intended meaning of "m×n pixels" in the real world).

If a preference is to be stated, it should be for "×" over "x". It is a matter for consensus to determine whether both forms should be permitted, although I note that MOS:MINUS (the link is currently broken) [link fixed] requires that − be used rather than a hyphen or en dash, which is nothing new although there are good reasons for this which were previously stated and have recently been deleted. —sroc 💬 22:27, 13 March 2014 (UTC)

I started this discussion because I desired we end up with the project page not explicitly excluding text that has become common on article pages. Currently, the project page explicitly excludes using the symbol "×" to specify dimensions without using units on all numbers. It says so very explicitly and gives examples of wrong ways of writing dimensions. I routinely see editors entering such text, and some editors specifically going through articles changing them to using such text.

Frankly, I did not care if the issue of pages using formats explicitly not permitted was resolved by changing the project page, or by changing the text on article pages. EEng made a change in February to the text on the project page from "Dimensions may be given using the" to "Length-width-height–type dimensions may use the" which at least opens up the possibility of arguing that the specification is only to apply when three dimensions are given. NOTE: I don't recall seeing any discussion on the talk page regarding limiting the guideline on dimensions to only "Length-width-height–type dimensions". From what I recall from looking at the archives, such limitation was certainly not part of the original consensus.

In my initial post, I attempted to be neutral to the issue, and only describe what discussions had gone before and what the project page explicitly states. My goal was, and is, to engender discussion on the issue and eventually reach a consensus.

However, when two of the first four people to respond to the thread effectively said that describing an array was multiplication, I started to be concerned. Describing an array and multiplication are two very different things. Multiplication can be used to determine properties of the array, but it is not the array itself. I don't know if the use of the multiplication symbol to separate the dimensions of the array is contributing to this impression on their, and probably other peoples, part or not. However, it does seem like it would contribute to the lack of distinction between the object and the action which has been expressed above. The hope of not having the distinction between these two become even more blurred for more people is what has me leaning in the direction of being against using "×" as a separator in describing dimensions/arrays.

I interpret a variety of comments from other editors to indicate that they believe I am rabidly for using "x" over "×". I am not. I am not sure what has given that impression. Do I personally use, "x" over "×"? Yes. Do I, now, think that using "×" has potential negative consequences that outweighs the visual benefit from using it? Yes. Am I rabidly one way, or the other? No.

@Wbm1058: Your making the statement: "Disrupting Wikipedia to constantly complain about the consensus for "×" can be annoying" and putting it in a section that has a heading title with my user name implies that you believe I am disrupting Wikipedia when talking about consensus. I don't believe that I am, or have ever, disrupted Wikipedia. If you could point out some specific examples where I have disrupted Wikipedia so I can see where that is the case and modify my behavior, I would appreciate it. If there are actually any such cases, I would prefer that you do so on my talk page rather than here, but if you feel it more appropriate to do do so here, then go ahead. I really am not sure to what you are referring, and I would like to know. Is it that you have an issue with my being conscientious enough to take the time to find, and read, the old discussions so I could get an idea about what consensus was actually reached in prior discussions rather than blindly assuming I know exactly what was intended from looking at very little information?

WP:CONS says "Consensus refers to the primary way decisions are made on Wikipedia". Let's all try to continue this process of forming a new consensus without straying into arguments which begin to border on personal attacks. — Makyen (talk) 03:12, 14 March 2014 (UTC)

I didn't occur to me that anyone would be idiotic enough to interpret the phrase Length-width-height–type dimensions as excluding e.g. length-width-depth or length-width (only) or similar things. Again, your rabid hysteria is beginning to sound really crazy. Anyway, I've added further examples for the avoidance of doubt. EEng (talk) 04:49, 14 March 2014 (UTC)

(edit conflict)When a couple of editors I respect say what I am doing is "disruptive", or "rabid hysteria" which is sounding "really crazy" it is certainly time for me to step back and try to figure out what it is I am doing which is objectionable. I will do so.

Prior to doing so, I feel I should try to correct what appears to be a significant error on my part:

EEng, I agree, it did not naturally occur to me that someone would believe the phase Length-width-height–type dimensions was intended to restrict the guideline.

The comments with respect to 2D vs 3D notation were not intended to be public, and are poorly written. They should have been deleted prior to saving. They follow a thought experiment trying to figure out some hypothetical other person's thought process. It is not an argument I was putting forward myself. The thought experiment was prompted by having just re-read the argument put forward (above) by WinTakeAll that the dimension guideline should not apply to pixel dimensions because "a pixel is an inherently two-dimensional physical entity".

Given that argument was ... something I had not previously considered, I was attempting a thought experiment to see if I could come up with some other argument I had not previously considered. Because that text was not intended to be public and potentially imputes another editor, I have struck it out. As it has been quoted and commented upon by a third editor, I understand the situation to be such that it is no longer appropriate for me to strike out that text. — Makyen (talk) 22:25, 14 March 2014 (UTC)

1. I started this discussion because I desired we end up with the project page not explicitly excluding text that has become common on article pages. OK
2. Currently, the project page explicitly excludes using the symbol "×" to specify dimensions without using units on all numbers. It says so very explicitly and gives examples of wrong ways of writing dimensions. I routinely see editors entering such text, and some editors specifically going through articles changing them to using such text. Frankly, I did not care if the issue of pages using formats explicitly not permitted was resolved by changing the project page, or by changing the text on article pages. EEng made a change in February to the text on the project page from "Dimensions may be given using the" to "Length-width-height–type dimensions may use the" which at least opens up the possibility of arguing that the specification is only to apply when three dimensions are given. NOTE: I don't recall seeing any discussion on the talk page regarding limiting the guideline on dimensions to only "Length-width-height–type dimensions". From what I recall from looking at the archives, such limitation was certainly not part of the original consensus. Thankyou for bringing this to my attention, but this is off-topic for this section.
3. In my initial post, I attempted to be neutral to the issue, and only describe what discussions had gone before and what the project page explicitly states. My goal was, and is, to engender discussion on the issue and eventually reach a consensus. An admirable goal. Describing what the project page explicitly states is at best difficult, when it is being changed so often. Over 400 edits so far this year... Four hundred edits in 2 1⁄2 months! This is supposed to be a guideline, how can anyone respect a guideline that is not itself being respected? Where is the respect for {{MoS-guideline}}? Please ensure that any edits to this page reflect consensus. I do see that Makyen has been pretty good in this regard, and that this excessive guideline editing is mostly by others. Some of these edits may be OK and uncontroversial, but Makyen's point #2 above is certainly cause for concern.
4. However, when two of the first four people to respond to the thread effectively said that describing an array was multiplication, I started to be concerned. Describing an array and multiplication are two very different things. Multiplication can be used to determine properties of the array, but it is not the array itself. I don't know if the use of the multiplication symbol to separate the dimensions of the array is contributing to this impression on their, and probably other peoples, part or not. However, it does seem like it would contribute to the lack of distinction between the object and the action which has been expressed above. The hope of not having the distinction between these two become even more blurred for more people is what has me leaning in the direction of being against using "×" as a separator in describing dimensions/arrays. I interpret a variety of comments from other editors to indicate that they believe I am rabidly for using "x" over "×". I am not. I am not sure what has given that impression. Do I personally use, "x" over "×"? Yes. Do I, now, think that using "×" has potential negative consequences that outweighs the visual benefit from using it? Yes. Am I rabidly one way, or the other? No.
   1. An array (definition) is a systematic arrangement of objects, usually in rows and columns. What we are discussing here is more specifically usage of the term in programming: Any of various data structures designed to hold multiple elements of the same type; especially, a data structure that holds these elements in adjacent memory locations so that they may be retrieved using numeric indices. And a particular application of arrays: pixel arrays as described in the article on display resolution.
   2. "Describing an array" is not multiplication. I don't think anyone claimed that it was.
   3. "Describing an array and multiplication are two very different things." What's the point of this point? Describing a steering wheel and measuring its diameter are two "very different things". Describing a steering wheel and identifying its RGB color are two "very different things". Describing a steering wheel and driving are two "very different things". Describing a steering wheel and the planet Mars are two really different things. So what?
   4. Multiplication can be used to determine properties of the array, but it is not the array itself. This can be better restated as "Multiplication can be used to determine the number of array elements, but it is not the array itself." And the RGB color model can be used to describe the color of a steering wheel, but is not the steering wheel itself.
   5. The use of the multiplication symbol to separate the dimensions of an array is not contributing to any false impressions, such as "multiplication is an array", "an object is an action". Do you have any evidence that it is? The use of the multiplication symbol to separate the dimensions of an array is, hopefully, contributing to the correct impression that the dimensions may be multiplied together to determine the number of array elements, and by describing that particular property of the array, is also helping to describe the array itself. The multiplication symbol is not commanding the reader to multiply the numbers together. But, this argument for preferring the letter x over the symbol × is a nonstarter because the letter x is used as a proxy for the symbol for multiplication. Otherwise, array dimensions would be described as "1920 ex 1080" rather than "1920 by 1080". It's used as a proxy by people who don't know how to enter the symbol on their keyboards, among other reasons. "By" can generally be considered to be shorthand for "multiplied by", although there are notable exceptions like four-wheel-drive vehicles. If I say that a room is 10 × 12 feet, is there any confusion about what I mean? The room is 120 square feet in size, and if it was a 10 foot × 12 yard room, I would have said so. Mixing dimensions in that way is not generally done.
   6. The impression that you are "rabid" (your word, not mine) is fostered by:
      1. The time and effort you have "required" me to put in to make a serious and thoughtful response to your last post to this thread. I hope you are not trolling me.
      2. Your edits to Display resolution and other related articles which are overturning a defacto consensus, if not one that has been explicitly stated in this guideline, neither is there consensus for not using the × symbol in these articles. The sheer number of articles using the symbol should have alerted you to the idea that changing it would be at least potentially controversial.
5. @Wbm1058: Your making the statement: "Disrupting Wikipedia to constantly complain about the consensus for "×" can be annoying" and putting it in a section that has a heading title with my user name implies that you believe I am disrupting Wikipedia when talking about consensus. I don't believe that I am, or have ever, disrupted Wikipedia. If you could point out some specific examples where I have disrupted Wikipedia so I can see where that is the case and modify my behavior, I would appreciate it. If there are actually any such cases, I would prefer that you do so on my talk page rather than here, but if you feel it more appropriate to do do so here, then go ahead. I really am not sure to what you are referring, and I would like to know. Is it that you have an issue with my being conscientious enough to take the time to find, and read, the old discussions so I could get an idea about what consensus was actually reached in prior discussions rather than blindly assuming I know exactly what was intended from looking at very little information? WP:CONS says "Consensus refers to the primary way decisions are made on Wikipedia". Let's all try to continue this process of forming a new consensus without straying into arguments which begin to border on personal attacks. Sorry, maybe I could have said this better. I am annoyed that I have spent so much time here composing this reply, that could have been spent doing something more productive. This last point of mine may be premature; it's only intended as advice or maybe a warning, not as an attack. There should be some actual proposed change to the guideline text put up for a !vote, which supports the symbol × as the preferred method for describing array dimensions. I can't fault you for disrupting a consensus that doesn't yet formally exist, and I guess you're not the only editor here I can find fault with. Wbm1058 (talk) 19:55, 14 March 2014 (UTC)

• Wiktionary lists thirteen meanings of the word (preposition) by, and the meaning we are discussing here is listed last. Yet somehow readers know the correct meaning from the context in which "by" is used. I think the same is true of both symbols "x" and "×". Wbm1058 (talk) 03:48, 15 March 2014 (UTC)

@Wbm1058: That is not the point. Some people use spaced hyphens - like this - or sometimes even without consistent spacing- for example, like this- to separate a parenthetic remark. Most readers will understand what was intended, even though what they really should use is a dash. We have MOS:EMDASH, which says to either use an unspaced em dash—like this—or a spaced en dash – like this – to achieve the same thing. It is understandable that sometimes editors will use hyphens instead, but these should be replaced when we find them to bring Wikipedia up to standard by using the correct punctuation. Why shouldn't "x" → "×" be treated the same way? Even if people understand "x", the only reason it has become commonplace is because it is easier to type than "×", and the trend is towards replacing "x" with "×" (as shown in the Ngrams below). —sroc 💬 00:39, 16 March 2014 (UTC)

I agree with you. The point I was making was in response to the contention that some readers understand "x" to mean "by" but think that "×" always means "multiply" and never means "by". I think such readers are extremely rare, and that most would figure out whether "by" or "multiply" was the intended meaning based on the context of usage, just as when they see "by" they are able to tell from the context of the use which of "by"'s 13 meanings was intended – even though it may be the least frequently occurring of the thirteen. Wbm1058 (talk) 03:06, 16 March 2014 (UTC)

Oh, yes, absolutely agree. —sroc 💬 03:16, 16 March 2014 (UTC)

Disagree. Reasons for preferring (or at least not forbidding) "x" other than that it's easier to type have been given. And the Ngram data, while fun to look at, is far from conclusive. For one, in several examples usage of "x" is also growing in popularity, and secondly, the data ends in 2008. Also, at least as far as I can see, Ngram only counts usage in printed media, but not online usage. Conversely, what good reasons are there for replacing "x" with "×" other than that they look similar? Indrek (talk) 09:54, 16 March 2014 (UTC)

Reasons why "×" is preferable to "x" have been given, namely, that "×" (the multiplication symbol) is semantically related to the inherent meaning whereas "x" (the letter) is not. —sroc 💬 13:02, 16 March 2014 (UTC)

What is the semantic relation between "×" and the word "by" in terms like "four-by-four"?

What is the semantic relation between "×" and the word "by" when listing display resolutions (e.g. "nineteen-twenty by ten-eighty")? Personally, I've seen people use a variety of other symbols, like "-", "/" and "*". It's not nearly as common as "x" or "×", and I'm not saying we should allow all of those on Wikipedia, but I think it supports the point I've made above, that the exact symbol used is of secondary importance, so long as it helps visually separate the two numbers that define a specific resolution. If both "×" and "x" satisfy that criterion, why not allow both? Indrek (talk) 14:02, 16 March 2014 (UTC)

I would be repeating myself. —sroc 💬 14:30, 16 March 2014 (UTC)

Not if you were to actually respond to my counterarguments, but of course I can't force you to do that. Indrek (talk) 16:05, 16 March 2014 (UTC)

Before I could answer that question, I would need to understand what a semantic relation is. The Wikipedia link seems to veer off into a computer science topic. Wbm1058 (talk) 16:23, 16 March 2014 (UTC)

I see that wikt:semantic relation is more helpful: "Any relationship between two or more words based on the meaning of the words." Is "×" a word, or is it a symbol? Can symbols have semantic relationships? Wbm1058 (talk) 18:17, 16 March 2014 (UTC)

Very simply put, two things can be said to be semantically related to each other when they mean the same (or similar) thing. As symbols can have meanings, they can also have semantic relationships.

As I understand it, sroc is saying that the word "by" in phrases like "four by four" and "nineteen-twenty by ten-eighty" means "multiplied by", and therefore the correct symbol to use is "×", because it also means "multiplied by".

I'm saying that (s)he is wrong on both counts. In "four by four", the "by" means something like "out of", as in "four wheels out of four being driven by the engine". See Four-wheel drive#Terminology and Tractor unit#Axle configuration for more on this usage. As for display resolutions and similar cases, I rather like Dictionary.com's definition (18) "having an adjoining side of". Neither case has any semantic relation to multiplication. Indrek (talk) 18:48, 16 March 2014 (UTC)

@Indrek: My take on this, repeating what I posted above, with one word (in boldface) added: Regarding 6x4 tractors and such, I think that this represents an evolution in language. Originally, "by" was used for dimensions, in rooms, lumber, arrays and probably other things where it made sense to multiply the numbers to get an area (square feet or square yards, etc.) or number of elements (arrays). As time passed and the use of "x", and later "×" to mean "(multiply) by", became solidly embedded in the language, only then did newer uses (multiplieddriven-by) to describe the number of drive axles or drive wheels on tractors came into use. I'd be interested to know when this usage for drive-wheels started. Perhaps there was a similar evolution with room measurements. At first "by" always meant "multiply" when the measurements were used to calculate the area of the room. Later, the "having an adjoining side of" interpretation comes in when people use the term by without bothering to do the actual calculation. One could also interpret "by" to mean "near to or next to", i.e., the east wall is next to the south wall. So the semantic relation may be more indirect, but it is still there. I think that room measurements in this regard are an apt analogy for array dimensions, which is the usage that prompted this whole discussion. – Wbm1058 (talk) 14:12, 17 March 2014 (UTC)

Interesting hypothesis. Of course, it's just as possible that "x" was originally used in this context completely independently of its similarity to the multiplication sign (especially since multiplication is also commonly denoted with the middle dot, which bears no resemblance to the letter "x"). This image, from Four-wheel drive#Terminology, clearly uses the letter "x", although it's of course anyone's guess whether or not the multiplication sign would have been possible. In any case, it's not inconceivable that, in a slightly ironic twist, "×" came to be used in such contexts due to its similarity to "x". Indrek (talk) 12:55, 30 March 2014 (UTC)

We should not prescribe or require usage of one over another when clearly both forms "x" and "×" are commonly used. We should not call for replacing "x" and/or "×" with "by" when the spelled out word is less commonly used than either symbol. This big discussion started because an editor was replacing "×" with "x" or "by". What good reasons are there for that? I would just call for consistency of usage within individual articles, possibly enhanced by explanation of the conventions used in the article before or with the first usage, where explanation is needed. My preference is to defer to the content creator's usage, when that usage is a matter of taste and there is nothing inherently wrong with it. There is certainly enough stuff on Wikipedia that is flat-out wrong to keep any editor busy forever fixing errors. I don't want to see "style police" annoying content creators by "fixing" things that are not incorrect, but rather are just a matter of taste. Maybe consensus can be formed for more specific usages in some content areas, but I don't see a consensus forming project-wide. Maybe the only guideline here should be "be consistent within an article, and don't fix what's not broken". Wbm1058 (talk) 14:33, 16 March 2014 (UTC)

Agreed, although I would still like Makyen expand upon his/her original concerns regarding the use of "×". Indrek (talk) 16:05, 16 March 2014 (UTC)

I also agree, and to resonate let me repeat part of what I posted earlier:

No one's going to be confused or misled by any of these formats, nor is there any grammatical or mathematical blunder, by which WP's reputation might be besmirched, to be avoided here. Arguing about whether a mathematical operation is implied is ridiculous. The choice of format is a matter of aesthetics, and it matters little if different articles adopt different formats, though each article should be internally consistent. The endash-emdash (or is it endash–emdash?) guideline (WP:EMDASH) is the right analogy here.

EEng (talk) 19:40, 16 March 2014 (UTC)

@Indrek: My concerns arose as a result of the first few responses to this discussion. The fact that two of the first 4 responses (here and here) to the original thread argued that multiplication was inherent in specifying dimensions. The argument that multiplication is inherent in representing an array has been expanded upon (above) and restated by at least one additional editor (below). It has also been argued that the "fact" that it is inherent is cause to use "×" instead of "x".

I strongly disagree that multiplication is inherent in the specification of dimensions or arrays. It is a property of the object described by the dimensions that area or volume can be determined by multiplication. It is a property of the array object that the number of items in the array can be determined by multiplication. I believe that most people here agree with that. I view it as a misconception that multiplication is inherent in the representation. While I do not feel that representation with "×" causes this misconception on the part of at least some editors, using "×" probably contributes to the misconception.

When initiating this conversation, my expectation was that we would eventually agree to permit both some version of "×" without units and unspaced "x". In addition, that a rule similar to WP:RETAIN or WP:DATERET would be used to retain the format used by the first major contributor. — Makyen (talk) 00:25, 19 April 2014 (UTC)

Google Ngram Viewer

Take a look at this chart in the Google Ngram Viewer. It makes it pretty clear where the trend is headed. In another five or ten years this won't be controversial anymore. "4 by 4" can also refer to lumber used in construction. I'm guessing that use of that type of lumber became widespread in the years around World War I, the good old days when there was still lots of old-growth forest around. Houses were built more solidly back then, just my opinion. Wbm1058 (talk) 02:15, 15 March 2014 (UTC)

Another example here, this one for VGA, another one that Makyen took retro at the beginning of this year. Again, the trend is clear. 1024 × 768 (XGA), Full HD (1080p), and Ultra high definition television 3,840×2,160. Sigh. The Google data needs updated. They only go to 2008. Try graphing other resolutions if you like. Warning, I've heard that this could be addictive. Wbm1058 (talk) 03:05, 15 March 2014 (UTC)

Interesting charts, to be sure. Of course, they paint a somewhat different picture once you add in unspaced "x": 4x4, FHD, XGA etc. Also, WUXGA and SXGA+.

You're right about one thing, though - it is addictive :) Indrek (talk) 08:31, 15 March 2014 (UTC)

Hey, that's not fair! I added a couple more terms to your 4×4 chart, see here. This compares "4 x 4" with "4x4" and clearly shows that the unspaced version has become the dominant usage. But it shows identical lines for "4 × 4" and "4×4": "Replaced 4×4 with 4 × 4 to match how we processed the books". How do we get "4×4" to work, is there a special syntax we can use to show that one? Wbm1058 (talk) 14:30, 15 March 2014 (UTC)

How do we get "4×4" to work, is there a special syntax we can use to show that one? I don't think you need to do anything special. From what I understand, Google considers "4×4" and "4 × 4" the same, and the graph shows usage for both. Indrek (talk) 14:55, 15 March 2014 (UTC)

Maybe you're right. I found the documentation here. "Try enclosing the phrase in square brackets". Using square brackets it says "Ngrams not found: 4×4, [4×4]" (I needed to re-click "Search lots of books" to get that message). So, it appears that in 2008, unspaced "x" was the dominant usage. What we don't know is how that might have changed in the last five years, although "×" was gaining on it, we don't know whether it has caught up yet. – Wbm1058 (talk) 15:33, 15 March 2014 (UTC)

Invalid conclusion, unfortunately. Books digitized by scanning and OCR will almost always have recognized × as x. Thus Google ngrams deny that "× Fatshedera" occurs (where × is the biological hybrid symbol), but it's easy to find botanical or gardening books digitized by Google where the image shows that the symbol is × not x, such as this. If you search inside this book for "×" the response is that it doesn't occur. Only books which were originally digital (and thus recent) are likely to have the correct symbol. Peter coxhead (talk) 14:57, 16 March 2014 (UTC)

Interesting, I was not aware of this usage. So what does × Fatshedera lizei mean? "By Fatshedera lizei", "multiply Fatshedera lizei", "times Fatshedera lizei" or something else? I have no clue, and the article should explain what the "×" means. Very odd to see it there. Wbm1058 (talk) 15:32, 16 March 2014 (UTC)

Duh. Read the article. The hybrid symbol ×... Give myself a trout. In biology, the multiplication sign is used in a botanical hybrid name, where it is read as "cross". Wbm1058 (talk) 15:42, 16 March 2014 (UTC)

Look it up in Wiktionary: wikt:cross: amongst twenty definitions: (biology) An animal or plant produced by crossbreeding or cross-fertilization.;(by extension) A hybrid of any kind. Wbm1058 (talk) 16:10, 16 March 2014 (UTC)

Yes, I think you're right. Use of × in publishing did not begin in the digital publishing era. Typesetters have been able to use special symbols for a long time, longer than computers – indeed before computers as we know them even existed. Take a look at Peter Norton's first book, the classic Inside the IBM PC. In the section titled Technical information (page x) he says, "My primary IBM/PC, on which this book was written," and on page 175, he just uses an "x": "In high-resolution graphics, there are 640 x 200, or 128,000, pixels." The publisher just took what he typed on his PC and printed that as-is. But by the time his "pink shirt book" was published, the publisher was doing lots of stuff to make it spiffy, including using real multiplication signs. But Google shows "x" which I know to be wrong because I have the actual book in front of me. Maybe we should call them "by signs". Where code examples show actual multiplication operations, the asterisk (*) represents multiplication, as any programmer knows. So whether "x" or "×" was used back in the day is probably more a matter of publishing budgets and schedules. Wbm1058 (talk) 17:31, 16 March 2014 (UTC)

When books were prepared by expert typesetters, my experience is that the proper symbol was generally used, as it tends to be now that authors are expected to supply digital copy. There was a time in-between when copy was prepared by typists rather than typesetters, and they naturally didn't appreciate or have access to the range of symbols available in a full font.

However, the key point remains that Google has digitized older books using OCR, and this process makes many mistakes when the source is not a word in its dictionary. (Even the title of a programming language book I wrote appears wrongly in the Google books digital version; as for code...) Somewhere lost in the archives there's a discussion in which I participated that used Google ngram evidence to determine whether "Bronte" or "Brontë" is the most common form in English. But it turns out that Google's OCR regularly loses diacritics, so the "evidence" was useless. Peter coxhead (talk) 21:31, 16 March 2014 (UTC)

Change proposal

As there have been no new comments for a while, and at least in one branch of the discussion we appear to have reached an accord, I propose to change the wording at WP:UNIT#Unit names and symbols to the following (with similar changes at WP:COMMONMATH, MOS:COMMONMATH, etc.), so we can finally wrap this up.

The unspaced letter x may be used in terms such as 1920x1080 (when describing display resolutions) or 4x4 (when referring to four-wheel drive).

Please indicate support or opposition below. Indrek (talk) 13:32, 22 March 2014 (UTC)

• Support, per discussion above, as both "×" and "x" are commonly used. Indrek (talk) 13:35, 22 March 2014 (UTC)
• Oppose. "×" is the only logical character here, and should hence be the only acceptable one. Using "x" originated from the resemblance with "×" and the ease of typing the former and difficulty typing the latter. Such things as in screen resolutions are really multiplications. A screen with "1024×768 pixels" has 1024×768 = 786432 pixels. Requiring "×" is analogous to requiring a "−" for subtraction and not allowing a hyphen ("-"). In at least many instances when people type an "x", a bot could come by and fix it to a "×", just like it comes by to fix, for example, the placement of references after interpunction. --JorisvS (talk) 13:50, 22 March 2014 (UTC)

• Please see above discussion where the relation to multiplication has already been discussed and debunked. Indrek (talk) 12:29, 30 March 2014 (UTC)

Where? --JorisvS (talk) 08:19, 1 April 2014 (UTC)

If you've the time, I recommend reading the entire current discussion from the beginning, but in short - display resolutions are defined by pixel counts in each dimension, not the total number of pixels, and the purpose of whatever symbol is used is to simply distinguish the numbers, not to imply any specific mathematical operation. Such operations (like multiplication or division) can be used to determine specific properties of the display, but not to define it, and thus saying that, quote, "Such things as in screen resolutions are really multiplications" is fallacious. Hope this helps. Indrek (talk) 08:50, 1 April 2014 (UTC)

Well, I'll comment on that by referring you to the comment below by Mikhail Ryazanov. --JorisvS (talk) 09:08, 1 April 2014 (UTC)

• Oppose. I have little objection to 4x4, but in screen resolution, it's "×", read "by". I add my comment here to indicate that it does not necessarily represent multiplication, but an alternate use of "×" in the dimensions of rectangles, rectangular cuboids, or boxes in general. — Arthur Rubin (talk) 16:33, 22 March 2014 (UTC)
• Oppose – it's best to pick a convention and stick with it consistently. Just use the muplitplication sign; there's no need to overload the "x" character. Archon 2488 (talk) 14:07, 23 March 2014 (UTC)
• Oppose. Where does the guideline give any guidance on display resolutions? If anything, we should add: "The unspaced symbol × may be used in terms such as 1920×1080 (when describing display resolutions) or 4×4 (when referring to four-wheel drive)." I don't want anything in the guidelines that supports any editor actively "fixing" 1920×1080 to read 1920x1080 and I don't believe that there was ever any consensus for that. Wbm1058 (talk) 12:38, 29 March 2014 (UTC)

• There isn't currently any guidance for use cases like display resolutions, hence this whole discussion. I agree that "fixing" from one commonly used format to another should be discouraged, but that should also include "fixing" from "x" to "×", especially since it's mostly being "fixed" to unspaced "×", which currently isn't allowed by the MOS. "1920x1080" is currently allowed, I'm simply proposing to make the wording clearer in that regard. I'm not opposed to also allowing "1920×1080" (i.e. unspaced "×"), and in fact I thought we had reached a consensus for allowing both, but in any case I don't think the very common use of "x" should be disallowed. Indrek (talk) 12:29, 30 March 2014 (UTC)

"x" is really just bad practice due to the ease of typing it compared to that of "×". "×" is really the only correct way. Though maybe technically these would need to be spaced, it appears to me that these are rather regularly unspaced, and so it would appear okay to me to explicitly allow the "×" in (screen) resolutions to be unspaced. --JorisvS (talk) 18:13, 30 March 2014 (UTC)

So you're saying that unspaced "×" is okay because it's regularly used this way? Then by the same logic, unspaced "x" should also be okay because it's also regularly used. Why exactly is something that is easy to type and gets the job done "bad practice"? Indrek (talk) 20:11, 30 March 2014 (UTC)

On a related note, if you want an example of bad practice, you need look no further than your own current behaviour of editing and reverting based on what you want the MOS to say (as opposed to what the MOS actually says right now) while the relevant discussion is still ongoing and no clear consensus has been reached. Indrek (talk) 20:14, 30 March 2014 (UTC)

• Oppose. Regarding display resolutions, "M × N pixels" is the correct notation because it actually means "M × N array of picture elements", and "M × N" is the notation for matrix dimensions (although it usually means M rows and N columns). — Mikhail Ryazanov (talk) 00:04, 1 April 2014 (UTC)

Suggestion: change now-obscure redirect {{x}} to a template that inserts "×" with (thin) unbreakable spaces, so that "1920{{x}}1080" produces a nicely formatted result. — Mikhail Ryazanov (talk) 01:07, 1 April 2014 (UTC)

Your suggestion is interesting. A couple notes:

• See Thin space. This represents an interesting compromise for the debate over whether "×" in array dimensions should be surrounded by spaces or not, and would be another step in the direction of giving Wikipedia a "professionally typeset" appearance.
• Template:x is currently a redirect to Template:Hammer, which is heavily used, so we probably shouldn't try to appropriate it. Template:× is also heavily used to serve another purpose, as is Template:by. Template:Dim (short for dimensions) is available. Template:Array is also available (not to be confused with Template:Image array). – Wbm1058 (talk) 15:27, 1 April 2014 (UTC)

I can't see why {{X}} should really be used to refer to the curling term {{Hammer}}, I looked through the history and the curling page but couldn't see why that is at all a logical, just seems they got there first... Current {{X}}s could be substituted for {{Hammer}} using AWB or a BOT, then {{X}} could be re-appropriated for ×— Preceding unsigned comment added by Jamesmcmahon0 (talk • contribs) 15:42, 1 April 2014

Looking at this more closely, I agree regarding {{Hammer}}. To see the difference between using narrow no-break spaces and normal spaces:

• 1920 × 1080 (U+202F   NARROW NO-BREAK SPACE)
• 1920 × 1080 (just using a space)

The difference is subtle, but noticeable, in Google Chrome. I could support this. – Wbm1058 (talk) 20:02, 1 April 2014 (UTC)

It has about the same appearance in FireFox and Opera. Internet Explorer 8 shows empty boxes instead of spaces. (All are running on the same system.) —PC-XT+ 01:08, 2 April 2014 (UTC)

IE is still broken?! Unbelievable... Anyway, controllable spacings can be obtained simply with style="margin: ...":

• 1920 × 1080 ( )
• 1920×1080 (3 pt)
• 1920×1080 (2 pt)
• 1920×1080 (1 pt)
• 1920×1080 (unspaced)

I'm not very familiar with English typesetting details, but, for example, Russian rules often specify 2 pt for "small" spacing. — Mikhail Ryazanov (talk) 01:19, 2 April 2014 (UTC)

That seems to be the best option. I expect {{X}} would be used more than the current redirect if this change was implemented. —PC-XT+ 06:26, 2 April 2014 (UTC)

Interesting suggestion indeed, but is it really an improvement? It's five symbols instead of one, and although all are present on the keyboard, curly braces can be a bit cumbersome to reach on many layouts. Non-breaking spaces would be desirable, yes, to prevent wrapping to two lines, but only if we don't permit unspaced "×".

BTW, IE isn't "still broken", the above examples all look fine in IE11. Indrek (talk) 06:38, 2 April 2014 (UTC)

I'm glad that IE11 finally works, :–) but I recall a discussion somewhere in the past that   should not be used in WP because of the problems with IE6, so I was surprised that IE8 has the same issue. I don't know what is the current minimal browser configuration that WP tries to support, but it should be kept in mind when implementing the template.

As for the "improvement", my suggestion was only about the spaced "×", if we decide that it is needed/required. {{x}} is easier to type and more readable than  ×  (or  × , or those with  ). The unspaced "×", of course, does not need a template. (And those who have problems reaching curly braces are perhaps suffering with WP code anyway. I suspect, they just click "Wiki markup: {{}}" in the insert panel.) — Mikhail Ryazanov (talk) 08:24, 2 April 2014 (UTC)

As far as I can tell, MOS generally requires a regular space (non-breaking recommended) between a number and a symbol (whether a unit or mathematical symbol). So allowing a thin space would constitute an exception, in which case it seems to me we might as well drop the spaces requirement altogether for cases like display resolutions. Or, to avoid having very specific exceptions in the MOS, allow unspaced "×" as an option wherever the numbers are dimensionless?

Also, I'm still of the opinion that unspaced "x" should also remain an option, if only due to it being extremely commonly used for describing resolutions. If I may make an analogy, it's similar to how the MOS currently recommends against using binary IEC prefixes for bits and bytes, even though they're "technically correct", for the reason that the majority of relevant literature uses the decimal SI prefixes. I see no reason why the same logic shouldn't also apply to "x". Indrek (talk) 19:09, 2 April 2014 (UTC)

Why? Someone who is typing and doesn't make the effort to do so correctly will do so regardless of the MoS and it will, in the Wikipedia spirit, subsequently be corrected. There is also a difference between the binary prefixes and "×": Those prefixes are not very commonly understood, but "×" is. --JorisvS (talk) 09:40, 3 April 2014 (UTC)

• Comment about "4x4". The wheel formula (or how is it called in English?) is not a mathematical formula, but a special notation, like classification of locomotives or floral formula. They have their own meanings and rules, which in this case are probably defined somewhere by ISO, SAE or other relevant organizations. There is an article in German WP (translation) with a nice illustration (and a similar article in Russian WP) but unfortunately without any references to standards.

So, I believe, this question should be dealt with in the vehicle-related MOS (if we have it) and based on available standards or other reliable sources. — Mikhail Ryazanov (talk) 12:47, 2 April 2014 (UTC)

Yes, the issue of drivetrain configurations like 4x4 has been discussed in-depth above. Personally I feel that, unlike with display resolutions, "×" should definitely not be used in such cases, precisely for the reason you point out, that it's not a mathematical operation (nor does it describe dimensions). Thanks for also mentioning locomotive wheel arrangements as a related example; I had stumbled across them earlier but lost track before I could mention them on this talk page.

In any case, the reason I didn't propose to remove "4x4" from the MOS text is twofold: first, to keep the proposal focused on display resolutions, the original topic of this discussion, and second, because there was some debate above as to whether or not that example was originally even meant to refer to four-wheel drive (Makyen pointed out that the "4x4" part was linked only recently, over 6 years after the text itself was added, and that the original discussion whence it originated also involved pixel arrays and dimensional lumber). However, if consensus can be reached here on that particular subject as well, then all the better. Indrek (talk) 19:09, 2 April 2014 (UTC)

• Comment I am fine with having more explicit examples of the use of unspaced "x". The use of an unspaced "x" as a substitute for by has been permitted for the last 6.5 years. It is only recently that the text was changed to imply a limitation on its use and the person who changed it has stated explicitly (above) that there was no intent to change the meaning. However, this proposal does not address the issue that the use of "×", without dimensions and/or unspaced, is currently not permitted. — Makyen (talk) 00:25, 19 April 2014 (UTC)

• Personally I'd be fine with permitting unspaced "×" as well. If you want to post your own proposal that incorporates that, I'd be happy to indicate support, but given the current opposition to allowing "x", I'm not sure if that would be particularly constructive right now. Indrek (talk) 16:29, 20 April 2014 (UTC)

Abbreviation of "circa"

The section on uncertain dates currently days:

use of the spaced, unitalicised form c. 1291 (or the {{circa}} template) is preferred

The former should be <abbr title="circa">c.</abbr>, or use {{abbr}}; WCAG, the ISO standard for web accessibility, recommends marking up abbreviations so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:19, 18 April 2014 (UTC)

This question arises because I wondered at Help talk:Citation Style 1/Archive 4#circa if the <abbr>...</abbr> tags are necessary in Citation Style 1 dates because they are not required at WP:DATESNO.

Does WCAG require or merely recommend?

—Trappist the monk (talk) 20:35, 18 April 2014 (UTC)

Even if it requires, are we bound to comply? In the "everyone can edit" culture of Wikipedia, insisting on adding such strange-looking markup every time anyone wants to use a simple abbreviation could significantly reduce accessibility (unless this new advanced editing tool is going to make it all transparent). W. P. Uzer (talk) 08:05, 19 April 2014 (UTC)

Expecting editors to type {{abbr}} is a non-starter. It's possible the CS1 template code could be modified to add <abbr>...</abbr> if people who have difficulty accessing Wikipedia find this helpful. Jc3s5h (talk) 10:54, 19 April 2014 (UTC)

This is a wiki. If an editor doesn't want to type out the template form, another editor (or bot) can come along afterwards and do so. While it may be possible to get Lua to detect and fix this in citation templates, the guidance above applies also to running prose and other cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 19 April 2014 (UTC)

Let's not get hung up on a minor semantic side-issue. We know that if we do not follow WCAG guidelines - the ISO international standard for web accessibility - we erect unnecessary barriers to people wanting to read our content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 19 April 2014 (UTC)

But in our particular case, that has to be balanced against the barriers we erect to people wanting to edit our content. I don't mean so much that the requirement itself would be a burden on editors (as you say, editors who don't know or don't care just won't bother), but that the additional markup clutter in the edit window (whether added by bots - which would sometimes get it wrong, probably - or by humans) makes the wikified text less legible and harder for other people to edit. W. P. Uzer (talk) 12:46, 19 April 2014 (UTC)

By default, JAWS, the most popular screen reader, doesn't do anything with <abbr> markup. Also, if the average reader doesn't know what "c." means, I'm not sure how much it would help them to find out that it stands for "circa" without elaboration. Graham87 13:24, 19 April 2014 (UTC)

As I said above, "This is a wiki. If an editor doesn't want to type out the template form, another editor (or bot) can come along afterwards and do so". Our use of templates is so ubiquitous I don't think that the introduction of confusion of editors is a likely result. At the very least, we should not be putting technical barriers in the way of editors who wish to use such markup; so that if they does it breaks other things, like COinS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 20 April 2014 (UTC)

Andy, maybe we could POS tag our code? All the best: Rich Farmbrough, 10:11, 22 April 2014 (UTC).

This is probably something that should be done by a bot. It's WP:CREEP for human editors. I guess I have no objection to mentioning that markup as the ideal way to do it, but MOS shouldn't try to "require" it. My bigger concern with that section is the demand for "c.", when "ca." is less ambiguous and probably just as common. This is actually one of my WP:IAR points when it comes to MOS; I never write "c." for circa. <shrug> (I don't force "ca." on anyone else though, like by reverting them or haranguing them on their talk pages; it's just how I write, and most of the time I never even think about it, anymore than I do about my spelling preference for center vs. centre.) This is perhaps a MOS:ABBR matter, though.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:58, 27 April 2014 (UTC)

Script-assisted conversion of Retrieved YYYY-MM-DD

Recall the September 2013 rendition

User:Walter Görlitz converts "reference date formats per WP:MOSNUM by script", with appeal to WP:STRONGNAT on my talk page (User talk:P64#See date formats). Our biography Ursula Vernon is the only instance on my watchlist today, but the editor insists over my revert (twice) and talk-page explanation that STRONGNAT imposition of DMY or YMD pertains to prose, infobox, and publication dates only (User talk:P64#See date formats).

The second iteration, following my first revert, may the most noteworthy because the edit summary concludes, "Manually fix any reference dates you don't want correct" (diff 2014-04-29 22:52).

Does anyone suggest improvement of my first revert summary, "(Undo revision 606143107 --needs revisit without scripted conversion of uniform YMD retrieved-date format)"?

My talk-page reply linked above includes notice that I will now/thereafter cite "script-assisted abuse of WP:MOSNUM" in the edit summary. "[Too] massive to undo manually", I added in the event. If I clerk correctly there were previously 16 YMD retrieval dates yesterday, and none other. Refdates were uniform on this page after November when I fixed stray YMD publication dates and DMY (there were no MDY) retrieval dates.[9]

--P64 (talk) 01:03, 1 May 2014 (UTC)

if you want to keep ISO-8601, feel free to do so, but don't be a dick and remove clear improvements to a bad date format because you don't like the script. The script is currently broken and is converting all dates, not just body dates. That should be fixed. Walter Görlitz (talk) 01:09, 1 May 2014 (UTC)

If the script is broken, it should not be used. Full stop. Resolute 01:24, 1 May 2014 (UTC)

• The guideline actually stipulates: "Dates in article references should all have the same format". This did not appear to have been the case with your version, despite what you asserted. You will note that although accessdates appear to have been consistent, there was a mixture of mdy and yyyy-mm-dd dates in the reference section. -- Ohc ^¡digame! 03:07, 1 May 2014 (UTC)

The script is broken. This diff before the script shows every accessdate is in YMD, which is perfectly acceptable under the rules. The fact that the article dates are in a different format is necessary for consistency (there's one source with just a "month year" date, so per this, using MDY or DMY for publication dates alongside YMD for accessdates works. The script should not have touched these accessdates, period. --MASEM (t) 03:22, 1 May 2014 (UTC)

Ohconfucius' claim that the guideline says "Dates in article references should all have the same format" isn't true. That character string does not appear in the guideline. The assertion "there was a mixture of mdy and yyyy-mm-dd dates in the reference section" is irrelevant; access dates are allowed to use the YYYY-MM-DD format even when the publication dates are in a different format. The publication dates are consistent among themselves, which is all that is required. Jc3s5h (talk) 03:30, 1 May 2014 (UTC)

• @Jc3s5h:My reading, and I suspect that of most people, of "Dates in article references should all have the same format" is that reference dates should all be dmy, or mdy or yyyy-mm-dd, and not a salad of more than one of them. If you read it differently, the problem may well be parsing error at your end. Of course it's relevant that publication dates on the Ursula Vernon article were in mdy whilst the access dates were in yyyy-mm-dd.
• @Masem:I was made aware of the problem with the script through this thread, and the problem has been rectified; I also notified Walter Görlitz to it an hour ago. -- Ohc ^¡digame! 03:42, 1 May 2014 (UTC)

• Yes, the problem is fixed, but I will point out there's a clear example of the mixed date format allowance on the page at MOS:DATEUNIFY, so it's hard to see what the confusion is. --MASEM (t) 03:49, 1 May 2014 (UTC)

• @Masem:I thought that was the case, but when I looked for it under format consistency – where I'd expect to find it – it said "Dates in article references should all have the same format". Should we adjust the wording? -- Ohc ^¡digame! 04:03, 1 May 2014 (UTC)

• (ec) I am not seeing where that phrase is used at all in the current version of the guideline. The section on consistency separates out the consistent of inline prose dates, publication dates, and access dates separately (along with the necessarily crossover for dmy or mdy when ymd is not used), but never says anything like what you quote. --MASEM (t) 04:09, 1 May 2014 (UTC)

The character string "Dates in article references should all have the same format" cannot be found in the guideline.

The guideline states "Publication dates in references should all use the same format." A few lines later it states "Access and archive dates in references should all use the same format – either the format used for publication dates, or yyyy-mm-dd". This is explicit permission for the access and archive dates to use a different format from the publication date, provided that different format is the YYYY-MM-DD format. Jc3s5h (talk) 04:00, 1 May 2014 (UTC)

• I stand corrected. I had permalinked my reference text to this version of the guideline from more than two years ago, so I will have to update my documentation. Apologies to all concerned. -- Ohc ^¡digame! 04:12, 1 May 2014 (UTC)

UK articles inconsistency - metric or imperial

MOS:UNITS says “In non-scientific articles relating to the United Kingdom, the main units for most quantities are metric or other internationally used units, except that: the main units for distance/length, speed and fuel consumption are miles, miles per hour, and miles per imperial gallon;” This has resulted in a recent series of edits to UK articles changing distances from metric first to imperial first. One example is at Wales, where the Lead now says “Wales has over 1,680 miles (2,700 km) of coastline …” . the preceding sentence ends by saying that Wales “… has a total area of 20,779 km² (8,023 sq mi).” So, the article's second sentence uses metric first and imperial second, while its third sentence uses imperial first and metric second. The resulting inconsistency looks rather amateurish. Any thoughts? Daicaregos (talk) 08:18, 5 May 2014 (UTC)

The editor in question is an WP:SPA dedicated to converting articles from kilometres to miles, citing (and in accordance with) this rule. The first edit citing this rule was the editor's ninth edit in total. We may draw our own conclusions.

It seems to me that there's a clear instruction to use miles for length/distance, but no clear instruction to use square kilometres for area. I'd suggest you thus use square miles for area to resolve the inconsistency.

It might be a good idea for us to consider writing square miles into the rule alongside other mile-based units for simplicity, or to use a formulation such as, use square miles for land area if necessary to avoid inconsistency - because Wales isn't the only article where this is likely to come up.

Some have in the past argued that the rule must either be a strait-jacket, to be followed unquestioningly and unthinkingly, or that we must allow total discretion, allowing mass-conversion of UK-related articles for reasons purely of personal preference. There's a more sensible middle ground, to say that the rule allows discretion where there is a genuinely good reason for it, and I believe that this applies here. Kahastok talk 09:17, 5 May 2014 (UTC)

No, we should not be using square miles for UK articles. We use miles because the road system still uses miles, but in fact most other distance measurements are in metric. If you look at this official government document[10] it uses both, but square km. first. Or this[11] from the National Statistics Agency. Or just a google search on gov.uk[12]. The guidance needs clarification, I agree, but it needs to follow UK practice and policy. The BBC uses kilometres when not discussing road distances or speed, eg [13] Even the Ordnance survey uses it for road distances[14] and for the grid on its maps.[15] Dougweller (talk) 10:46, 5 May 2014 (UTC)

We really do need to clarify this. I've just reverted a few of his edits, including Geography of England - as I've said, roads are generally discussed in miles, but not other distances, and the sources I checked were metric. Dougweller (talk) 11:30, 5 May 2014 (UTC)

The editor was also reverted on a footpath article, as these are always in metric to match the Ordnance survey national grid, we need to add that to the MOS. Dougweller (talk) 11:37, 5 May 2014 (UTC)

@Dougweller: I note that you mention in your edit summary that “UK uses sq km, not sq miles - using miles is for road distances”, with which I would not disagree. However, the relevant MOS does not specify miles should be used for road distances alone. As I said when beginning this thread - MOS:UNITS says “In non-scientific articles relating to the United Kingdom, the main units for most quantities are metric or other internationally used units, except that: the main units for distance/length, speed and fuel consumption are miles, miles per hour, and miles per imperial gallon (but area is measured in metric units, eg square kilometers)” (my emphasis). Only in relation to UK engineering-related articles does it say that road distances are given in imperial units. I would support amending the MOS to something like “In non-scientific articles relating to the United Kingdom, the main units for most quantities are metric or other internationally used units, except that: the main units for road distances, speed and fuel consumption are miles, miles per hour, and miles per imperial gallon, respectively (but area is measured in metric units, eg square kilometers)”. Daicaregos (talk) 14:53, 5 May 2014 (UTC)

Daicaregos You're right. I like your suggestion but I'd prefer to have roads in italics. Dougweller (talk) 14:57, 5 May 2014 (UTC)

I have no objections to that. Please go ahead and make the change. It can be reverted if anyone else objects. Daicaregos (talk) 15:09, 5 May 2014 (UTC)

• NO CHANGE to the guideline. Do not even try to attempt to limit distances in miles to 'roads'. RGloucester — ☎ 15:25, 5 May 2014 (UTC)
  • That's pretty aggressive. You're saying that no way will you agree to a change. And what you reverted was not about distance in miles but my clarification that this doesn't apply to area. Do you really mean that you won't discuss this? Dougweller (talk) 15:34, 5 May 2014 (UTC)

No, I mean that it has been discussed ad nauseum, and that such a change is extremely contentious, and should not be made lightly, in the manner you did so. I'm sure all the others from our previous discussion will be streaming in shortly to contest or advocate for such a change. RGloucester — ☎ 15:39, 5 May 2014 (UTC)

I tried to follow the earlier discussions but I don't recall area being discussed and it isn't mentioned in the guidelines. Ok, maybe we should avoid personal measurements right now (although my experience is metric), but things such as area, height as in height of mountains, footpaths - these aren't mentioned in the guidelines but are now metric - the Ordnance Survey has probably had a great influence on this. If we don't clarify these we just get editors like the one mentioned above. Dougweller (talk) 15:47, 5 May 2014 (UTC)

Do you really think that we should be saying that you have to drive 400 miles to cover the 500 kilometres between London and Edinburgh?

The OP made the point that it looked "rather amateurish" to mix miles in one sentence and square kilometres in the next. What you propose is a far greater level of inconsistency. Now, there's no substantive or major difference in British usage between distances measured along roads and distances measured point-to-point (which is the point of most of the exceptions we have). It is not as though this is an area where there is a genuine division in usage that we might reflect. You are proposing that Wikipedia be inconsistent, effectively for the sake of being inconsistent.

Probably worth mentioning that UK footpath signs are in miles - and not kilometres - as well. Kahastok talk 16:46, 5 May 2014 (UTC)

I invite you read this excellent and extraordinarily long discussion: Wikipedia talk:Manual of Style/Dates and numbers/Archive 142. Note in the arguments, that there many reasons specified why we do not specify a 'strait-jacket' for certain measurements, including area. RGloucester — ☎ 15:52, 5 May 2014 (UTC)

That doesn't help avoid edits like the one that sparked this discussion. Or rather it should, as area is not distance. But you re saying that area can be Imperial. The Times style guide (now 11 years old it seems) clearly says that altitude except for aircraft is to be metric - so would you agree that attempts to measure altitude in Imperial are against the style guide? I'm just trying to figure out how to judge edits like those that got us here. Dougweller (talk) 16:40, 5 May 2014 (UTC)

The point is whether there is a genuinely good reason to deviate from the rule.

Now, there are points that are not genuinely good reasons, that have been used as excuses for conversion (in fact, mass-conversion) in the past. One is personal preference. Another is alignment to the precise source used to justify a measurement (this causes inconsistency - we wouldn't do it with spelling or date format so we don't do it with units).

OTOH I would argue (in fact, I did argue in my first response) that the fact that an article uses miles in one sentence and square kilometres in the next is good reason to deviate from the rule. In the same way, if we wanted to compare a mountain height to an aircraft altitude, that would be a good reason to deviate from the rule. I have argued in the past that the fact that a Munro is defined in feet is good reason, when comparing mountains with that definition, to give the mountain height in feet.

It would be distinctly ironic if a thread started by editor (the OP) objecting to mixing miles and square kilometres from sentence to sentence resulted in that "rather amateurish" inconsistency being enshrined in policy. Kahastok talk 16:52, 5 May 2014 (UTC)

With Munros (which my wife mentioned today), height should be in both - definitely not just in feet. I don't agree with your example of deviating from the rule. We should show miles per gallon but if discussing the cost of petrol should show that in litres. And I'm sure you wouldn't want someone to be able to add a legitimate mention of miles to an article and then convert all metric measures to Imperial. It's just a fact that UK articles are going to have inconsistencies reflecting those in the real world - I think there would be very few instances when articles should be changed to avoid these. Dougweller (talk) 17:36, 5 May 2014 (UTC)

I read this, and I wonder whether we aren't actually arguing something pretty similar.

First, to be clear, all these measures should be converted into both systems. I don't think anyone objects to that? The question is then what is the "main unit". My argument about Munros is that it is surely preferable to compare 3,001 feet (914.7 m) with 3,000 feet (914.4 m), as opposed to comparing 914.7 metres (3,001 ft) with 3,000 feet (914.4 m).

I entirely agree that you shouldn't be able to add a legitimate instance of miles to an article and then convert the rest of the article to imperial. Certainly, not things like temperature, mass and so on. I agree that on UK-related articles you are going to end up with some inconsistency reflecting the real world. The point of this advice is to try and reflect the system as used, without overcomplicating matters.

The difficulty with land area is that it is measured in a unit involving miles/kilometres, so you're saying that Wales has an area of 20,779 square kilometres and a coastline length of 1,680 miles in successive sentences. Some may find this odd. If you and others involved don't see that as a problem, then by all means leave it. It's fully in line with WP:UNITS unchanged. But the premise of the OP's point was that it is a problem, and if so I don't think WP:UNITS prevents resolution. Kahastok talk 18:05, 5 May 2014 (UTC)

Sorry guys, I should have searched the archives for this. I note that the current wording is based on The Times' style guide. As the pre-paywall version says “The main aim is to avoid confusing the reader, so try not to mix the two systems [metric and imperial] in a single article.”, something seems to have been lost in translation. However, from reading previous discussions, it appears consensus on this issue may not be possible. Thank you for your responses, but, rather than spend many more hours of editors' time, perhaps it would be best all round to leave it there. Daicaregos (talk) 20:07, 5 May 2014 (UTC)

Kahastok, Daicaregos, RGloucester- so what do I do about the editor, who is now saying "It is only establishment organisations such as government agencies that use metric for land areas. General use in the population, and reflected in the press and other media, is square miles or acres. Feet would be the preferred unit of hill heights over metres too. Don't be confused or misled by what the government do - they do not reflect public opinion, but the media and press usually do. Please respect that in the articles."? What happens if he goes to List of mountains and hills of the United Kingdom and changes it because of his opinion? Dougweller (talk) 20:51, 5 May 2014 (UTC)

First thing I would do is check his edit history to determine whether s/he was in fact user DeFacto, a serial sockpuppeteer who would make exactly those arguments in exactly those terms. It may not be AGF-ing properly, but in the circumstances I would consider it appropriate. Taking a look at your edit history, I have found the quote and would note that the editor in question is already listed at that SPI.

The point I'm making is that MOSNUM shouldn't override common sense - if there's a genuinely good reason in the specific circumstances, fine. But outside those limited circumstances, it's the basic rule. What you're describing is a user that is outright rejecting MOSNUM's advice in favour of his own personal preference in the general case.

So, how would you handle it if he said he would insist on using American English in UK-related articles, because, "It is only establishment organisations such as government agencies that use British English. General use in the population, and reflected in the press and other media, is American English. "Favor" would be the preferred spelling. Don't be confused or misled by what the government do - they do not reflect public opinion, but the media and press usually do. Please respect that in the articles." It's basically the same thing. Kahastok talk 21:16, 5 May 2014 (UTC)

I agree with Kahastok. We left the rules somewhat flexible for that very reason, and you will see that there is a footnote that explains that stability is important in a dispute. Changing the guideline just causes more problems, as it will lead to straitjacket solutions for problems that are nuanced. RGloucester — ☎ 21:32, 5 May 2014 (UTC)

I've been dragged into this by editor mentioned- and am pretty irritated by his actions. My first thoughts were that it has a lot to do with the forthcoming European election and is a politic act by a Nationalist party. Looking at this page I think the guidelines are too slack- "In non-scientific articles relating to the United Kingdom,.." is too ambiguous. HMG uses metric measures for statistical purposes- OS maps are exclusively metric- the only anomally is distance on road-signs and draught beer- milk at ASDA is marked with ml first then pints. The doctor measures a child in cm and kg. Can someone tell me how you calculate the mpg of your car when petrol is sold in litres (I wanted to know- so wrote a python routine to make it possible).

Theakstons OP is sold in a 500ml bottle, while Bulmers cider comes in a 568ml bottle with no mention of pint. I think we can safely say that "In non-scientific articles relating to the United Kingdom, both the metric and imperial measurements can be expressed together but the metric measure should be included and always be written first. In articles referring solely to events pre-decimalisation, the metric measure may be omitted." I don't see a need to make exceptions for road mileage, or nautical miles. When we do use mpg- I think we should also include the l/100km figure too, (though that could come in brackets).

In 1968, I picked up a copy of an old maths Mensuration textbook from the bin. No child has been taught to calculate in furlongs, or acres or quarts and gills since then- the imperial system is a legacy system and has not been used for 45 years. WP needs to present info, in the way that allows users to see the data in the way everyone else publishes it. Users under 55 deserve to have the same access to the data, as us old fogeys.

I do enter data from old sources, so I often type up

{{convert|number|imperial|metric}}

so it appears the wrong way round. Do you think we could get convert rewritten with an extra named parameter

{{convert|number|imperial|metric|layout=invert}}

to invert the order of the markup. I can even think of a evil tweak to {{convert}} that would totally solve this problem! -- Clem Rutter (talk) 23:49, 5 May 2014 (UTC)

Do you mean disp=flip? --Boson (talk) 00:25, 6 May 2014 (UTC)

• We cannot 'safely say' anything of the sort. You are providing a bunch of WP:Original research. I'd like to standardise as much as the next fellow, but that isn't going to happen, and it doesn't match British usage. RGloucester — ☎ 01:00, 6 May 2014 (UTC)

My view is that articles relating to physical geography should be treated as science articles, and should prefer metric units (the USA is the only exception to this, because for some reason American geographers think that it's appropriate to talk in medieval units). We shouldn't fetishise road signs, because they're only one aspect of the units of measure in use in the country: as others have pointed out, official sources will generally use metric units. For comparison, MOSNUM does not require UK articles to prefer square feet or acres, although these still tend to appear in real estate advertisements. Anyway, the real reason that the DfT has not taken our road signs out of the dark ages isn't because of some mysteriously compelling argument for imperial units, or because British people suffer from a genetic disability to understand modern measurements; it's because they couldn't be bothered to pay for it, and they have admitted as much. Hardly a ringing endorsement for the use of miles (curiously, given that road signs also use yards, why does the argument not apply equally to them? The guidelines are absurdly inconsistent.) Expressing heights and weights in Ye Olde measure is just stubborn conservatism or personal preference: there is no official mandate for it (indeed, the NHS staff are instructed specifically to use metric), and it has no place in a modern encyclopedia. Archon 2488 (talk) 21:23, 6 May 2014 (UTC)

If the road signs all change to metric, then that will go a long way toward metricating people's thinking. Right now, the predominant unit of distance - largely thanks to the fact that they are used on all the road signs - is the mile, and we should be reflecting that.

It was argued above that schools don't teach imperial units any more. This is largely true. But not everything that you learn, you learn in school. It is unsurprisingly difficult to get a handle on how far (for example) 70 kilometres is without leaving the classroom. You learn it in the abstract sense, but not in any practical sense. Trying to visualise 70000 metre rules end on end does not help, nor 70 lengths of 1000 metre rules end-on-end. On the other hand, you'll have a pretty good idea of what 40 miles is if you know it's the distance into town and back twice (or whatever), and the road sign you use to measure it is in miles.

We should be in the business of using the units that people actually use - or at least our best approximation to it. Trying to create some complicated rule that is bound to be gamed (such as, use kilometres for physical geography - bearing in mind that we have had users in the past arguing that that includes all point-to-point measurements on all articles) is a bad idea. Kahastok talk 21:47, 6 May 2014 (UTC)

I think we should be clear that the current rule does not propose that furlongs, acres, quarts or gills be used as main unit on UK-related articles on Wikipedia. I'd say there's actually a pretty good case for furlongs on horse racing articles, but that's by-the-by. The cases we're dealing with are actually the cases where people under 55 will for the most part still use imperial.

At a bar, you buy beer and cider by the pint. You don't need to even be able to convert from pint to gallon to know that a pint is the amount of beer you get if you order a beer at a bar. The fact that it's the unit of sale means it makes sense for us to use it. You learn to measure your height in metres in school, but switch to feet as soon as you leave the school gates because that's what society uses and because nobody older than you will understand what 150 centimetres means. By the time you stop growing, you've grown out of measuring yourself at school, so it's all feet and inches. Ask someone their height, chances are they'll give you an answer in feet and inches, whether they're in their teens or their seventies. All the road signs are in miles, so you use miles to measure distance. You don't necessarily know how many feet there are in a mile - if you're under about 40 that's a trivia question. You don't need to know that in order to know how far the 10 miles to the nearest town is - and not have a clue what 25 kilometres is except in terms of miles or in terms of metre rulers laid end-to-end. We should reflect that. Kahastok talk 21:47, 6 May 2014 (UTC)

I understand all of that, but your criteria are not as consistent as you think. Adopting "what units people commonly talk in" is a recipe for confusion: road signs show miles, so you say we should use those, but road signs also show yards, which aren't even mentioned in MOSNUM, and they show clearances in feet and inches, ditto. Equally, in terms of "common usage", people in the UK often think about floor space in square feet and room dimensions in feet, and the size of plots of land in acres. Obviously this is not universal, and the official units in these cases are the metric ones, so it makes sense to use metric.

"You learn to measure your height in metres in school, but switch to feet as soon as you leave the school gates" Well, obviously I didn't. I never really developed a natural understanding of imperial units, because I was never taught how to use them, and because there are so many of them, each of which is in effect a separate scale to learn (the metric system has one scale for each dimension). Do people who actually paid attention in school and bothered to learn the metric system not count? Is it really your position that people can be expected to understand what it means for a bookshelf to be 150 cm tall, but not a human? If you understand what a unit means, then you understand it, regardless of whether it's measuring a human or a piece of furniture or anything else. The suggestion that people running the 100 km Transpennine Challenge have absolutely no idea how far they are running, and would need to borrow 100,000 metre sticks to work this out, is bizarre. Nobody would do that, any more than they would express a marathon as 1,661,220 inches.

If someone has no clue what "25 km" means then they are to that extent innumerate, plain and simple. Unless you're trying to argue that the UK education system teaches people to measure distances in kilometres as some sort of elaborate joke. Even when we learned about estimating dimensions in high school, it was all in metric units: 1 km is an unrealistic height for a building (which could soon change), 100 km is unrealistic for the size of a city, etc. One of our maths exam questions even had to be discounted because they accidentally used imperial measures, when it should have been metric.

My deeper question is this: if metricating the road signs would allow us to do away with miles, even though past experience with other units suggests that many people would continue to think and talk in miles, then how can we justify sticking with units like the stone, which have already been officially deprecated? What criterion would need to be satisfied for everyone to accept weighing people in kilograms instead? "Common usage" is a chimera, and it's not exactly what MOSNUM reflects, as I've tried to explain.

In short my position is that an encyclopedia should not assume so little of its readership. Archon 2488 (talk) 23:01, 6 May 2014 (UTC)

A 100 km race would never be measured in any unit other than kilometres on Wikipedia. A marathon distance would never be measured in inches on Wikipedia. Nobody is saying that a large number of people don't know what "25 km" means, but there is a difference between knowing what it means, and having an intuitive sense of how far it is. Most people, who have never needed any intuitive sense of how far 25 kilometres is or how fast 90 km/h is, will not have an intuitive sense of how far or fast they are. If the road signs change, this will pretty much inevitably also change within weeks.

I think we're in danger of rehashing old ground here. We have a consensus for the status quo, which is based roughly on an outside source that is trying to do the same job as we are. We didn't just make all this up as you seem to suggest: you demonstrate why the mention of the Times in this advice is important, because ultimately it's where this came from. If the road signs change, chances are good that other similar sources will follow. Kahastok talk 06:37, 7 May 2014 (UTC)

"If the road signs change, this will pretty much inevitably also change within weeks." You say this, but the fact that we officially switched away from imperial weights when I was a child ("metric martyrs" and all that nonsense) doesn't seem to have had any effect on the dreaded "stone". I am glad that you are reasonable enough to admit that changing the road signs would allow us to change MOSNUM (consider, even decades after switching to Celsius, we still have some people pining for Fahrenheit). This is what concerns me; official usage is ignored when it is convenient to do so, and this is exploited by the many heads of deFacto, or whatever alias he now has, going around and arguing that "government agencies may use km, but that's irrelevant". From the very beginning metrication was something that was supposed to be over, if not in a "few weeks", then pretty fast. Instead it has needlessly dragged on through my parents' lifetimes and mine. Arguing with one breath that the official abandonment of miles would allow us to demote them on Wikipedia, then in the next that we should give precedence to obsolete units such as the stone purely because some people still like to talk in them, is inconsistent, and will inevitably produce a measurement muddle, as the experience of the past 40 years of British history has conclusively shown. You are not deFacto, but you are helping to manufacture a climate of ambiguity in which he can thrive. Archon 2488 (talk) 13:44, 7 May 2014 (UTC)

DeFacto was not originally blocked was not sockpuppetry, but for pushing so hard for imperial measures that he ended up winding everyone up. The answer to the argument cited (which actually referred to land area) is surely as I said to Dougweller when he brought it up. The rule we have is pretty clear. If there is a genuinely good reason in the specific circumstances in question to do so, then sure, use common sense. But that does not mean you can just make up your own rule in the general case.

To be clear, it is not the removal of miles from road signs per se that would mean a change in rules. It's the change in British usage that would (I believe) inevitably result that would be the significant thing.

I'd note that there is wide precedent for Wikipedia preferring common usage over official usage. Most obvious is WP:COMMONNAME. Now, in this instance, we define what common usage means in the general case precisely so that it doesn't have to get re-argued from first principles every time the point comes up - we go back to the rule defined here unless specific circumstances provide a genuinely good reason to go against it. Re-arguing from first principles is effectively what the editor being cited (whom we assume to be DeFacto) here is trying to do, to try and secure a more imperial sentiment. Others do the same thing on a metric side.

I'd note in terms of imperial weights that, while British shops officially stopped selling goods by the pound about twenty years ago, Wikipedia follows that rule. All weights used for items that are sold in Britain are cited in metric. Fact remains that stones are in common use in the single instance of personal weight, so that's why we say that it should be used it.

This is going to be just us to discussing this though, I think. I don't think a consensus is likely for a change in the rules. I suggest we're probably best stopping here. Kahastok talk 20:14, 7 May 2014 (UTC)

• Comment Because of rounding errors, we need to reflect the units of our sources – and in some cases their sources, when it's obvious that they are converting from something without paying adequate attention and claiming unwarranted precision. When a distance is given as ten miles, it's not possible to convert to km without corrupting the data. Likewise, if it's given as ten km, it's not possible to convert to miles without corrupting it. We have this issue more often in the US, where for example the data for the Great Lakes is given in imperial in many sources, and so needs to be reported that way; also for a lot of NASA stuff, where despite the fact that they lost a Mars mission because of imperial measurements, they still tend to report discoveries in imperial. IMO, ENGVAR is used as an excuse for too much on WP. Where all else is equal, we should use metric, but we need to reflect our sources for any country, and that means reporting distances in Imperial China in li just as it does reporting stuff from the US or UK in miles. — kwami (talk) 05:10, 6 May 2014 (UTC)

I guess you mean US Customary, but NASA is certainly getting better at using the metric system, at least in their official publications. Anyway, science-related articles should strongly prefer the metric system, and this is not really controversial. Archon 2488 (talk) 21:23, 6 May 2014 (UTC)

(edit conflict):OR is fine on talk pages like this one. Our guidelines are often based on OR, eg WP:COMMONNAME means we research the common name for articles. Kahastok, thanks for telling me about the SPI. Looks like he is indeed a sock. Dougweller (talk) 05:16, 6 May 2014 (UTC)

It is fine for the purpose of discussion, but it does nothing to support a change in the guidelines. As far as a 'source units' proposal, that has been rejected numerous times as well. I'll place my old proposal here, in case anyone would like to take a look: User:RGloucester/units. – RGloucester — ☎ 05:48, 6 May 2014 (UTC)

Yes, I saw the problems with 'source units' and I agree. Dougweller (talk) 10:45, 6 May 2014 (UTC)

Year suffixes

It is conventional bibliographic practice that multiple works by the same author(s) in a given year are distinguished by suffixing a lower-case letter to the year. (E.g.: "Smith, 2001a". See CMS-13 §15.91, Turabian-5th §8.13.) MOS:DATEFORMAT does not recognize this form, wherefore several bots are "fixing" such dates by removing the letter. The resulting ambiguity as to which of similar sources is referred to leads to confusion for both readers and editors. I propose adding a sentence to MOS:DATEFORMAT clarifying that in references and citations a lower-case letter suffixed to the year is a valid usage, and should not be removed. Any objections? ~ J. Johnson (JJ) (talk) 21:45, 6 May 2014 (UTC)

Can you please provide a link to an example of a bot removing a valid letter from a year? Did you report the error to the bot's operator? Thanks. – Jonesey95 (talk) 23:17, 6 May 2014 (UTC)

I have a counter-proposal. Remove every word about citations from MOS and MOSNUM, and refer to WP:CITE for all citation issues. Put the bit about letter after year in Help:Citation style 1. Jc3s5h (talk) 00:11, 7 May 2014 (UTC)

  Your counter-proposal is effectively the status quo, as MOS:DATEFORMAT currently does not mention citation usage at all (except as abbreviations). And this is the problem: that the authoritative MOS:DATEFORMAT does not mention this citation specific usage, and those who correct dates, even in citations, do not (and indeed, should not) look for exceptions elsewhere.

  Examples of year suffixes being stripped. By BattyBot: here and here (reported and the bot fixed). By MOSNUMscript: here ("date formats per WP:MOSNUM by script"; not yet reported).

  I suspect AWB also does this (see second example) but I haven't checked that yet. I have a vague recollection of another bot, but off-hand don't recall which. ~ J. Johnson (JJ) (talk) 20:17, 7 May 2014 (UTC)

@J. Johnson: wrote "And this is the problem: that the authoritative MOS:DATEFORMAT does not mention this citation specific usage, and those who correct dates, even in citations, do not (and indeed, should not) look for exceptions elsewhere." [Emphasis added]]. Wikipedia has never adopted a house style for citations. Thus general-purpose policies and guidelines should not give detailed format requirements for citations. This guideline could reiterate in strategic places that it does not control citation format, but details of how dates should be formatted should be confined to the work (if any) that describes the citation style. It would inappropriate to specify that 1989a is a valid format for a year in a citation because it is not valid in some citation styles (for example, it is not valid in a Chicago Manual of Style footnote). Jc3s5h (talk) 20:49, 7 May 2014 (UTC)

Your response is quite perplexing. In the following discussion it seems you do accept the validity of a suffix (despite the impression given here). Perhaps your objection is only to where this usage is documented? I'll comment on that below. ~ J. Johnson (JJ) (talk) 20:21, 8 May 2014 (UTC)

I have modified Help:Citation_style_1#Date_range.2C_multiple_sources_in_same_year to reflect Jc3s5h's suggestion above. The text that was there at the time of the original post in this section was, to coin a phrase, out of date. (Sorry.)

I also posted a note for Ohconfucius about the MOSNUM script bug linked above. – Jonesey95 (talk) 03:15, 8 May 2014 (UTC)

Thanks to you both for fixing that. I see OhConfucius has run the script at Oso; it looks good. ~ J. Johnson (JJ) (talk) 19:22, 8 May 2014 (UTC)

• Noted. The regex was adjusted to remove the trailing letter because it gave rise to a cs1 error. I'll tweak the script accordingly to take the concern into account. -- Ohc ^¡digame! 03:30, 8 May 2014 (UTC)

Trailing lower-case letters such as the ones shown at the Help link above should not cause a CS1 date error to display. Can you give an example of such an error? We'll want to get that fixed in the citation module code. Thanks. – Jonesey95 (talk) 04:24, 8 May 2014 (UTC)

Maybe I should have said "trailing character". I can't remember what character it was, so I took a broad-brush approach assuming that all trailing characters resulted in the error message. Now my script should ignore the characters "a" through "e". Would that be enough? -- Ohc ^¡digame! 09:55, 8 May 2014 (UTC)

@Ohconfucius:Software should follow use expectations. These expectations come from documentation, which would include Help: Citation Style 1 or Chicago Manual of Style 16th ed. p. 795. None of the documentation mentions the highest letter. I would suggest allowing a-z so that we don't have rules buried in obscure places where no editor is likely to find it. (Since Chicago Manual of Style and other printed manuals are not under the control of the English Wikipedia editors, changing the documentation is not an option.) Jc3s5h (talk) 12:05, 8 May 2014 (UTC)

A single lower-case letter, a-z, should be left alone. I have also seen single upper-case letters and other variations that should be manually converted to lower-case letters. If your script removes them, a future editor will have a harder time converting them to lower-case letters that match the harv references in the article. – Jonesey95 (talk) 16:01, 8 May 2014 (UTC)

Yes, 'a-z' seems adequate, and appropriate. ~ J. Johnson (JJ) (talk) 19:29, 8 May 2014 (UTC)

Jc3s5h: possibly you accept (right?) the validity and need of suffixing a single-letter to a year (e.g., "1989a"), and your objection (above) is only to documenting this in MOS:DATEFORMAT? That this is giving "detailed format requirements for citations"? I point out that the proposed clarification goes no further than the existing and accepted "detailed format requirements" in MOS:DATEFORMAT for formatting dates, and that documenting this valid format anywhere else would constitute being "buried in [an] obscure place". While the need for such suffixes arises from citation usage, as a matter of valid date format it should be documented here. ~ J. Johnson (JJ) (talk) 20:21, 8 May 2014 (UTC)

I accept that some citation styles need the suffix (e.g., "1989a"); that would be styles where the intext citation gives the author and year, and the reader looks it up in an alphabetical list of sources (with the year used as a tie-breaker, and the letter as a secondary tie-breaker). This also applies to the short footnote template and the Harvard templates, even though the reader can click to navigate. The suffix is not needed when there are simple endnotes, or in the MLA style.

So, since some citation styes need the suffix, and bots don't inspect the article well enough to determine what citation style is in use, the bot must leave the suffix alone. This guideline should not be making statements about valid date formats in citations because there are many citation styles, so we don't know all the valid date formats and thus cannot enumerate them. The only statement that is made about citation date format is that all-numeric date formats other than YYYY-MM-DD are disallowed; if someone can find a style guide that says to give dates as 5/8/2014, save that style guide for something other than the English Wikipedia. Jc3s5h (talk) 20:34, 8 May 2014 (UTC)

So we agree that (in your words) "the bot must leave the suffix alone" — right? The problem is that well-meaning editors and bot-writers, having done due diligence as far as checking MOS:DATEFORMAT, are given no clue that a suffix is possibly valid, and should be left alone. In fact, MOS:DATEFORMAT implicitly is an enumeration of "all the valid date formats", including those used in citations, and the failure to mention this valid (in some cases) format leads to bots (and editors) not leaving it alone. Explicit mention of this case is needed here. ~ J. Johnson (JJ) (talk) 22:16, 8 May 2014 (UTC)

I believe we're all on-board with this, so I have added a comment to MOS:DATEFORMAT explicitly recognizing year suffixes. ~ J. Johnson (JJ) (talk) 19:51, 11 May 2014 (UTC)

Use £ (ambigious? with E£)? Recommend GB£?

"The pound sterling is represented by the £ symbol, with one horizontal bar. The double-barred ₤ symbol is ambiguous". Isn't the single-barreled £ also ambigious (with the Egyptiab pound)? Is there a full abbreviation for the British pound?

"Use the full abbreviation of a currency on its first appearance (e.g. A$52)". Would that be GB£, that I've never seen used? I wander shouldn the MOS then be clarified to "(e.g. A$52, GB£)"? It is the same principle, but I don't mind that we make it consistent, state explictitly that £ can only mean the British pound? That GB£ not be used?

I just wasn't sure if the British pound was the only one (non-historical). I've never seen GB£ used, but neither had I seen US$ before (just $ or USD). I would always have assumed US dollar for $ and British pound for £..

I didn't really mind: Dickson Poon "10 million GBP", just thought it should be "[[Pound sterling|£]10 million", but both seemed to be in violation of the MOS. comp.arch (talk) 20:32, 7 May 2014 (UTC)

• "10 million GBP" and "10 million USD" look odd, and are not endorsed by MOSNUM. These ought to be "$10 million" for US dollar amount and "£10 million" for the British pound. The British pound and US dollar are two of the world's leading reserve currencies, and use of the £/$ symbols is generally assumed to apply to these except where the context dictates otherwise. We would only be referring to the Egyptian pound in context of Egypt. -- Ohc ^¡digame! 03:11, 9 May 2014 (UTC)

• The "$" symbol is specific to the US. It originally was a U superimposed on an S; later the bottom of the U was dropped, so it looked like an S with two vertical lines through it; this form is still used in some fonts. Finally, the two vertical lines were combined into one. Jc3s5h (talk) 03:16, 9 May 2014 (UTC)

Jc3, you seem like an intelligent guy (or gal), so I would have expected better from you than to repeat that kind of grade-school pap. EEng (talk) 04:32, 9 May 2014 (UTC)

'£' is also used for the Gibraltar pound (one to one for the British pound) and for the obsolete Irish pound, Australian pound and Italian lira.

For the British pound, you can use the {{GBP}} and {{currency}} templates to give £10 and £10 respectively (linking being optional in both cases). I was the editor that made them display GB£, but considering that the other uses are either one-to-one with the British pound or are obsolete, I might consider changing it to just '£'. Which of course shows the benefit of using currency templates - we change the template when MOS changes and the articles are updated automatically. The Egyptian pound coudl be represented by the more commonly use LE by using {{currency|10|EGP}}, eg E£10.

'10 million USD' looks odd to you but is quite common in financial circles. For article that show only a few currencies, it is best to use the common symbol (eg £ and $ or £, NZ$ and US$) but when many currencies are shown it is better to use ISO 4217 codes (eg GBP, NZD and USD). The {{USD}}, {{NZD}} and {{currency}} templates are helpful to keep things consistent, giving US$10 and US$10 respectively.  Stepho  talk  07:03, 9 May 2014 (UTC)

Found a few more pounds:

1. Pound sterling, GBP
2. Guernsey pound, no ISO code, par with GBP
3. Jersey pound, no ISO code, par with GBP
4. Saint Helena pound, SHP, par with GBP
5. Manx pound/Isle of Man pound, no ISO code, par with GBP
6. Gibraltar pound, GIP, par with GBP
7. Egyptian pound, EGP, LE1000
8. Lebanese pound, LBP
9. South Sudanese pound, SSP
10. Sudanese pound, SDG
11. Syrian pound, SYP
12. Irish pound, IEP, obsolete
13. Australian pound, no ISO code, obsolete
14. Italian lira, ITL, obsolete
15. many other obsolete currencies are listed at Pound (currency).  Stepho  talk  11:01, 12 May 2014 (UTC)

Sounds to me like the most sensible rule is, don't disambiguate unless there's a good reason to. In this case, particularly given the point made at Pound sign that not all countries that use currencies called the pound use "£" as a symbol, that means that "£" is GBP unless there's some reason to assume that it isn't (e.g. an article about Australia in the 1950s). Readers are not going to see "£1000" on the English Wikipedia in most contexts, and conclude that its anything other than GBP. Kahastok talk 18:19, 12 May 2014 (UTC)

US$ vs $

Mojoworker and myself have a disagreement about whether the MOS should use $ or US$ in an example.

• "Since 2001 the grant has been 10,000,000 Swedish kronor ($1.4M, €1.0M, or £800k as of August 2009), not ($1,390,570, €971,673 or £848,646)."
• "Since 2001 the grant has been 10,000,000 Swedish kronor (U$1.4M, €1.0M, or £800k as of August 2009), not (U$1,390,570, €971,673 or £848,646)."

Mojoworker contends that the earlier statement in the MOS "In non-country-specific articles such as Wealth, use US dollars ($123), euros (€123), or pounds sterling (£123)" means to use only "$" and his edit comment said "in the example there is only one currency using the $ symbol". Whereas I contend that we have to think of the article as a whole, not just a single line. This article/MOS has many currencies, including A$ for the Australian dollar. He also mentioned that if we use US$ then we must also use GB£ but I will leave that to be decided in the topic above. Comments?  Stepho  talk  07:26, 10 May 2014 (UTC)

"The article" is not this MOS, but the hypothetical article in which the example sentence might appear. That article may or may not refer to other types of dollar, but it sounds more likely that it would not (since it seems to be about something going on in Sweden), so I prefer the version without the additional "US" (and "GB"). W. P. Uzer (talk) 08:07, 10 May 2014 (UTC)

Good point. However, the example sentence could also be part of an article covering grants in many countries (see Government incentives for plug-in electric vehicles for a similar example) and therefore would need to specify 'US$' instead of just '$'. My worry is that a new editor would read that single example and then use the simple '$' where 'US$' would be more appropriate. And vice-versa, my preferred example with 'US$' might be wrongly copied when a simple '$' would be better. Perhaps we need two examples, to cover both situations.  Stepho  talk  10:31, 12 May 2014 (UTC)

True, but the situation at Government incentives for plug-in electric vehicles is covered by the first bullet point of MOS:CURRENCY#Formatting). It is at least as likely that your hypothetical "new editor" would use US$ where $ is more appropriate. These style guidelines need to be taken as a whole, and the appropriate style determined from all the rules that apply. In the edit in question that I made to bullet point six, it is discussing the rule for rounding and conversion precision. The inclusion of US$ there is ambiguous at best, and confusing at least. I don't know if there's a situation not to use the bare € symbol, since I can't think of another currency using that symbol, but according to my distillation of the relevant bullet points in the currencies sections of the MOS (including WP:MOS#Currencies), the bare $ symbol (or the bare £ symbol) should be used:

1. In non-country-specific articles such as Wealth
2. In articles related entirely to EU-, UK- or US-related topics
3. In country-specific articles not related entirely to EU-, UK- or US-related topics where it is not the first occurrence (unless it would be unclear) and when there are not different currencies using the same symbol in an article, unless the currency which is meant is clear from the context

I would postulate that the majority of articles on Wikipedia fall into categories 1 and 2 and the majority of the uses of the $ or £ symbol fall into one of the three categories above (and not one of the three categories below).

US$ or GB£ would be appropriate only in comparatively limited cases:

1. In country-specific articles that are not related entirely to EU-, UK- or US-related topics and is the first occurrence of the $ or £ symbol in the article
2. In country-specific articles that are not related entirely to EU-, UK- or US-related topics and is not the first occurrence of the $ or £ symbol in the article, but which currency is meant is unclear
3. In an article with different currencies using the same symbol in an article, when the currency which is meant is not clear from the context

So, in a hypothetical situation, as W. P. Uzer pointed out, it's far more likely to be a situation where the bare $ symbol is appropriate. You can perhaps theorize that the hypothetical article in the original example is Sweden specific, but assuming it's the first occurrence of '$' is a stretch – why assume it is the first occurrence of $ but not the first occurrence of £ (when in all likelihood it would be neither)? And as W. P. Uzer pointed out the assumption of multiple $ currencies in the the hypothetical article is also unlikely.

I guess I've rambled on too long here, but the tl;dr version is that the edit in question is to the rule for rounding and conversion precision and mixing US$ with £ (or $ with GB£) has nothing to do with the conversion precision rule and only introduces ambiguity and confusion. Mojoworker (talk) 18:25, 12 May 2014 (UTC)

In case it is of interest in this discussion, I pondered the issue recently. A Russian high-speed helicopter design is in a source[16] as "Rb3.6billion ($1.3 billion) in government cash", and someone mistakenly tried to use {{convert}}. I restored the previous text (diff) with "I think WP:$ is saying to just use USD, but "US$" for such a big number seems unnecessary". The currency details would only matter for a value under perhaps $1000 (or for specific cases where an article discusses several different dollars). Johnuniq (talk) 01:11, 13 May 2014 (UTC)

Publication dates

Publication dates in references should all use the same format. Any format from the "Acceptable date formats" table above may be used; in addition formats required by the citation style being used may be used (however, all-numeric date formats other than yyyy-mm-dd must still be avoided).

Am I missing something here? How would formats required by the citation style being used be an addition? Surely we'll be sticking to one citation style for all references which should in turn ensure that all publication dates be in the same format. Jimp 10:42, 15 May 2014 (UTC)

I think the meaning is that the set of formats to chose from for publication dates consists of the formats in the "Acceptable date formats" table and the citation style being used in the article. There is an exception: if the citation style being used in the article calls for an all-numeric format such as mm/dd/yy, that is disallowed. From the set of acceptable formats, only consistent formats should be used. For example, in one article, "July 2000" and "18 May 2012" would be consistent, "18 May 2012" and "September 30, 2013" would be inconsistent. Jc3s5h (talk) 16:03, 15 May 2014 (UTC)

And what exactly would be the argument for allowing yyyy mon dd and disallowing mm/dd/yy, which seems to be what you are suggesting, if both are valid external date formats? -- Ohc ^¡digame! 07:54, 17 May 2014 (UTC)

The only numerical dates allowed are yyyy-mm-dd in references and other places where brevity is required. Numeric dates like mm/dd/yy are strictly not allowed because 01/02/03 looks like 1 Feb 2003 to most of the British Commonwealth (eg my country of Australia), 2 Jan 2003 to Americans, 3 Feb 2001 to most Asian countries when using the Julian calendar and some countries like China and Japan use 2 digit years based from recent events.  Stepho  talk  09:34, 17 May 2014 (UTC)

I'm referring to the yyyy mon dd date format as in "2014 May 17" that is supposedly according to AP style and whose authorisation has been strongly argued by Jc3s5h. -- Ohc ^¡digame! 16:03, 17 May 2014 (UTC)

@Ohconfucius:, is your question "what is the difference in the reasoning behind allowing 2014 May 17 but disallowing 11/5/14"? The difference is that 11/5/14 is ambiguous in a publication such as Wikipedia where several national varieties of English are allowed. As for "yyyy mon dd", that is not a date recommended by the AP; they would write, for example, "Feb. 14, 1987". Further, newspapers do not use in-text citations and bibliographies, so their style would have no application to Wikipedia citations. However, APA style does use a format for publication dates that differs from anything in MOSNUM: "(yyyy, month, dd)." APA style is specifically named as being acceptable for citations here. Jc3s5h (talk) 16:44, 17 May 2014 (UTC)

Correctness matters, even in examples: pressure is not mass

A table in this article groups "ppi" (= pounds per square inch) together with six units of mass under a group "Mass". Confusion about the differences between pressure and mass are frequent in school physics; Wikipedia should not advance such confusion. Pressure is not mass, even though the two are frequently confused in popular writing. I tried to solve this by introducing a schort "Pressure" section and adding two often used and correct units of pressure (Pascal and bar). EEng reverted this; for presumably good reasons. I therefore suggest removing ppi from this (examplary) list alltogether. If it can not be presented right, it should not be listed at all. Wefa (talk) 15:25, 24 May 2014 (UTC)

My edit summary [17] explained pretty well, I think, why the table isn't sliced up into a hundred tiny sections:

I see what you're trying to do, but note ea section (mass, length, etc.) includes rates, densities, etc. related to the base unit-type. This is to reduce fragmentation of tbl & to allow related units to be nearby

To allay Wefa's concern I've changed the main group names from Mass to Mass etc., from Length to Length etc. and so on. Yet I didn't change Information to Information etc. because I just don't think the difference in formality between Information and Rate of Information is worth worrying about. See what I'm saying? EEng (talk) 17:09, 24 May 2014 (UTC)

I'm confused by this question on several levels. Typically mass might be confused with weight, which is a kind of force. One might similarly confuse a load expressed (for example) in kg/m² with a pressure expressed in N/m² (i.e. pascals), but I don't understand why anyone would confuse a mass with a pressure. Weight could colloquially be expressed in kilograms or newtons; it would never be expressed in pascals. Also, nobody would refer to psi as "ppi". Archon 2488 (talk) 16:28, 25 May 2014 (UTC)

I think ppi is just a typo for psi. As for the rest, the OP is right that people sometimes say stuff like "exerted 10 pounds of pressure" and that doesn't help when they get to an environment, like physics, where precise terminology matters. EEng (talk) 17:06, 25 May 2014 (UTC)

In physics, weight is sometimes regarded as the force on an object resulting from gravity. But in weights and measures law, weight is often regarded as the mass of an object. Thus, we cannot say that weight always means force or that it is incorrect to regard weight as mass. Jc3s5h (talk) 18:15, 25 May 2014 (UTC)

The OP is not talking about mass versus force/weight, but rather force total (e.g. pounds) versus force-per-unit-area (e.g. psi).[Striking my own illogical comment] This is showing signs of becoming one of those tiresome discussions in which people try to show off their knowledge, so unless someone has something to say about what the guideline should look like, let's stop now. EEng (talk) 18:29, 25 May 2014 (UTC)

I don't think EEng knows what the original post is about: "The OP is not talking about mass versus force/weight, but rather force total (e.g. pounds) versus force-per-unit-area (e.g. psi)" is not a correct summary of the original post. Placing psi in the mass section of the table implies the unit would measure mass per square inch. But psi almost always refers to force per unit area. But there is neither a force section nor a pressure section in the table, so there is no place to put psi. Jc3s5h (talk) 18:49, 25 May 2014 (UTC)

You're absolutely right -- I somehow misremembered the OP and answered without even looking at it -- my apologies, I'm an idiot. However, this doesn't change the essential point here, which is that the table is not meant to be didactic or formal -- it's an eclectic list of units that (for some reason or another) have received MOS attention. The idea is to group them in a way that helps people find what they're looking for, as well as to group related units together, taking into account that most editors are technical laymen (or lay-women, though that sounds, somehow, not a nice thing to say). Notice the joint note on miles/mph/nautical miles.

Anyway, I've expanded the group names again to, I hope the satisfaction of all. And I repeat that we're here to discuss what the guideline should look like, so unless someone has a suggestion about that there's nothing to discuss. EEng (talk) 22:16, 25 May 2014 (UTC)

WP:SEASON

There's been lengthy discussion at Wikipedia:Featured article candidates/Kronan (ship)/archive1 regarding the relevance of WP:SEASON. Also, see follow-up discussion here and some of the debate spilling over to Talk:Mary Rose#Poor_writing. I'd like to float the question of how far it is reasonable to adhere strictly to the recommendation to not use seasonal time references. For example, is it really advisable to simply remove seasonal terms in statements like "during the spring of 1754" so that it just reads "during 1754"? How narrow should "appropriate when related to the point being made" be interpreted? To me, it seems reasonable that any seasonal activity that is apparent in the context (sailing seasons, harvests, etc). And how far is it really appropriate to assume that readers are confused about references to "winter" or "summer" in an article that is geographically limited? In an article like forestry or galley it seems very sensible to assume that unspecified seasons can be ambiguous, but does this argument really extend to early modern Scotland?

As someone who writes a lot about early modern history, I'd also like to point out that it might be appropriate if WP:SEASON showed more leeway with regards to pre-modern historical article. For example, an event in the 16th century isn't always as strictly defined as events in the 19th century on account of the sources available. This is even more true if we go back to the medieval or ancient events.

Peter ^Isotalo 06:13, 28 May 2014 (UTC)

I think we should allow for the fact that the article might be reorganize in the future, but retain references to seasons. Or, a reader might just read the section of the article the reader is interested in, rather than the whole article. The reader might not be aware that Swedish warships of that era stayed in European waters, unlike somewhat later ships of superficially similar construction that sailed all over the world. The reader might come upon a seasonal term before reading about the limited range of the ship. Thus I don't think this particular article should use seasonal references.

Does the above passage

I'd also like to point out that it might be appropriate if WP:SEASON showed more leeway with regards to pre-modern historical article. For example, an event in the 16th century isn't always as strictly defined as events in the 19th century on account of the sources available. This is even more true if we go back to the medieval or ancient events.

mean that a source may just say "winter of 1664–65" and no more precise date is available? In that case, it may be necessary to add a footnote explaining the possible date range, since 17th century definitions of seasons in a particular region and language may be different than modern definitions (and even in modern Europe and North America there are a few definitions to choose from). Jc3s5h (talk) 14:34, 28 May 2014 (UTC)

I live in Australia and expressions like 'during the summers of 1679–86' for me cause me to think of Dec-Feb (Australian summertime). I then have to pause for a moment while I rethink it. The rethink isn't hard in most cases but it does stop whatever train of thought the article was talking about. In some cases (eg if the ship was somewhere near or below the equator) then it is ambiguous if 'summer' means the Northern hemisphere summer as experienced by the writer or the local summer at the location.

To readers like me who have little knowledge of diving or ship building, there is no link between diving and summer or log cutting and winter. If the link is important then it is better to spell it out for us. If it is not important then it can be left out.

If the only reliable references just say 'summers of 1679–86' (ie no specific months given) then we get the choice of several bad alternatives

1. Leave it as 'summer', hope the context is good enough and that us poor southerns will put up with it.
2. Convert it to 'June-August of 1679–86' and assume the reference didn't mean July-Sept or May-June or May-Sept or similar.
3. Convert it an awkward expression like 'summers (circa June to August) of 1679–86'
4. Drop the season and let the reader think diving happened during winter time as well.

If a source gives exact months then always put them in instead of 'summer'. If the source does not give months but you know that diving only happens during June-August (or whatever months are good for diving), then I'd write in those months. If you can't work out the most likely months but the context makes it pretty clear that it is in the northern hemisphere, then I'd take the first option as the lesser of evils. And lastly, if the context isn't clear about whether it is the northern or southern summer then you will have to do some research and then spell it out, even if the wording is awkward.

To summarize, try to pin it down as tight as you can without making the wording painfully awkward.  Stepho  talk  15:18, 28 May 2014 (UTC)

I've implemented[18] some of the suggestions in Kronan (ship). If complete clarity is the aim of WP:SEASON, I don't see how awkward language can be avoided. It seems to me like this guideline was originally intended as a recommendation to use specific dates, but when applied very strictly in FACs, it seems to have become a prohibition against mentioning seasons at all, regardless of context.

It's also based on the very specialized instance of readers who can locate specific sections, but can't be assumed to read anything beyond that. It's literally the exact opposite argument of other MoS guidelines like WP:OVERLINK ("a link should appear only once in an article" .

Peter ^Isotalo 05:27, 30 May 2014 (UTC)

Notification of RfC

Talk:Albert Einstein#RfC: date format in this article requests community input on the date format (DMY/MDY) to be used in that article. The issue concerns the application of WP:STRONGNAT, WP:RETAIN and WP:DATERET to that article. It's the issue mentioned above, in the previous section. --Stfg (talk) 22:16, 1 June 2014 (UTC)

Need some extra advice for currencies

If one uses an abbreviation of million or billion as part of mentioning an amount of money, such as ten billion US dollars, does one write it "$10bn" or "$10 bn"? Should the abbreviation be spaced from the number or not? Roger (Dodger67) (talk) 14:49, 2 June 2014 (UTC)

MOS:NUMERAL says that it should be unspaced, and gives the example of £10M. --Redrose64 (talk) 16:14, 2 June 2014 (UTC)

Thanks, I missed that part. Perhaps it should be mentioned in the currencies section too. Roger (Dodger67) (talk) 06:26, 3 June 2014 (UTC)

Tera ambigious?

"In quantities of bits and bytes, the prefixes [..] tera (T), etc. are ambiguous", tera maybe, peta, exa? [How big are the biggest systems?] I just noticed that JEDEC (in the table) doesn't define tera. Note also for Tb/s rates (as in networks) and lower rates have been historically always been in decimal. The largest memory module is now 128 GB (just released) [19]. It takes three more doublings to reach binary TB, in one module. Yes, there are big systems/file systems, but file systems at least in Linux and Windows and computers in general handeling this amount of data have used decimal prefixes for a long time, right? comp.arch (talk) 10:07, 23 May 2014 (UTC)

I think have seen IBM using exa as a power of 1024. Does that make it ambiguous or simply incorrect usage? Dondervogel 2 (talk) 10:53, 23 May 2014 (UTC)

Both :) tera and all the prefixes are of course SI-prefixes so decimal is "correct" and binary "incorrect". Would like a good source for actual tera or more binary use. I've seen pages generally describe all the units as 1024 bigger than the next if that counts as a good source, these big numbers are however not much used in practice and then (mostly) as decimal? Eventually we will get in exabyte ranges of RAM combined, we are currently in terabytes (gigabytes for single modules). What started out as 0.24% small error for KB/KiB vs. kB, is an big error of 10% and 15% error for tebibytes (TiB) vs "terabytes" TB (decimal) and exibytes (EiB) vs "exabytes" (EB). comp.arch (talk) 12:28, 23 May 2014 (UTC)

The heading of this section should have been Tera incognito EEng (talk) 15:01, 23 May 2014 (UTC)

[20] "1024 Gigabytes = 1 Terabyte" A table that shows binary use. And another[21]. And [22]. And another [23] Terabyte (and the others) is not ambiguous because the meaning is obvious to those with knowledge in the field. Fnagaton 19:49, 24 May 2014 (UTC)

The guideline states "In quantities of bits and bytes, the prefixes kilo (symbol k or K), mega (M), giga (G), tera (T), etc. are ambiguous." Perhaps it should say potentially ambiguous. In articles that make it clear that the device under consideration is a RAM or ROM, and where the article is advanced enough that only people with knowledge in the field would be reading it, the prefixes are unambiguous. For novice readers, it may be ambiguous (but usually, those readers won't need to know which definition applies). In the case of an article that discusses the superficial characteristics of a device without revealing the underlying technology, the meaning is ambiguous (but again, in a superficial discussion, the difference in meanings probably isn't important). Jc3s5h (talk) 16:20, 25 May 2014 (UTC)

For as long as two different meanings are recognised for a prefix, that prefix is ambiguous. That is what the word means. It does not follow that all uses of that prefix are ambiguous, because there is nothing to stop the user of the prefix defining it each time it is used. Dondervogel 2 (talk) 16:31, 1 June 2014 (UTC)

They're not ambiguous according to the definition you link because when someone has relevant knowledge in the field the prefixes are not ambiguous, they are obvious to someone with skill in the field. Fnagaton 12:37, 8 June 2014 (UTC)

Writing "7 feet 0 1/4 inch"?

For 84.25 inch, do we write: 7 ft 1⁄4 in or 7 ft 0+1⁄4 in? -DePiep (talk) 14:22, 2 June 2014 (UTC)

It would always be the former. I don't know of any case where you'd write a vulgar fraction with a leading zero; that applies only to decimal fractions (you write 0.5 rather than .5, but 1/2 rather than 0 1/2 – you say "zero point five" but never "zero and a half"). Archon 2488 (talk) 15:23, 2 June 2014 (UTC)

Don't we write 214 cm? :) Or 84.25 inches (2,140 mm)? [It seems you can't ask for cm (the converted) first with the convert-template, and shouldn't maybe?] Where does this odd number come from? In case you must have the other format, 7 ft 1⁄4 seems ok to me. The three value frac format is to add whole numers and would seem to me not needed with a "zero whole part" (with or without feets). comp.arch (talk) 15:41, 2 June 2014 (UTC)

To show the converted-unit-first, use "disp=flip" as in:
   • {convert|84.25|in|mm|disp=flip} → 2,140 millimetres (84.25 in)
However, people could hard-code the conversion to show "0" with inches. -Wikid77 (talk) 19:20, 3 June 2014 (UTC)

It's only an odd number to those unfamiliar with British railway history. See Great Western Railway, Broad gauge#History and Railway Regulation (Gauge) Act 1846. --Redrose64 (talk) 16:11, 2 June 2014 (UTC)

re Comp.arch: I am only interested in the "'0' yes/no?" format question. Background: it originates from a railway track gauge designed and improved by I.K. Brunel in the early 1800s. This talk shows involved editors who prefer adding the "0". It also mentions a source (MacDermot, 1927) that has the zero written. -DePiep (talk) 16:53, 2 June 2014 (UTC)

I have no insight other than personal opinion, but when I was thinking about the issue for {{convert}}, I decided the "0" should be omitted:

• {{convert|84.25|in|ftin|frac=4}} → 84.25 inches (7 ft 1⁄4 in)
• {{convert|84.25|in|ftin|abbr=off|frac=4}} → 84.25 inches (7 feet 1⁄4 inch)

Johnuniq (talk) 23:45, 2 June 2014 (UTC)

Given that you have seen most conversion numbers & issues of us all, I tend to conclude that the issue is not that big or widespread. More like a on-off blip (probably by the 1927 source). Not a common writing. -DePiep (talk) 08:50, 3 June 2014 (UTC)

A Google search for "broad gauge" 7' (with quote marks as shown) finds several reputable sources (including Princeton University, and The Broad Gauge Society, using a leading zero. A search for "broad gauge" "7' 0 1/4" finds more. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:17, 3 June 2014 (UTC)

That would mean it is done more often for this one measurement, right? It could be following the 1927 source (btw MacDermot also uses periods in "ft. in."). I was hoping to find whether it is a common writing for imperial units. Now googling for 0½ inch gives some many hits, but not convincingly to make it a MOS/standard. -DePiep (talk) 12:59, 3 June 2014 (UTC)

Allowing either "0" or not: Once we found those multiple sources with "0+1⁄4" then obviously we should remove restrictions, or just have the wp:MOS state how either form is acceptable, just as gun caliber typically omits the lead zero for dozens of ".44 Magnum" or ".45 Colt" or ".357 Magnum" etc. Anyway, I have created a {convert/old} unit-code "ftinfrac0" to show the lead "0" as in:
   • {convert/old|214|cm|ftinfrac0} →

   • {convert/old|84.25|in|ftinfrac0} →

Some people seem to think the role of the wp:MOS is to advise the whole world how they have been writing with the wrong styles for centuries, but at least Wikipedia has enough intelligent users to broaden the consensus to match reality and not confuse people by claiming .357 caliber should be written as "0.357" or some other obnoxious stupidity. -Wikid77 (talk) 19:20, 3 June 2014 (UTC)

It's hardly obnoxious stupidity to insist on putting a zero before a decimal point, as only an innumerate person would want to do otherwise. However, .357 is the name of the item in question. Archon 2488 (talk) 20:34, 3 June 2014 (UTC)

Archon, you said, ".357 is the name" as if it were not a measurement, but .357 caliber is about one-third inch, where {convert|.357|in|mm|3}} = .357 inches (9.068 mm), as the diameter of the bullet inside the cartridge. -Wikid77 (talk) 14:21, 4 June 2014 (UTC)

I understand that it's a measurement, but my point is that ".357", without the leading zero, is the conventional name of the gun (strictly speaking, the name of the calibre). It's a nominal size that doesn't in every instance have to correspond to the actual diameter of the barrel or the bullet (or anything, because nominal sizes like "700C" can be weird like that), but regardless we should stick with the name that is used in the real world. For general measurements, the MOS requires a leading zero, as is proper. Archon 2488 (talk) 11:04, 5 June 2014 (UTC)

First of all, a calibre is the exception to {convert} calculation because it does fixed 'names'. The calibre 'numbers' are id's, are iconic. They are tabular, not calculated. Coincidentally, rail gauges (track widths) sometimes are too. E.g., the Chenmnitz (Germany) defined rail gauge "915 mm" is the 3 ft gauge, otherwise converted as "914 mm" (rounded more correctly).

Secondly, my original question is: write the zero yes or no. OK, so far I have seen many instances that do. But I am not convinced that it is a habit in imperial writing. My conclusion here is: it is written this way, but it is not a standard way. -DePiep (talk) 21:07, 3 June 2014 (UTC)

In the United States, where English measurements are often used for field events (e.g. shotput, discus, and high jump) at track and field meets, the zero is often shown, maybe almost always. See this page, this page, and this page, which are among the first four Ghits in a search for high jump results 7'0"1/4. – Jonesey95 (talk) 03:00, 4 June 2014 (UTC)

That's not strictly relevant to this issue because it appears they are used to a shorthand expression and write simply "High Jump: 7-2 1/4 (2.19)" (exactly like that, with no formatting). That makes a great deal of sense because athletics people probably think of the value as three words (feet, inches, fractional inches), so they would include zero. With "proper" formatting, it would make sense to include the zero if numbers are shown in tabular form, and I think Wikid77 is correct that some would include a zero and some wouldn't, and there is no need to impose a standard. In the case of a specific railway gauge, reliable sources might resolve what is "best". Johnuniq (talk) 07:45, 4 June 2014 (UTC)

• Anyway, fractions can have a lead "0" in text: And for years, Template:Convert has allowed showing a "0" with a fraction, such as:
       • {convert|0+1/8 |m |ft }} → 0+1⁄8 metre (0.41 ft), or
       • {convert|0+1/8|m|ft|disp=flip}} → 0.41 feet (0+1⁄8 m)
  Also zero with fractional inches:
       • {convert|7 |ft |0+1/4 |in |m }} → 7 feet 0+1⁄4 inch (2.140 m), or
       • {convert|7|ft|0+1/4|in|m|disp=flip}} → 2.140 metres (7 ft 0+1⁄4 in)
  As with .30 caliber, the lead "0" can be omitted. -Wikid77 (talk) 14:21, 4 June 2014 (UTC)

• Perhaps we need a reminder here that the point of a leading zero in a decimal fraction is to avoid having a leading decimal point. This is standard in engineering and science lest the decimal point be overlooked; in other contexts this is not a big deal (e.g., "20 caliber" is hardly ambiguous). But a zero in front of proper fraction just looks silly. ~ J. Johnson (JJ) (talk) 21:26, 4 June 2014 (UTC)

• I haven't been following this but I want to add this tidbit: it's not hard to find 19th C engineering sources discussing e.g. a gauge "6 feet 0 1/8 inch" and so on. [24]

Look, let me say this. To a first approximation the time to add to MOS guidance on some point is when it becomes apparent that doing so will avoid rehashes, on page after page or in project after project, of the same issue. So far I see no evidence of that. So why don't we let this get hashed out locally a few places, and if becomes a recurring waste of time the High Court of MOS can rule. Until then this seems like an argument to settle a problem that isn't arising. EEng (talk) 23:10, 11 June 2014 (UTC)