Template talk:Convert/Archive July 2015

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Units which set sp=us

Some units are defined like this:

meter  =m  sp=us

That makes meter an alias for m and also sets sp=us (US spelling of "meter"). Currently, convert gives these results (using fixed wikitext so the results will not change):

  • {{convert|1.23|meter|cm|abbr=off}} → 1.23 meters (123 centimetres)
  • {{convert|123|cm|meter}} → 123 centimetres (1.23 m)

That uses sp=us for "meters" but not "centimetres". As part of some recent developments, I plan to make sp=us apply to both sides which will give these results:

  • {{convert|1.23|meter|cm|abbr=off}} → 1.23 meters (123 centimeters)
  • {{convert|123|cm|meter}} → 123 centimeters (1.23 m)

There are about 110 converts in articles where this will make a small difference. For example, {{convert|44,000|liters}} will change from the first of the following to the second:

44,000 liters (9,700 imp gal; 12,000 US gal)
44,000 liters (9,700 imp gal; 12,000 U.S. gal)

and {{convert|4.4|to|5|L|U.S.qt}} will change like this:

4.4 to 5 litres (4.6 to 5.3 U.S. qt)
4.4 to 5 liters (4.6 to 5.3 U.S. qt)

I'm posting this to document my planned change to convert, but I don't think the subtle difference is worth documenting for users. Johnuniq (talk) 04:29, 3 July 2015 (UTC)

This is a great idea except for one thing. I'm not so sure about linking "US" vs "U.S." to "~re" vs "~er". "US" vs "U.S." would better be kept distinct from |sp=us. Using American English does not mandate using "U.S." in fact (according to the MOS) "The Chicago Manual of Style (16th ed.), now deprecates U.S. and prefers US." (link removed). The MOS also says "use 'US' in articles with other national abbreviations, e.g. 'UK' or 'UAE'". So, an editor could very easily want to use "US" in an article with US spelling. Moreover, "U.S." is "the dominant abbreviation" (according to the MOS) in Canadian English; however, Canadians write "metre" and "litre". Another point to consider is the future. It's not inconceivable that {{convert}} will still be around in 100 years; they'll probably stick to their quirky spelling but will Americans still be dotting "US" then? Jimp 16:01, 3 July 2015 (UTC)
The U.S. versus US style is in transition and I'm sure you're right that US is supported by the MOS and will also become more prevalent in the real world...except for where it doesn't like Canada, groan. I posted those examples because they are typical of the 110 converts which will change, and that is only because of the way the units are currently defined. Currently U.S.gal sets sp=us but is otherwise an alias of USgal—we could readily change U.S.gal to show U.S. in the output but not set sp=us and that would be the cleanest thing to do if it were necessary. Johnuniq (talk) 21:53, 3 July 2015 (UTC)
Well, that's what I'd be suggesting, the clean approach whereby "US" vs "U.S." is set by the form of the input unit code and "~re" vs "~er" is set by |sp=us. Anyhow, tonnes, if we really want some fun we can start chucking metric tons around. Jimp 01:11, 4 July 2015 (UTC)

Proposed new units

I am preparing for a new release of the module and that involves consideration of three units added to Module:Convert/extra:

  1. au: like AU but using au displays "au" as the symbol, while AU displays "AU"
  2. u: unified atomic mass unit
  3. dalton: same as u but displays "Da" for the symbol and "dalton" for the name

I support the addition of au because recent MOS discussions show there is no ruling on whether "au" or "AU" is preferred and in some contexts "au" is wanted while others need "AU". If anyone has a link showing my understanding of the MOS discussions is incorrect, please provide it, however, let's not debate the merits of each symbol here.

I do not support u or dalton unless someone can show a couple of articles where conversions of these units would be useful. Cpiral may have had {{val}} in mind because val uses convert for some units, however I think val has a different application than convert and the latter is too complex already without adding units specifically for val. Thoughts please. Johnuniq (talk) 03:24, 30 June 2015 (UTC)

Since val can very easily take care of u separately, val gives no a reason to include a unit that is not needed in convert. —Quondum 03:35, 30 June 2015 (UTC)
Any page about units that also has a conversion chart (: hastemplate:"infobox unit" insource:inunits1) should be here ready and waiting, including those three. — CpiralCpiral 04:01, 30 June 2015 (UTC)
Do you mean the infobox table, for example, at the top of Atomic mass unit? I would not expect convert to always be useful there because precise definitions are involved and mucking around with convert to display exactly what is wanted might not be warranted. In particular, that example uses uncertainty notation which convert can't handle. There are zillions of units (examples), and adding them all to convert for one or two occurrences does not seem desirable. Johnuniq (talk) 04:19, 30 June 2015 (UTC)
OP proposal sounds reasonable to me. -DePiep (talk) 08:31, 30 June 2015 (UTC)
No. Please let me answer the original question again. Add auu because its Wikipedia page rightly states that it is commonly and notably converted. Consider the alternative process: that other person is bothered because the commonly converted standard unit is missing from Convert, and is bothered to come to the talk page, and no one would then delay. So why aren't all 27 units in that search link? Because that search link is new information. There is no more reasonable, honest, objective justification for adding au or any other unit missing from that particular search. Thank you. — CpiralCpiral 21:43, 2 July 2015 (UTC)
Yup, your understanding of the MOS discussion re au and AU jibes with mine. And I think that even if the MOS does recommend one symbol or the other, it will remain best to include both in the convert template since it's just a tool for editors (not an MOS enforcement mechanism) and both choices are at least arguably reasonable. I do not care at all about the implementation; as far as I know as a dumb end user, it works perfectly well now and there is no need to change it. —Alex (Ashill | talk | contribs) 14:29, 30 June 2015 (UTC)
re (not an MOS enforcement mechanism) - well, it should follow MOS truly & really. That is also what it is about, over here. -DePiep (talk) 02:26, 1 July 2015 (UTC) (did rm distracting typo)

@Cpiral: I don't follow your comment. Please show an example of a val and/or convert that would be useful in an article and which needs units 2 and 3 above (u and dalton). If there are 27 articles (like Watt?) that need some fix, why not just add the required definition to val? One of the items on my todo list is to remove a lot of strange units from convert because they add clutter and are never used, and that makes me doubly reluctant to add new units unless there is a demonstrated need for them. Johnuniq (talk) 01:25, 3 July 2015 (UTC)

I can appreciate your sentiment about units being clutter, I'm interested in that effort too and concede that it might be the case that daltons are clutter. I only had in mind to humbly vote and proudly advertize my wares, so forgive me if I sound repetitive, but I'm confident that my reasoning, given above, has weight: Those pages are most likely to need template convert, themselves, somewhere on there own page with convert because, by virtue of each of them having a Infobox Unit with conversions in it. That. Plus they say they convert themselves. Make sure the 26 others are there to, and for the same reason. Don't wait for them to ask or for me to exemplify in time. As for your examples, I humbly submit on behalf of u, alias Da, alias amu, the word "OR" as appended to Atomic mass unit#Examples, plus the very telling Infobox Units. — CpiralCpiral 07:35, 3 July 2015 (UTC)
That example uses val like this:
  • {{val|1.0078250|u=u}} ({{val|1.0078250|u=Da}}) → 1.0078250 u (1.0078250 Da)
It seems pretty pointless to define those units in convert when they are equivalent, and given it is unlikely the units would be used for anything else. Convert could be used instead of val in the infobox at, for example, Kilometre, but no new units are needed for that. I don't see how convert could be expected to help at, for example, Watt. It is normal here for people to be asked to provide examples of how proposed units would be used. Johnuniq (talk) 10:29, 3 July 2015 (UTC)* A hydrogen-1 atom has a mass of 1.0078250 u (1.0078250 Da).
I'm just trying to get us to the point where you hear the logic of my undeniable reasoning. I'm not asserting anything. I'm ignoring when Da "would be useful", and only treating the Da element as an insignificantly small application, in what I must assume is a perfectly elegent and capable Convert apparatus in a powerful and efficient Lua environment. Of course I would not ask for the why or how of a rejection.
So here the four examples in the link I gave above, now here and modified to show in green the "or" part I mentioned, the part that must inevitably one day be requested on behalf of Da (and any others missing from the above search list, of notable and common conversions as listed on those pages), and showing in red the one automatic Convert that editor could have (and in my viewpoint certainly should have used) instead of the two manual Vals.
  • By definition, a carbon-12 atom has a mass of 12 u (12 Da) or 1.87437×10−26 kg --> {{convert|12|Da|kg}}
  • A molecule of acetylsalicylic acid (Aspirin) has a mass of 180.16 u (180.16 Da) or 931.49 MeV/c2 --> {{convert|180.16|Da|MeV}}
  • Titin, the largest known protein, has an atomic mass of 3-3.7 megadaltons or 18–19 me --> {{convert|3700|Da|me}}
— CpiralCpiral 17:40, 3 July 2015 (UTC)
Things proceed slowly here so let's try this: in a couple of weeks I will update the modules and move au into the main data module, and keep u + dalton in the extra module so they will continue to work. We can think about making them more permanent later. Johnuniq (talk) 22:04, 3 July 2015 (UTC)
The need for certain units and not others should really depend on article space, shouldn't it? A kind of ecosystem that needs scientific analysis, rather than programmer sentiment, to decide for provisions? Here are some numbers to think about from units samples taken in article space: {{Val/units/test}}. Many of my guesses about the number of articles that used a particular Val unit were way off. Many of the more troublesome units I've become familiar with, (having to bandy them about while performing Val/units maintenance), are not even used. Apparently units were likely added just for the sake of adding the unit, because obviously they are not needed at this time. My gathering instinct, my effort towards the wp:performance orientation, and my text processing skills all lead me to feel like keeping them maintaining them.
It seems daunting to have to fully play out any of the parts of any of the participants of the au/MoS drama (see the recent discussion), but I can't find an easy query "Dalton OR Da OR u incategory:units" that we can do to get number to then gauge a probability. But if such a category or query could be found, the unit battles would be over. Case closed. Next unit.
Ideally, I think, the addition of units should happen for one reason—probability—and not because an editor asks, and not because the maintenance burden is lifted. From the time regexp searches were made available, there began the chance to apply science to what was previously blind sentiment and happenstance. I claim is highly probable the articles I gave in my original search link —: hastemplate:"infobox unit" insource:inunits1— would benefit from having {{Convert}} ready for what will inevitably one day be converted there. I'm thinking that that quick survey is only the lowest fruit on one of many other Convert-targeted surveys of the wiki that are possible to determine what units Convert bothers with. Thanks for reading. — CpiralCpiral 22:35, 3 July 2015 (UTC)
Cpiral, your "logic of my undeniable reasoning" paragraph is pedantic into being illegible. I also beg to claim that "I'm not asserting anything" is falsified by your statements e.g. when writing "should really depend on article space". Then you start "ignoring" stuff. If you cannot argue without injecting "programmer sentiment" (actually it is designers choices, but hey you can ignore that too if it suits you). It's hard to read sense in between your personal judgements.
As far as I can follow you, when Johnuniq asked for existing example that use such a conversion, you came with the unit-equivalents (u, Da) to which you were answered. Only then did you add true conversions, not present your linked examples, thereby explicitly ignoring the answer's gist.
Let me reply short to your statements: no, you are mistaking that articles should dictate what conversion should do. {{Convert}} is a supporting help, not article content. It has been explained to you here. You can propose improvements for example by reading the replies here once more, and follow up. Or you can ask clarification if you don't understand parts of it. At this point, there is no conclusion brought forward to add those units. -DePiep (talk) 12:03, 4 July 2015 (UTC)
I don't assert keeping 2 or 3 because I must remain silent on that and defer: ya'll ain't Val. At Val anyone just adds a unit. — CpiralCpiral 22:05, 4 July 2015 (UTC)
no, you are mistaking that articles should dictate what conversion should do. {{Convert}} is a supporting help, not article content.
Not dictate, mandate. Because Convert stylizes content, whereas Val does not, the MoS, which has a mandate above and beyond Convert, can only wait so long. Because Converts weakness causes Wikitext-clutter wherever two Vals instead of one Convert are required, users will mandate Convert add convertible units, or they will mandate the MoS mandate it. Mandate stuff takes time, and temporarily necessary dictatorial actions are laughable, like the fact that Convert temporarily not only cannot add a flagship Wikipedia convertible unit, but threatens to throw out treasures to avoid sinking. — CpiralCpiral 22:05, 4 July 2015 (UTC)
I have suggested the development of a CirrusSearch skill (which is more rare than a Lua skill) and employing the science of probability based on numbers from that search, in order to try and help. I am not sure I have helped yet.
The fix-all solution is to throw more development at Convert internals. Recent unwanted-emotionally, unecessary-technically, discussions are symptomatic of overworked developers. First we discussed au, now its u, and next time will be . ? How can it become . ? I suspect these oft-said unwanted discussions are really symptomatic of the need to create the Lua scripts to convert /data into various interesting formats. Starting with them will lead to better ability to handle units, and lead to a config file anyone can edit. The technology is not to blame for Convert's inability to handle beyond a certain number of units, development is. — CpiralCpiral 22:05, 4 July 2015 (UTC)
eh Cpiral, what-the-fuck is your reply? -DePiep (talk) 22:21, 4 July 2015 (UTC)
Sorry for ignoring your "ignoring" remark. I've highlighted something for you. — CpiralCpiral
Well, you do not need to answer me of course, but for Johnuniq you better spend quality time. -DePiep (talk) 22:24, 4 July 2015 (UTC) (refined, -DePiep (talk) 22:55, 4 July 2015 (UTC))
Well I could begin some Lua objects oriented around /data. I'm sure that would entail quality time with Johnuniq. — CpiralCpiral 00:11, 5 July 2015 (UTC)

adjective and or

When the "adj=on" parameter is used with "or" as the second parameter, the "or" is included as part of the adjective when it should be split, e.g. from Slacklining:

  • Code: {{Convert|2|or|1|in|spell = in|adj = on}}
  • currently gives: two-or-one-inch (51 or 25 mm) (substed: two-or-one-inch (51 or 25 mm))
  • should give: two- or one-inch (51 or 25 mm)

Although the "spell" parameter is used here, testing shows this makes no difference: 2-or-1-inch (51 or 25 mm) (substed: 2-or-1-inch (51 or 25 mm)) should be: 2- or 1-inch (51 or 25 mm). Thryduulf (talk) 20:16, 9 July 2015 (UTC)

Getting data from Module:Convert

A new helper function has been added to the sandbox so another module can look up convert's units—that would be useful for example if a module were used to implement {{val}}. Information is at Module talk:Convert/Archive 2#Getting data from Module:Convert. Johnuniq (talk) 01:38, 4 July 2015 (UTC)

What does "look up" mean? How and what to? I've been suggesting such partial funtions all time. -DePiep (talk) 22:27, 4 July 2015 (UTC)
It means another module can use convert to determine the symbol or name of a unit from its unit code. Options control whether the result is linked and whether it uses US spelling. If the unit code is not known, a dummy result is returned (unit code "xyz" would give symbol and name "xyz", and the link would be "[[xyz]]"). A small amount of module code is needed (see the above link) and the function cannot be accessed directly by a template. I would not have thought a template would not be needed because the new function is equivalent to, for example, {{convert|1|usgal|abbr=on|lk=on|sp=us|disp=unit or text}} which gives "[[US gallon|U.S. gal]]". Johnuniq (talk) 08:04, 5 July 2015 (UTC)
But to satisfy {{val}} we've got (as you're aware) to be able not only to pull out the symbol/abbreviation but also the numerical equivalent in SI. Jimp 16:36, 5 July 2015 (UTC)
Yes, it does that. Some examples are here—the "unit(...)" lines show what a module would do to look up a unit, and the line underneath has the result, including a sort key. Would you be interested in working on Module:Val? I intend fixing the unit part of that module so it works with convert and has a very convenient way for built-in units to be defined, but I don't want to dive into the intricacies of what val does without support. Johnuniq (talk) 01:33, 6 July 2015 (UTC)
It should serve {Val} of course, but not be {Val}-only right? Later, Val can align. This partial function, what could it have for input, and for output? IMO, beforehand, every Lua access to the {convert} unit data set is great. -DePiep (talk) 20:37, 9 July 2015 (UTC)

Table of contents

Hi, I feel that this list could possibly benefit from some quick links to each section, functioning as a contents table. Otherwise you may have to scroll down for ages or use Ctrl-F (not hard, I know, but it would make things easier; otherwise it seems a little difficult to navigate). I imagine there will be some technical reason I haven't grasped which makes it impossible, but such an index could be accomplished with anchors. There is no usual TOC, since the displayed list appears to be a sequence of smaller wikitables such as {{convert/list of units/length/short list}}, whose first line is 

|- !colspan=7|LENGTH

which could (I imagine) be easily changed to 

|- id=Length !colspan=7|LENGTH

since {{anchor}} is not allowed on lines with |- at the beginning. These could be linked thus, e.g.:

  1. Length [[Length table#Length|Length]]
  2. Mass [[Mass table#Mass|Mass]]

etc. My technical knowledge stops here. Any thoughts? >MinorProphet (talk) 13:23, 15 July 2015 (UTC)

Yes, such an anchoring would be great.
Let's do uc/lc together: id=Length, id=length.
Are the list generated automatically?
By the way, wetre the grouping names straight section titles (==Length==), they's be an anchor right away. And would not introduce an ad hoc heading. -DePiep (talk) 18:27, 15 July 2015 (UTC)
I had a go at making a fake contents box for Template:Convert/list of units. Better than nothing, although it's not quite right. For some reason the #Volume anchor doesn't work, but takes you to the top of the first table...
Volume anchor fixed by User:PrimeHunter from the Help Desk. I think everything looks 100% better. Thanks, all. >MinorProphet (talk) 07:01, 16 July 2015 (UTC)

Rounding to multiples of 0.5

Despite playing with all the rounding parameters, I can't get {{convert}} to round to the nearest 0.5 - e.g. {{Convert|8|-|12|ft|disp = comma|abbr = on|round = 0.5}} gives (substed): 8–12 ft, 2.4–3.7 m. Thryduulf (talk) 20:24, 9 July 2015 (UTC)

Strange indeed. Documentation says #Round to a multiple of 5: 15, 20, 25, ....
From {{Convert|8|-|12|ft|round = 0.5}}
  • 8–12 feet (2.4–3.7 m) -- no round
  • 8–12 feet (2.5–3.5 m) -- round = 0.5
  • 8–12 feet (2.4–3.7 m)* -- round =1
  • 8–12 feet (0–5 m) -- round =5
  • 8–12 feet (0–0 m) -- round =10
  • 8–12 feet (2.4–3.7 m)* -- round =15
Johnuniq, is this about integers? -DePiep (talk) 20:49, 9 July 2015 (UTC)
Isn't this a bug? -DePiep (talk) 21:28, 9 July 2015 (UTC)
Sorry, but convert has no way to round to the nearest 0.5. The issue arose in March 2015 where I said that, for example, the value 12.5 means not 12.4 and not 12.6—it would not be clear that 12.5 was in fact intended as a value rounded to the nearest half.
It is possible to round to the nearest 1⁄2:
  • {{convert|2.6|m|frac=2}} → 2.6 metres (8 ft 6+1⁄2 in)
  • {{convert|2.6|m|ft|frac=2}} → 2.6 metres (8+1⁄2 ft)
For historical reasons, there are thousands of broken parameters in converts used in articles so I haven't been brave enough to enable warnings. However, the sandbox template does enable warnings and can be used to check whether convert is accepting a parameter:
  • {{convert|8|-|12|ft|disp=comma|abbr=on|round=0.5}} → 8–12 ft, 2.5–3.5 m
  • {{convert/sandbox|8|-|12|ft|disp=comma|abbr=on|round=0.5}} → 8–12 ft, 2.5–3.5 m
Holding the mouse over the error message shows Ignored invalid option "round=0.5".
@DePiep: If wanted, you can check what is a valid option by searching for "Valid option values" in Module:Convert/text. It's in alphabetical order and the "round" section shows that the only accepted values are "5" + "10" + "25" + "50" + "each".
Johnuniq (talk) 00:50, 10 July 2015 (UTC)
Why would 12.5 mean not 12.4 or 12.6 but presumably when rounding to 5, 125 would still mean anywhere from 123 to 127? Why does the decimal point make a difference?GliderMaven (talk) 01:27, 10 July 2015 (UTC)
That's a good point, but is also an illustration of the ambiguities of language. People are used to thinking that "the fence is 125 feet from the house" may not be intended as a precise statement. It's true that "the fence is 12.5 feet high" might likewise be interpreted "closer to 12+1⁄2 than 12 or 13", however, most encyclopedic mentions of 12.5 would imply 12.5±0.5, just like 12.4 implies 12.4±0.5. I have not invested much thought or research on this, and if there are a few examples of where rounding to the nearest 0.5 are really needed, it can be looked at. Johnuniq (talk) 01:56, 10 July 2015 (UTC)
I'm not persuaded there is a need to round to multiples of a power of 5 (if someone really wants to do that, they can simply not use the convert template and do it manually). But if I see a measurement of 12.5 which was written by someone with a technical background, I interpret it to mean that the .5 helps to understand the true value of the number is. If the actual uncertainty was ±0.3, writing 12.5 gives a better idea of what the value is than writing 13. But adding another digit, and writing 12.53, does not help understand the true value, so the 3 digit is false precision. Of course, this is all rough & ready notation; if it's really important the statement should be something like "the value is normally distributed with a mean of 12.5 and standard deviation of 0.1".Jc3s5h (talk) 03:25, 10 July 2015 (UTC)

The problem for me here is that the conversion is implying a greater precision than the original value. "8-12 feet" in the context of the article means "2.5 - 4 metres" not "2.4–3.7 metres" (i.e. ±1-2 feet or 25-50 centimetres not ±10 centimetres or 3.9 inches). Thryduulf (talk) 19:19, 10 July 2015 (UTC)

Don't forget that Wikipedia is a reference work; people take these numbers and plug them into their calculations. In most cases you want greater precision from a converted value; the value you start with is always rounded in some way, and if you round it again to the same degree, the accuracy is reduced, often unacceptably. And it's usually clear from the initial value, what the real precision is anyway.GliderMaven (talk) 19:44, 10 July 2015 (UTC)
That is relevant for scientific and technical contexts, but that is not the only way that numbers are used on Wikipedia. This is an estimated length and the excessive precision misrepresents the source in exactly the same way that excessive rounding would. Thryduulf (talk) 20:22, 10 July 2015 (UTC)
I respectfully just don't agree. If somebody quotes a length of a road as 1 mile, is it 2 km? Of course not, and that's not even what convert does: 1 mile (1.6 km). Adding a decimal place is a fairly robust (but not foolproof) heuristic that would get close to what is intended in the vast majority of cases; and note that the original value is there for the reader to interpret its accuracy (in that case at least, convert is used in different ways, but being able to see the source value is the most common). Given that the reader can see how it was supposed to be originally, so there's no misrepresentation.
But going back to the original point, if the editor specifies it should be rounded to 0.5, they presumably know something.GliderMaven (talk) 21:52, 10 July 2015 (UTC)
If someone quotes a length of a road as "1 mile", then I'd want to see 1.6km. If someone says the aircraft crashed "about a mile away" I'd want to see "about 1.5km". Thryduulf (talk) 22:08, 10 July 2015 (UTC)

This has been requested before, so on the basis that an editor can choose when it is desirable to provide a hint that the value is not precise, I have implemented round=0.5 in the sandbox. On trying it out I decided that the result should round to N or N.5 where N is an integer—it should not show N.0 as that implies a precision which is not wanted. That point is shown in the second of the following examples where 7 ft rounds to 2 m while 8 ft rounds to 2.5 m. Any thoughts on that?

  • {{convert/sandbox|7x8x12|ft|abbr=on}} → 7 ft × 8 ft × 12 ft (2.1 m × 2.4 m × 3.7 m)
  • {{convert/sandbox|7x8x12|ft|abbr=on|round=0.5}} → 7 ft × 8 ft × 12 ft (2 m × 2.5 m × 3.5 m)
  • {{convert/sandbox|1.249|m|m|round=0.5|abbr=on}} → 1.249 m (1 m)
  • {{convert/sandbox|1|m|m|round=0.5|abbr=on}} → 1 m (1 m)
  • {{convert/sandbox|0.9|m|m|round=0.5|abbr=on}} → 0.9 m (1 m)
  • {{convert/sandbox|0.8|m|m|round=0.5|abbr=on}} → 0.8 m (1 m)
  • {{convert/sandbox|0.75|m|m|round=0.5|abbr=on}} → 0.75 m (1 m)
  • {{convert/sandbox|0.7|m|m|round=0.5|abbr=on}} → 0.7 m (0.5 m)
  • {{convert/sandbox|0.6|m|m|round=0.5|abbr=on}} → 0.6 m (0.5 m)
  • {{convert/sandbox|0.5|m|m|round=0.5|abbr=on}} → 0.5 m (0.5 m)
  • {{convert/sandbox|0.4|m|m|round=0.5|abbr=on}} → 0.4 m (0.5 m)
  • {{convert/sandbox|0.3|m|m|round=0.5|abbr=on}} → 0.3 m (0.5 m)
  • {{convert/sandbox|0.25|m|m|round=0.5|abbr=on}} → 0.25 m (0.5 m)
  • {{convert/sandbox|0.2|m|m|round=0.5|abbr=on}} → 0.2 m (0 m)
  • {{convert/sandbox|-1.25|m|m|round=0.5|abbr=on}} → −1.25 m (−1.5 m)
  • {{convert/sandbox|-1.75|m|m|round=0.5|abbr=on}} → −1.75 m (−2 m)

It may be a few weeks before this goes live in convert because I'm trying to put some tweaks in it for Module:Val in case that is ever developed. It's ok to use the sandbox convert in an article if wanted, and I will get around to replacing it with the proper convert in due course. Johnuniq (talk) 07:05, 11 July 2015 (UTC)

That all looks fine to me, and I agree about not showing N.0. Thryduulf (talk) 20:53, 11 July 2015 (UTC)
Per {{Template usage}}:
84 or 85 use "round" and of those
78 or 79 use "2" and
6 use "5" or ".5"
— CpiralCpiral 05:58, 17 July 2015 (UTC)

Mathematical error needs correction

Hi, all.

At Lumber#North American hardwoods, this template is representing 144 cubic inches (1/12 of one cubic foot) as both 2,360 cubic centimetres (correct, as a rounding of the exact 2,359.737216 cubic centimetres) and 0.028 cubic metres (incorrect—should be 0.024 cubic metres, if rounded to the third decimal place).

The conversion factor is exactly 2.54 centimetres to the inch.  2.543 = exactly 16.387064.  16.387064 × 144 = exactly 2,359.737216.

— President Lethe (talk) 00:53, 19 July 2015 (UTC)

The correct equivalent to a board foot is 0.0024 m3. There is no error in the template, but trying to pack too many equivalents into one sentence created confusion. I trimmed out the needless conversions. Jc3s5h (talk) 01:13, 19 July 2015 (UTC)
(edit conflict) The template is correct but used twice in an ambiguous way. The article says {{convert|144|cuin|disp=or}}, {{frac|1|12}}th of {{convert|1|cuft|disp=or}} which renders as: 144 cubic inches or 2,360 cubic centimetres, 1⁄12th of 1 cubic foot or 0.028 cubic metres. The first conversion correctly produces "144 cubic inches or 2,360 cubic centimetres", and the second correctly produces "1 cubic foot or 0.028 cubic metres". 1⁄12th is written by an editor and isn't produced by or passed to the template at all. By the way, 2,360 cubic centimetres is actually 0.0024 cubic metres and not 0.024 as you say. PrimeHunter (talk) 01:16, 19 July 2015 (UTC)

Thanks for the replies, Jc3s5H and PrimeHunter.  Your edit to "Lumber", Jc3s5H, did remove the ambiguity (which I also had noticed, but in a different way).  I now see how, where I thought it should be giving 0.0024 cubic metres (the rounded equivalent of 144 cubic inches; thanks for pointing out the extra 0, which I was missing!), it was giving 0.028 cubic metres (the rounded equivalent of 1 cubic foot or 1,728 cubic inches). — President Lethe (talk) 19:02, 21 July 2015 (UTC)

MOS ranges

Recent discussions (for example, 1 × 2 × 3 cm above) have concerned WP:UNIT which specifies that the unit should be repeated in a "times" range that uses ×. For historical reasons that currently occurs for 1x2 ranges, but not for 1x2x3 or higher. Another consideration is that 1x2 uses "by" when abbr=off and "×" when abbr=on. The following illustrates these issues, using fixed wikitext so the results won't change:

  • {{convert|1x2|m|cm}} → 1 by 2 metres (100 cm × 200 cm)
  • {{convert|1x2|m|cm|abbr=off}} → 1 by 2 metres (100 by 200 centimetres)
  • {{convert|1x2|m|cm|abbr=on}} → 1 m × 2 m (100 cm × 200 cm)
  • {{convert|1x2x3|m|cm|abbr=on}} → 1 × 2 × 3 m (100 × 200 × 300 cm)

Displaying "by" may not be expected above, but it's purpose is to use natural language when unit names are shown and is the way convert has worked for many years.

I've done far too much work on this in the last week, and have some new code which is not yet uploaded. The following illustrates some results (again using fixed wikitext) from the new code:

  • {{convert|1x2x3|m|cm|abbr=on}} → 1 m × 2 m × 3 m (100 cm × 200 cm × 300 cm)
  • {{convert|1|by(x)|2|m|cm}} → 1 by 2 metres (100 cm × 200 cm)
  • {{convert|1|by(x)|2|m|cm|abbr=on}} → 1 by 2 m (100 cm × 200 cm)
  • {{convert|1|by(x)|2|m|cm|order=flip}} → 100 by 200 centimetres (1 m × 2 m)

The new code gives the same results for the 1x2 cases shown above—it shows "by" when abbr=off. The new code supports a new method of defining "times" ranges and it would now be easy to make 1x2 always use "×". The new by(x) range is in anticipation of that change—it works like and(-) and to(-) in that by(x) always uses "by" on the left, and "×" on the right (the left side is normally the input, but is the output if order=flip is used). The behavior of 1x2 has not yet been changed because it occurs over 6,000 times in articles and I would prefer to have the new code running for a few weeks before considering whether to change 1x2. Apart from my hesitation about imposing such a significant change without wide discussion, it's good to check that new versions produce reasonable results in the converts used in articles, and the changes are already very complex, so I don't want to deal with checking what happens with 1x2 changes yet. The changed results are in my sandbox2 (permalink). Please have a look! One change I'm unsure about is in the "Thousand million billion trillion" section where the number words are repeated. That is a side effect of a fix to correct the currency/length bug shown in the previous section ("1–$2 per kilometer"). Johnuniq (talk) 08:06, 8 June 2015 (UTC)

I'm chewing on this (like 1 and 2). -DePiep (talk) 19:34, 10 June 2015 (UTC)
I am *very* charmed by the argument: it's purpose is to use natural language when unit names are shown (i.e. to write "1 by 2 metres" for the first value). Coming from my "It must be MOS and must be scientifically right", for me this opens a nice improvement into readability (still MOS and scientifically legal! ;-). (Five stomacs to go). -DePiep (talk) 19:31, 13 June 2015 (UTC)
Note 3/n. Johnuniq, your OP does not say so explicitly, but is the explicit aim that all dimensions (dimension: 1 x 2 = 2 dim; 1 x 2 x 3 = 3 dim) all will be treated the same, as in: "there will be one MOSCONVERT (lol) in this"? -DePiep (talk) 19:48, 28 June 2015 (UTC)
My plan is that 1x2 and 1x2x3 (and similar such as "1x2 to 3x4") would repeat the unit symbol when the unit is abbreviated so it will be MOS compliant. I finished the code for that a couple of weeks ago but off-wiki events have interfered with final testing. The sandbox2 links above give more examples, however I decided that the simplified code which repeated numbers such as in "3 million to 8 million US gallons" was ugly, so I added a little more with the result "3 to 8 million US gallons" as currently occurs. I should get the code uploaded to the sandbox with a summary soonish. Johnuniq (talk) 02:23, 29 June 2015 (UTC)
OK, your answer is fine. (I'm reading your intentions, not the sandbox & code issues). -DePiep (talk) 21:31, 30 June 2015 (UTC)
Note 4/n. So the principle is: Per output value (that's those two per convert, basically) 1: determine whether the unit is shown as name or as symbol, whatever the reason. 2: the "by" or "x" follows this outcome, whatever the input in this. (In other words: an editor entering "x" while the unit must show the unit name for whatever reason, {{Convert}} turns that "x" into "by" format. Unit name says so! -DePiep (talk) 23:04, 2 July 2015 (UTC)
Let me refine/check: if the editor asks for "x" and "unit name", the unit name dictates that the x-form be turned into "by"-form. This per value (never the second/output value changes the first/input value format in this). -DePiep (talk) 20:30, 9 July 2015 (UTC)
Note 5/n. I'm looking for this option. If I want to enter a full scientific notation (ie "x" not "by" ever), while showing the unit name (think: an obscure unit name), then how can I enforce that? -DePiep (talk) 20:30, 9 July 2015 (UTC)
Yes, using 1x2 will show "by" when the unit is not abbreviated, and some units such as acre are never abbreviated (the acres example is just to illustrate how convert works; there is no such thing as "1 by 2 acres"):
  • {{convert|1|x|2|m|abbr=on}} → 1 m × 2 m (3 ft 3 in × 6 ft 7 in)
  • {{convert|1|x|2|acre|abbr=on}} → 1 by 2 acres (0.40 ha × 0.81 ha)
  • {{convert|1|x|2|m|abbr=off}} → 1 by 2 metres (3 feet 3 inches by 6 feet 7 inches)
  • {{convert|1|x|2|acre|abbr=off}} → 1 by 2 acres (0.40 by 0.81 hectares)
The only range which follows MOS regarding repeating the units with × is plain x. However, there is also xx which always uses × and works as a simple range, just like "to".
  • {{convert|1|xx|2|m}} → 1 × 2 metres (3 ft 3 in × 6 ft 7 in)
  • {{convert|1|xx|2|m|abbr=mos}} → 1 × 2 metres (3 ft 3 in × 6 ft 7 in)*
That does not do everything that might be wanted, but it's close enough for what is used in practice. Johnuniq (talk) 01:19, 10 July 2015 (UTC)
Wait wait. I do not accept input option "xx" to be introduced in this discussion. As it was, it was complicated enough. And I note, |xx| is already depreceated. On top of this, |xx| is not MOS). So Johnuniq, will you withdraw all of this "xx" sidetracking? (And explain why you ever ever brought it up?) -DePiep (talk) 21:50, 15 July 2015 (UTC)
I'm just reporting what has been there for years (from before the module existed) in response to the question about "×". I'm not recommending it, and am happy to withdraw. As described above, the changes make 1x2x3 MOS compliant, so that's a move forward. Johnuniq (talk) 04:14, 16 July 2015 (UTC)
Yes we know it was there for years. The point is, Johnuniq, we want to get rid of it. Those "years" include the pre-module era, and now you use that as an argument. But hey, Johnuniq, since you keep bringing deprecated non-MOS as an argument (to keep me busy and distracted, right?): see you when you have actually removed non-MOS options. But I don't believe you ever will. -DePiep (talk) 02:00, 19 July 2015 (UTC)
Avoid the need for backward compatible code or documentation. Directly evolve the obsolete parameter usage on the the 45 articles using xx. — CpiralCpiral 09:02, 19 July 2015 (UTC)
I agree, it's time we got rid of these deprecated options (like xx and mos ... I thought I got rid of mos years ago). When backwards compatibly merely accommodates a particular user's non-MOS-compliant whim, I'd say, forget it. Jimp 00:34, 21 July 2015 (UTC)
From /doc#Deprecated_options: deprecated being non-MOS: abbr=mos, adj=1, |xx|, |*|. All have alternatives mentioned. Discussion was on this page, so look in the archives. IMO as long as they may appear in articles (as is today), they should be in the documentation somehow. Until now I had no opinion on the removal-process (in soft steps ahead or hard from code as Cpiral says), but since they keep coming back in talks like an old bug it is time to kill them asap with fire. The error category will help us out. -DePiep (talk) 10:00, 21 July 2015 (UTC)
The main previous discussion was in November 2014 here and here. In that, I said I would want to examine current usage in articles, but it hasn't happend because there are lots of things on my todo list. There were large changes to complex code to make 1x2x3 work like 1x2 does, and I wanted to move to other things after that. I don't like discussing changes to long-standing procedures as an abstract exercise when what is required is finding some examples of xx usage in articles and thinking about how they should best be handled (best for the article). In the November 2014 discussion I said xx was used 220 times, and I suppose I should list them somewhere. Also see the new section below. Johnuniq (talk) 22:51, 21 July 2015 (UTC)
bla bla I would want to examine current usage bla bla. Dear Johnuniq. Either you remove non-MOS options from code, or I might use the word "f---". -DePiep (talk) 23:48, 21 July 2015 (UTC)

range of AU with words as output

{{convert|39|to|40|AU}} gives 39 to 40 astronomical units (5.8×109 to 6.0×109 km; 3.6×109 to 3.7×109 mi). I desire the output to use "billions" (e.g. 5.8 to 6.0 billion km) rather than scientific notation, but I've been unable to find a way of doing this. Thryduulf (talk) 23:49, 26 July 2015 (UTC)

I don't know about miles, but for km I surely want billion be diambiguated at first sight. -DePiep (talk) 23:58, 26 July 2015 (UTC)
IMO, especially for astronomical distances, use of the powers is both clearer & more common, not least for the possible confusion over the size of a "billion" (Carl Sagan notwithstanding). TREKphiler any time you're ready, Uhura 00:09, 27 July 2015 (UTC)
{{convert|39|to|40|AU|e9km e9mi|abbr=off}} → "39 to 40 astronomical units (5.8 to 6.0 billion kilometres; 3.6 to 3.7 billion miles)". Jimp 00:15, 27 July 2015 (UTC)
Let's write billion by default. -DePiep (talk) 00:33, 27 July 2015 (UTC)
Did you mean billion (billion = 1e9)? Or million (million = 1e6)? Because billion = 1e6 certainly isn't right. (I think the short scale billion is now dominant enough worldwide in English language usage that we don't need to support billion = 1e12, though I strongly agree that being explicit to readers -- not just editors -- that billion = 1e9 is best.) —Alex (Ashill | talk | contribs) 01:17, 27 July 2015 (UTC)
I meant to say: disambiguate 'billion' at first sight. -DePiep (talk) 01:41, 27 July 2015 (UTC)
It's precisely because there is possible confusion I think using the exponent is a better idea. Not to mention it's far & away the choice in the sources I've seen... TREKphiler any time you're ready, Uhura 01:45, 27 July 2015 (UTC)
When adding convert, I typically try and use the same style as what I'm replacing and the lead section of Pluto uses "billion" not exponents (rightly in my opinion, as it's more accessible to the lay reader). Thryduulf (talk) 09:01, 27 July 2015 (UTC)

Non-breaking space

Please use your browser's view source facility to look at: {{convert|2|km|mi}} 2 kilometres (1.2 mi). You will see that 1.2 and mi are separated by &#160; which is a less-readable equivalent of &nbsp; - non-breaking space. But 2 and kilometres are separated by an ordinary space - why not by an nbsp? Indeed one could even consider putting the entire template expansion within <span style="white-space: nowrap">. — RHaworth (talk · contribs) 13:35, 29 July 2015 (UTC)

Space & breaking rules are described in Help:Convert#Wrapping_and_line_breaking.
{{convert|2|km|mi}} → 2 kilometres (1.2 mi)
By Special:expandTemplate:
2 kilometres (1.2&nbsp;mi)
I don't see the &160; you mention (and I question it is an issue). The "2" is followed by a regular space because the unit is by name (not by symbol). -DePiep (talk) 14:12, 29 July 2015 (UTC)
It is by-design that there is a space between a number and a unit name (so the name might wrap to a different line), but &nbsp; is used between a number and a unit symbol. The last discussion I can find is here. In its typically unhelpful fashion, WP:MOSNUM includes "a space appears between a numeric value and a unit name or symbol" followed by some waffle to ensure everyone is confused. However, long discussions on MOS pages have confirmed that something like "2 kilometres" should normally be allowed to have a line break between the number and the unit on the principle that they are just words in a sentence. Convert has a seldom-used option to force a non-breaking space (adj=j to "join" the number and unit), illustrated below, with some junk before and after to make it easier to see where line wrapping occurs when adjusting the size of the browser window:
  • {{convert|1234|km|mi}} → aaaaa bbbb ccc dddd eeee fffff 1,234 kilometres (767 mi) aaaaa bbbb ccc dddd eeee fffff
  • {{convert|1234|km|mi|adj=j}} → aaaaa bbbb ccc dddd eeee fffff 1,234 kilometres (767 mi)* aaaaa bbbb ccc dddd eeee fffff
MediaWiki replaces &nbsp; with &#160; so the latter is what browsers see—that has nothing to do with convert. In some browsers, pressing Ctrl+U will show the html source and it will include &#160;. As DePiep mentioned, use Special:ExpandTemplates to see exactly what convert outputs, namely &nbsp;. Johnuniq (talk) 02:26, 30 July 2015 (UTC)

How to get capitlization

For Southern Pacific class MC-2 {{convert|5|lbf/in2|kPa|spell=in|lk=on}} five pounds-force per square inch (34 kPa). How do I raise the "five" to upper case? Peter Horn User talk 00:17, 26 July 2015 (UTC)

Simply change "in" to "In": {{convert|5|lbf/in2|kPa|spell=In|lk=on}} Five pounds-force per square inch (34 kPa). Cheers :) — Huntster (t @ c) 00:45, 26 July 2015 (UTC)
Thanks. Peter Horn User talk 15:06, 30 July 2015 (UTC)

Better placement of documentation for temperature differences

I suggest that the documentation for converting temperature differences (|C-change=, |F-change=, etc.) be moved out of the rounding section and into somewhere more sensible. I never would have thought to look in the rounding section to find out how to display temperature differences, and I had to go hunting in the archives where I see it is a somewhat frequently asked question. I have to go catch a flight in a few minutes, otherwise I'd do this myself. Regards, Orange Suede Sofa (talk) 08:17, 30 July 2015 (UTC)

Moved to the top of section Range. Too prominant? It accounts for 3% of ranges using |-|, and about 9% of Celsius to Fahrenheit conversions:
377 articles use "-change"
4155 articles use "|C|"
12536 articles use "|-|"
— CpiralCpiral 20:02, 30 July 2015 (UTC)
Moved it to the "weird units" subsection, I hope you can agree (not actually a range, but a delta). This was one of the old (pre-2014) fossiles in the /doc. Glad to improve this, good catch. -DePiep (talk) 23:55, 30 July 2015 (UTC)
"C-change" is a "unit", sort of, yes. — CpiralCpiral 18:32, 31 July 2015 (UTC)

While we're at it, Gm and gigameter are units, absolutely, so why are they in Numbers? The rest of the material in Numbers is numbers. — CpiralCpiral 18:32, 31 July 2015 (UTC)

It's true that Gm is a unit, but the Numbers section is discussing the G—an SI prefix is a number that scales the value of the unit. The SI prefixes might be discussed somewhere else but I don't think there would be any practical benefit. The Units section might have a brief link to SI prefixes, but moving it there would distract from other information. Johnuniq (talk) 23:26, 31 July 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_July_2015&oldid=1141950133"