Jump to content

Template talk:Convert/Archive June 2013

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


ENGVAR

I just had to make a really unfortunate edit to an American English-based article, airplane. The article used this template to convert km/h data into mph, which is fine (more appropriate than mph for this article anyway), but unfortunately it used the British spelling. Is there any way to use this template so that {{convert|274|km/h}} spits out 274 kilometers per hour (9028938 mph)? An extra tag? Maybe even {{convert|274|A|km/h}} or something? Liters could use it too. Red Slash 05:32, 2 June 2013 (UTC)

Use sp=us. JIMp talk·cont 05:49, 2 June 2013 (UTC)
... or abbr=on (for "km/h"). JIMp talk·cont 05:52, 2 June 2013 (UTC)
Jimp, how do I do that? Red Slash 01:38, 3 June 2013 (UTC)
Oops, nevermind, I got it! Red Slash 01:41, 3 June 2013 (UTC)

LT cwt

Foe British Rail Class 24#Train heating 79 long tons (80.267705795199 t)* instead of 79 tons 16 cwt similar to 3 feet 6 inches (1.07 m). 79 long tons (80 t; 88 short tons) 16 cwt[convert: unknown unit] does not convert st all yet.

{{convert|16|cwt}} doesn't work because whether it's long or short hundredweights is not specified. Use {{convert|16|Lcwt}} or {{convert|16|Scwt}}. JIMp talk·cont 01:26, 29 May 2013 (UTC)
That was not quite what I had in mind. I was more thinking like 79 long tons 16 hundredweight (81.1 t) or even 79 long tons 16 hundredweight (81.1 t; 89.4 short tons), and ah yes, both work. Peter Horn User talk 02:52, 4 June 2013 (UTC)
I don't recall where these came from: {{TonCwt to t|33|8|lk=on}} and {{TonCwt to t|26|7|lk-on}} but in all cases those like these should be replaced by 33 long tons 8 cwt (33.9 t; 37.4 short tons) and 26 long tons 7 hundredweight (26.8 t; 29.5 short tons) as the case may be. Peter Horn User talk 23:30, 8 June 2013 (UTC)

Make adj=j work for converting acres

The conversion function adj=j, which prevents text wrap with first number and first word of any fully spelled-out unit of measurement, does not work when converting acres. It displays the error message, Template:Convert/LoffAoffDbSjNa.Wondering55 (talk) 14:48, 8 June 2013 (UTC)

should work now. Frietjes (talk) 16:27, 8 June 2013 (UTC)
Happy days and many thanks.Wondering55 (talk) 19:52, 8 June 2013 (UTC)

problem with grammatical context of results

I was just reading/reviewing Stanley Park and, seeing "A paved 22 kilometres (14 mi) seawall path circles the park" is not correct English, not Canadian English anyways, that should be singular "kilometre" in that sense/context. And if spelling out "kilometre" w/wo plural why is "miles" abbreviated, without a period no less?? There should be a switch in the template for situations like this; I understand "120 kilometres per hour" sure, but "a 40 kilometre trail" should read that way, not a 40 kilometres trail. What version of English is that? It's not North American, is it UK? Maybe a second template for North American and other non-British forms of English is needed; I feel like removing that template usage from that phrase entirely, and supplanting plain-jane straight text. Canadian English is what is to be used in Canadian articles and it looks and sound very wrong. And that abbreviated "mi" has either got to be normal, with a period, or it should be "miles"...or, in the case from the Stanley Park article, "mile".Skookum1 (talk) 18:34, 8 June 2013 (UTC)

Try adding |adj=on to the template. That switches things to the adjectival format you desire. In other words, {{convert|22|km|mi|adj=on}} seawall produces 22-kilometre (14 mi) sea wall. Imzadi 1979 → 20:55, 8 June 2013 (UTC)
It's singular with a hyphen in all standard dialects of English (use |adj=on as mentioned above). The template does allow for US spelling (metre, litre, etc.), that doesn't really concern articles written in Canadian English (but you might like to know that both tonne and metric ton are supported). Abbreviating the converted unit is pretty-much the WP norm but you can override this using |abbr=off.
  • {{convert|22|km|mi|adj=on|abbr=off}} → "22-kilometre (14-mile)"
Wrt dotting the abbreviation, the template follows MOSNUM which gives the following guidance.
  • Standard symbols for units are undotted; e.g. m for the metre (not m.), kg for the kilogram (not kg.), in for the inch (not in., the quotation mark ", or the double prime ″), and ft for foot (not ft., the apostrophe ', or the prime ′).
    • Non-standard abbreviations should be dotted.
JIMp talk·cont 04:11, 9 June 2013 (UTC)
P.S. just being a little pedantic but the seawall doesn't actually go the whole way round. JIMp talk·cont 04:24, 9 June 2013 (UTC)

Make "disp=or" work

For Ton of refrigeration 12,000 BTU/h or 3,517 W instead of 12,000 BTU/h (3,517 W). "disp=or" does not work here. Peter Horn User talk 16:51, 28 May 2013 (UTC)

Comments removed, going to a new section. Peter Horn User talk 01:40, 12 June 2013 (UTC)

Things get more interesting

For Creamy Kate and Trailer I need to convert 27 tons 14 cwt 0 qtrs, 27 long tons 14 hundredweight (28.1 t; 31.0 short tons) 0 qtrs. Peter Horn User talk 03:26, 4 June 2013 (UTC)

You want the ton/cwt/qtr as an input (not an output)? I don't think the template can do a conversion with more than two units for an input or output multiple. The module I am writing cannot handle more than two units in an input multiple, but it can do more than two for output, as in this demo:
{{convert/sandboxlua|123.4|km|miydftin}} → 123.4 kilometres (76 mi 1,191 yd 2 ft 8 in)
I don't know a way to get what you want as an input, but if the value is zero quarters, you could fudge it by using disp=x to specify fixed text, although it would probably be more straightforward to just write the text you want, doing the conversion manually. As a matter of interest, the module works with disp=x like this:
{{convert/sandboxlua|27|LT|14|Lcwt|t ST|disp=x| 0 qtrs (|)}} → 27 long tons 14 hundredweight 0 qtrs (28.1 t; 31.0 short tons)
In short, I don't have a useful suggestion—the above is just my understanding of the limitations. Johnuniq (talk) 01:41, 6 June 2013 (UTC)
I've got it working.
  • {{convert|27|LT|14|Lcwt|0|qtr|t ST|1}} → 27 long tons 14 hundredweight 0 quarters (28.1 t; 31.0 short tons)
JIMp talk·cont 03:37, 6 June 2013 (UTC)
But the default precision should be adjusted:
  • {{convert|27|LT|14|Lcwt|0|qtr|t ST}} → 27 long tons 14 hundredweight 0 quarters (28.14 t; 31.02 short tons)
  • {{convert|27|LT|14|Lcwt|1|qtr|t ST}} → 27 long tons 14 hundredweight 1 quarter (28.16 t; 31.04 short tons)
  • {{convert|27|LT|14|Lcwt|3|qtr|t ST}} → 27 long tons 14 hundredweight 3 quarters (28.18 t; 31.07 short tons)
By default, precision should be 2 decimal places. See thread: "#Default precision with composite inputs" for amounts modulo 10. -Wikid77 (talk) 09:07, 6 June 2013 (UTC)
I agree that the default should be two decimal points since the input can be assumed accurate to the nearest quarter (i.e. 2 stone or 13 kg). Probably a little tweaking would fix that. JIMp talk·cont 03:38, 9 June 2013 (UTC)
Reset formula for "j" in Template:Convert/and/Lcwtqtr, to handle decimal qtr=1.3, as "|j=1.103823772 +{{#ifexpr:floor( {{{5|0}}} )={{{5|0}}} |0|1}}" but will default as 2-decimal precision when qtr zero. -Wikid77 15:16, 9 June 2013 (UTC)
I fixed it simply with |j=1.103823772 since {{order of magnitude|0}} gives zero. JIMp talk·cont 05:15, 10 June 2013 (UTC)

Conversions of tonne-force

For Ariane 5#Vehicle Description: 115 tonnes-force (1.13 MN) instead of 115 tonnes-force (1.13 meganewtons) and 630 tonnes-force (6.2 MN) instead of 630 tonnes-force (6.2 MN 115,000 kilogram-force[convert: unknown unit]. Let's also have say 115 tonnes-force (113 long tons-force). That would be comparable to 59 long tons-force (587.9 kN) and 59 short tons-force (524.9 kN) that we already have. Then there could be 59 long tons-force (59.95 tf) and 59 short tons-force (53.52 tf). We also already have 59 long tons-force (132,200 lbf) and 59 short tons-force (118,000 lbf). Peter Horn User talk 04:53, 18 May 2013 (UTC) Peter Horn User talk 18:58, 19 May 2013 (UTC)

Similarly kilogram-force also needs conversions. Peter Horn User talk 19:13, 19 May 2013 (UTC)
{{convert|115|tf|MN|lk=on}} → 115 tonnes-force (1.13 MN)
{{convert|115|kgf}} → 115 kilograms-force (1,130 N; 250 lbf)
JIMp talk·cont 02:19, 21 May 2013 (UTC)
Thanks Jimp for ton-force, a truly elegant solution. Peter Horn User talk 01:13, 3 June 2013 (UTC)
I just noticed that the "tf" in 115 tonnes-force (1.13 MN) still does nor redirect to Ton-force#Tonne-force. Can that be fixed? Ditto for 115 tonnes-force (1.13 MN) as an alternative. Peter Horn User talk 02:56, 12 June 2013 (UTC)
Done. JIMp talk·cont 05:04, 12 June 2013 (UTC)
Thanks a million. Peter Horn User talk 00:38, 13 June 2013 (UTC)
This one 115,000 kilogram-force[convert: unknown unit] is not yet resolved. Peter Horn User talk 00:43, 13 June 2013 (UTC)
Well, it is now. Peter Horn User talk 01:09, 14 June 2013 (UTC)

Matter density

It would be helpful to have conversions from lb/ft3 <=> g/m3, at different scales. Thanks for listening! Lfstevens (talk) 15:33, 12 June 2013 (UTC)-

we have 1 lb/cu ft (0.016 g/cm3), and could probably add g/m3 if there is a need for it. Frietjes (talk) 16:59, 12 June 2013 (UTC)
Oh...I found
  • 1 lb/cu ft (16 kg/m3).
  • 1 lb/cu ft (16,000 g/m3).
  • 1 lb/cu ft (16,000 μg/cm3)
  • 1 lb/cu ft (16 mg/cm3)
  • 1 kg/m3 (0.0010 g/cm3)
  • 1 lb/cu ft (0.00058 lb/cu in)

I hadn't tried them, because I couldn't find it in the doc. No oz, though. Thanks! Lfstevens (talk) 19:40, 12 June 2013 (UTC)

{{convert|101|g/m3}} → 101 grams per cubic metre (0.170 lb/cu yd)
{{convert|593|g/m3|lb/cuyd|abbr=on}} → 593 g/m3 (1.000 lb/cu yd)
{{convert|1.0|lb/cuyd|g/m3|abbr=on}} → 1.0 lb/cu yd (590 g/m3)
{{convert|1.0|kg/m3|g/m3|abbr=on}} → 1.0 kg/m3 (1,000 g/m3)
{{convert|1|lb/cuft|g/m3}} → 1 pound per cubic foot (16,000 g/m3)
Related units:
Before a crisis arises, we should create the typical units. -Wikid77 (talk) 19:53, 12 June 2013 (UTC)
Thanks so much. I'm happy to update the doc, unless you want to. Lfstevens (talk) 20:07, 12 June 2013 (UTC)
Took a shot at the doc. Lfstevens (talk) 05:33, 14 June 2013 (UTC)

Am I doing this wrong?

{{convert|5|acre|ha|disp=output only|abbr=out|1}}

=> 2.0 ha

NB works fine for other units

John of Cromer in transit (talk) mytime= Thu 11:08, wikitime= 10:08, 13 June 2013 (UTC)

Just omit "|abbr=out" because that will happen by default. Johnuniq (talk) 11:32, 13 June 2013 (UTC)
How bizarre! John of Cromer in transit (talk) mytime= Thu 15:48, wikitime= 14:48, 13 June 2013 (UTC)
added the missing redirect. Frietjes (talk) 18:15, 13 June 2013 (UTC)

conversions of megalitre (ML or Ml)

For Upper Nepean Scheme#Nepean Dam 17,898×10^6 imp gal (81,370 ML; 2.1495×1010 US gal) or even 17,898×10^6 imp gal (81,370,000 m3; 2.1495×1010 US gal) instead of 17,898×10^6 imp gal (8.137×1010 L; 2.1495×1010 US gal). 70,170 ML (1.544×1010 imp gal; 1.854×1010 US gal) works nicely. Peter Horn User talk 02:30, 15 June 2013 (UTC)

Done. I've also added gigalitre-US-gallon conversions.
  • {{convert|17898|e6impgal|Gl USgal|abbr=on}} → "17,898×10^6 imp gal (81.37 Gl; 2.1495×1010 US gal)"
  • {{convert|17898|e6impgal|GL USgal|abbr=on}} → "17,898×10^6 imp gal (81.37 GL; 2.1495×1010 US gal)"
JIMp talk·cont 04:47, 15 June 2013 (UTC)
Thanks Jimp. But "lk=on" does not work {{convert|17898|e6impgal|ML USgal|abbr=on|lk=on}} → "17,898×10^6 imp gal (81,370 ML; 2.1495×1010 US gal)" etc. Peter Horn User talk 00:32, 16 June 2013 (UTC)
How's that? JIMp talk·cont 07:23, 16 June 2013 (UTC)

Fractions of long ton

For Upper Nepean Scheme#Cataract Dam, {{convert|2|-|4+1/2|LT|t ST|disp=s}} otherwise {{convert|2|-|4.5|LT|t ST|disp=s}}. In the second case "|disp=s" does not work, see 2–4.5 long tons (2.0–4.6 t; 2.2–5.0 short tons). Peter Horn User talk 00:15, 16 June 2013 (UTC)

{{convert|2|-|4+1/2|LT|t ST|disp=s}} used to produce "2–41⁄2 long tons/2.0–4.6 tonnes; 2.2–5.0 short tons". Is that what we want: a slash then a semicolon? I would say that neither of these punctuation marks are appropriate. The slash normally indicates division, for this reason disp=s has been removed (see above). The normal function of a semicolon, on the other hand, is to separate clauses (normally independent ones) though it can also be used as a kind of "supercomma" (e.g. in a list where the items already contain commas). I suggest we get rid of these semicolons as well. What we really should be aiming at would be "2–41⁄2 long tons, 2.0–4.6 tonnes or 2.2–5.0 short tons", i.e. three things listed as we normally would list them in English. Ideally {{convert|2|-|4+1/2|LT|t ST|disp=or}} should give us this but it currently fails and instead gives "2–41⁄2 long tons or 2.0–4.6 tonnes; 2.2–5.0 short tons" (which doesn't make much sense either). I had been working on a rewrite of the template (2011–2012) which fixed this problem; however, this rewrite was based on old-school template coding but now we have the option making things much more efficient by using Lua so the 2011–2012 version has more or less been mothballed. Still, {{convert|2|-|4+1/2|LT|t ST|disp=or}} → "2–41⁄2 long tons, 2.0–4.6 tonnes or 2.2–5.0 short tons" is what we should be aiming at (rather that a muddle of misplaced slashes & semicolons) in the meantime I suggest either using disp=or (and just wait till it's fixed) or type the conversion in as plain text (i.e. don't use the template). Sorry I can't really be much more helpful as yet. JIMp talk·cont 06:58, 16 June 2013 (UTC)

Minus

In the Boeing 787 article I just came accross a use where minus was input but minus-hyphen was output.

—Lgfcd (talk) 04:42, 20 June 2013 (UTC)
The article is Boeing 787 Dreamliner and the convert is (input is minus 45; output uses a hyphen):
{{convert|115|to|−45|°F|°C|abbr=on}} → 115 to −45 °F (46 to −43 °C)
Johnuniq (talk) 07:35, 20 June 2013 (UTC)
  • Use Convert/2 or Convert/3: For those cases, use {convert/2} or {convert/3} rather than {convert}.
  • {convert/2 |115|to|−45|°F|°C} → {{convert/2|115|to|−45|°F|°C}}
  • {convert/3 |115|to|−45|or|-48|°F|°C} → {{convert/3|115|to|−45|or|-48|°F|°C}}
In general, {convert/2} allows more options. -Wikid77 (talk) 12:55, 20 June 2013 (UTC)

Present or current output of convert/spell not elegant if not undesirable

For TAZARA Railway#Construction, and others, could {{convert/spell|1+1/2|mi|km|1|unit=1}} one and a half miles (2.4 km)* be made to read one and one half mile(s) (2.4km)? Peter Horn User talk 13:33, 21 June 2013 (UTC)

That's tricky because the difficult work is done by Module:ConvertNumeric (called from {{spellnum}}), and that does not handle fractions. If given a fraction, spellnum evaluates it as an expression, then spells the result. Therefore 1+1/2 is evaluated as 1.5 with result: {{spellnum|1+1/2}} → one point five. The reason that {{convert/spell}} handles some fractions is that some anticipated inputs are handled as special cases. It would be simple to add 1+1/2, but then it wouldn't handle 1+1/4 or 2+1/2. Trying to handle everything leads to enormous complexity, and unless spelled fractions are needed in many locations, I don't think it would be worth extending ConvertNumeric to handle them. OTOH, ConvertNumeric handles some pretty exotic values, so Dcoetzee (its author) may not need much encouragement to add fractions. Johnuniq (talk) 00:27, 22 June 2013 (UTC)
Last year when I dusted old {{spellnum}}{{numtext}} off I'd intended to construct fractions using its ordinal function (plus some special code for "half" & "quarter"). The plan was to put the faction together in a convert subtemplate using {{spellnum}}{{numtext}} to spell out the whole part, the numerator and the denominator (as "half"/halves", "quarter"/"quarters" or an ordinal). Of course, this was before Lua came along. ...1+1/2|mi... was going to be "one and a half miles". I'd got it working in a sandbox version, it was a little complex but it should be simpler with Lua. I think it's worth doing. Jimp 05:02, 22 June 2013 (UTC)
OK, I have made a request at Dcoetzee's talk. Johnuniq (talk) 11:12, 22 June 2013 (UTC)

disp=/ and disp=s

I don't recall where this applies but here they are: {{Convert|446669320|km|AU|4|abbr=on|lk=out|disp=/}} and/or 446,669,320 km (2.9858 AU)*. Peter Horn User talk 01:44, 12 June 2013 (UTC)

  • Jimp has deleted many of the slash "/" options, so using "disp=s" is trouble now, and instead use "disp=x|/|" to insert a slash as follows:
  • {Convert|446669320|km|AU|4|abbr=on|lk=out|disp=x|/||4} → 446,669,320 km/2.9858 AU
For extra spacing, use "disp=x|&nbsp;/ |" or similar spacing. -Wikid77 (talk) 11:10, 12 June 2013 (UTC)
The use of the slash as separator between units has been seen as problematic for about as long as the template has been around (pick through the archives). The use of a symbol which in the context of numbers & units normally signifies division has been brought into question over and over. It was decided a while back that disp=s, disp=/ and disp=slash be considered deprecated and that mention of them be removed from the doc. Now these options have been disabled. You can still get the template to use slashes (as Wikid has shown) but I'd strongly recommend not doing so, I'd suggest "or" or a comma instead. JIMp talk·cont 06:40, 14 June 2013 (UTC)
For Eurotunnel Class 9#Background and design (0.13 m/s2 (0.43 ft/s2)*) instead of (0.13 m/s2 (0.43 ft/s2)) and for British Rail Class 92#Gallery, (−25 °C (−13 °F)*) instead of (−25 °C (−13 °F)). Peter Horn User talk 19:25, 18 June 2013 (UTC)
Again, you could use disp=x|/ to get the same result formerly achieved by disp=s but note that the slash would have to be the fourth unnamed parameter so it would have to be {{convert|0.13|m/s2|2|abbr=on|disp=x|/}} or {{convert|0.13|m/s2|ft/s2|abbr=on|disp=x|/}} and {{convert|-25|C|F|disp=x|/}} or {{convert|-25|C|0|disp=x|/}} but do you really want a slash? Would you want "0.13 m/s2/0.43 ft/s2"? This exemplifies, I think, why the slashes had to go. How about using disp=or instead? JIMp talk·cont 01:06, 20 June 2013 (UTC)
In User:Peter Horn/Sandbox#Imperial {{convert|33|ksi|MPa|abbr=values|disp=or}} 33 or 230 would not work but {{convert|33|ksi|MPa|abbr=on|disp=or}} 33 ksi or 230 MPa does work. Eliminating disp=s really did a number. Peter Horn User talk 01:09, 24 June 2013 (UTC)

Now what am I doing wrong?

{{convert|100|acre|ha|abbr=out|disp=flip|1}}

produces 40.5 hectares (100 acres)

?? John of Cromer (talk) mytime= Sat 16:35, wikitime= 15:36, 22 June 2013 (UTC)

acres are not supposed to be abbreviated. I fixed it for you by making a redirect that ignores the abbr=out. Frietjes (talk) 15:56, 22 June 2013 (UTC)
I think I'm confused by the nomenclature. I use "out" to mean the part I haven't supplied; here it seems to mean "right-hand-side" (which was the input before flip). So I guess I need to specify abbreviation of input.
{{convert|100|acre|ha|abbr=in|disp=flip|1}}
produces 40.5 ha (100 acres)
- that's what I want! John of Cromer (talk) mytime= Sat 17:16, wikitime= 16:16, 22 June 2013 (UTC)
yes, flip makes it confusing. right or wrong, the convention that has been used for sometime is that 'out' is the second unit and 'in' is the first. you can check this with other units (9.3 square metres (100 sq ft)). Frietjes (talk) 16:58, 22 June 2013 (UTC)
This is a strange way of setting things up. Perhaps we could sort this out somehow. Jimp 10:00, 24 June 2013 (UTC)

Convert/acre without "-Na" suffix

I think it is time to change Template:Convert/acre to drop the internal "-Na" suffix, and use the same subtemplates as other unit-codes, because people have been creating more and more of the "-Na" forks for rare options, such as adj=1 or such. All options seem to have been fixed to handle the missing {{{u}}} parameter, to work without "-Na" as in {{Convert/acre/sandbox2}}.

There were a few rare exceptions, but I think most options work. When a rare option fails, it will display singular "acre" when plural is needed or else "{{{u}}}" (rather than "acre"), but we can probably find a way to fix those. -Wikid77 (talk) 23:56, 19 June/09:42, 25 June 2013 (UTC)

It would be a step in the right direction. JIMp talk·cont 01:07, 20 June 2013 (UTC)
  • Checking Convert/acre usage in 69,017 pages: To determine the impact on the current articles, I ran wikisearches to count 104,671 pages using the word "acre" while 69,000 (66%) use Convert/acre, as 30,352 (44%) with "km2". I collected a sample of 3,000 pages containing Convert/acre, to count various parameter combinations, such as "acre|ha" in 21% of cases with "ha|acre" in 1% but 78% do not mention "ha" with acres. Nearly 3% of cases use option "lk" with acre: 45 of 3,000 use "lk=on" (1.6%) or 10 "lk=out" (0.4%) or 7 "lk=in" (0.3%) or 5 "lk=off" (0.3%). Examples:
Those examples are typical of over half of pages using Convert/acre. -Wikid77 (talk) 12:55, 20 June 2013 (UTC)

My tests include the following unlikely but plausible combinations (currently, the template does not handle these, but Module:Convert does).

  • {{convert|1|acre|sqyd|abbr=in|disp=flip}} → 4,800 sq yd (1 acre)
  • {{convert|1|acre|sqyd|abbr=out|disp=flip}} → 4,800 square yards (1 acre)
  • {{convert|1|acre|sqyd|abbr=on|disp=flip}} → 4,800 sq yd (1 acre)
  • {{convert|1|ST/acre|lk=on}} → 1 short ton per acre (2.2 t/ha)

It's not "acre", but I have wondered whether the fact that "US gal" is merely "gal" in the second of the following is intentional:

  • {{convert|4500|acre ft|e9USgal e6m3}} → 4,500 acre-feet (1.5×10^9 US gal; 5.6×10^6 m3)
  • {{convert|4500|-|4900|acre ft|e9USgal e6m3}} → 4,500–4,900 acre-feet (1.5×10^9–1.6×10^9 US gal; 5.6×10^6–6.0×10^6 m3)

Johnuniq (talk) 04:26, 22 June 2013 (UTC)

"gal" instead of "US gal" would not be intentional (MOSNUM would not be pleased). About a year ago we got rid of a whole bunch of special subtemplates for imperial & US gallons/pints/fluid ounces/etc. These old subtemplates added the "US"/"U.S."/"imp"/"imperial". It was set up this way so that the "US" bit could link to the article on US customary units and the "gal" bit could link to the gallon article. Like the -Na subtemplates these were getting cumbersome so we got rid of them. The intention had been to resurrect this dual linking in the new version of the template I was working on (but it seems that Lua probably is a better way to go). Jimp 05:10, 22 June 2013 (UTC)
  • Use Convert/flip for acre and sqyd: The example would be:
So, by using {convert/flip}, then many combinations of options would be supported without creating more special subtemplates for "-Na" suffix. -Wikid77 (talk) 09:42, 25 June 2013 (UTC)

Lua version

The Lua module gives these results (the first is for the case reported in the Minus section just below):

  • {{convert/sandboxlua|115|to|−45|°F|°C|abbr=on}} → 115 to −45 °F (46 to −43 °C)
  • {{convert/sandboxlua|4|acre}} → 4 acres (1.6 ha)
  • {{convert/sandboxlua|4|acre|lk=on}} → 4 acres (1.6 ha)
  • {{convert/sandboxlua|4|acre|km2|2}} → 4 acres (0.02 km2)
  • {{convert/sandboxlua|4|acre|ha|adj=mid|-increase}} → 4-acre-increase (1.6 ha)
  • {{convert/sandboxlua|2|-|3|acre}} → 2–3 acres (0.81–1.21 ha)
  • {{convert/sandboxlua|2|-|3|acre|disp=flip}} → 0.81–1.21 hectares (2–3 acres)
  • {{convert/sandboxlua|0.5|acre}} → 0.5 acres (0.20 ha)
  • {{convert/sandboxlua|0.5|acre|adj=1}} → 0.5 acres (0.20 ha)*
  • {{convert/sandboxlua|2/3|acre|ha}} → 2⁄3 acre (0.27 ha)
  • {{convert/spell|2/3|acre|ha}} → the Lua module does not handle this

By the way, I fixed the way the module handles multiple inputs; examples:

  • {{convert/sandboxlua|27|LT|14|Lcwt|1|qtr|t ST}} → 27 long tons 14 hundredweight 1 quarter (28.16 t; 31.04 short tons)
  • {{convert/sandboxlua|1|mi|120|yd|2|ft|10|in|m}} → 1 mile 120 yards 2 feet 10 inches (1,719.94 m)

There are lots of other minor issues which the module handles well, and it would great if people would consider testing the module. For example, there are lots of testcases and I would like to know if the results from the module are satisfactory, or whether the differences from the template indicate problems. Johnuniq (talk) 08:04, 20 June 2013 (UTC)

Commas

As per Wikipedia:MOSNUM#Delimiting (grouping_of_digits), Numbers with four digits to the left of the decimal point may or may not be delimited (e.g. 1250 or 1,250). Personally I strongly dislike using a delimiter for four-digit numbers, but {{Convert}} gives me no option. I would love to be able to turn this off so as to enable a uniform style in pages I edit. Thanks,  Mr.choppers | ✎  16:51, 21 June 2013 (UTC)

  • When dealing only with 3 and 4 digit numbers, the comma is very distracting and ugly. There should be some way to exclude the comma in cases like auto engines where there is never a 5 digit number so a comma is never needed, even if it takes a separate template. Perhaps someone will make a new template, or I guess I could learn how if forced, that won't add the comma to a 4 digit number. Dennis Brown | 2¢ | © | WER 17:14, 21 June 2013 (UTC)
  • {convert/f |12,345|km|mi}                  → 12,345 kilometres (7,671 mi*)
  • {convert/f |12,345|km|mi|comma=off} → 12345 kilometres (7671 mi*)
  • {convert/f |12,345|km|mi|comma=in} → 12,345 kilometres (7671 mi*)
The "new world" (or "next generation") of {Convert} is {Convert/f}. -Wikid77 (talk) 18:09, 23 June 2013 (UTC)

Sorry to bang the Lua drum again, but it is much easier to handle tricky details in a module. Here is an example using the current module:

  • {{convert/sandboxlua|123456789|mm|m}} → 123,456,789 millimetres (123,456.789 m)
  • {{convert/sandboxlua|123456789|mm|m|abbr=comma}} → 123,456,789 millimetres (123,456.789 m)*
  • {{convert/sandboxlua|123456789|mm|m|adj=nocomma}} → 123,456,789 millimetres (123,456.789 m)*
  • {{convert/sandboxlua|123456789|mm|m|disp=nocomma}} → 123,456,789 millimetres (123,456.789 m)*

There are three ways to turn off commas because I have tried to implement all the options handled by the current template. There is no way to specify that only the input (or only the output) have no commmas, or that only four-digit numbers have no commas, however stuff like that could be added. Johnuniq (talk) 00:09, 22 June 2013 (UTC)

Ideally there should be one way to turn off commas (and should not be any of those formerly used). Jimp 04:43, 22 June 2013 (UTC)
Do you have a suggested syntax? Positive options are good, so perhaps comma=X where X is "on" (default), or "in", or "out", or "off". However, I can't think of a good way to say "comma if more than four digits", so perhaps nocomma=X where "nocomma=off" is the default, and "nocomma=4" means no comma if four digits before decimal mark. Johnuniq (talk) 05:07, 22 June 2013 (UTC)
I don't know what's best - for me I reckon that the default ought to be no commas for four leading digits, and commas for five and above - but that's a decision that is clearly not up to me as it would affect all kinds of users not privy to this conversation. What if there was a parameter for "comma so-so", allowing for commas only in cases of five or more leading digits. I would call it adj=somecom.  Mr.choppers | ✎  07:48, 22 June 2013 (UTC)

What I had had in mind was something to deal with the four or five different ways we might want a number displayed. Perhaps a parameter called format or something. This could be set to, say, nocomma for no commas (maybe nocomma4 to turn off commas iff ∃ 4 digits), gap for formatting with gaps, spell for spelling numbers out & scinote for scientific notation (... of course, what do we do if we want scientific notation with gaps ... scigap or a completely different parameter to control scientific notaion?). This is what the old new version (i.e. the one I had been working on until I realised that Lua was probably the way to go) was going to do. Also I was going to introduce format_in & format_out in case the input & output were to be formatted differently (say spelling out the input & formatting the output with gaps).

The thing is that we've been using disp, abbr & adj for things that they were not really intended to do. This was more or less forced by the way the template was set up back in 2007 (before these different options had been dreamt of) ... sorry about that. This, of course, meant that the parameters couldn't actually do their job. For example, if you want to flip the input & output, you can use disp=flip, but if your conversion is in a table you can't use disp=table also. What we really need is a new parameter to flip things around (perhaps flip=on (which I'd had in mind) or (probably better) order=flip (which I think was Wikid's suggestion)). So we ended up with three different ways of omitting the comma.

This clunky old template needs a revamp but I'm suggesting backwards compatibility with the old convoluted ways of use need not be a priority. We just need someone to unleash their pet bot on the 'pedia and simplify things once & for all. Jimp 08:41, 22 June 2013 (UTC)

I am currently wondering about each of these: {{convert/2}} ∙ {{convert/3}} ∙ {{convert/4}} ∙ {{convert/spell}} (are there any others!?). I haven't looked in any detail yet, but I think I can manage convert/2 and convert/spell reasonably soon. However, convert/3 and 4 look tricky—in principle, the module could simply recognize the inputs and cope, but the complexity is already high and I would prefer to leave that for the future. Ideally there would be a tricky way of moving the current {{convert}} to a new location, then inserting the new name in convert/3 and 4, but I suspect that might be much more complex than what I hope (I'm saying that on the uninformed guess that convert/3 and 4 would not work if the current template were replaced with {{convert/sandboxlua}}). The Lua module would need to be highly compatible with the current templates for any initial release, but your proposal to redesign the parameters is attractive. Johnuniq (talk) 10:28, 22 June 2013 (UTC)
  • Convert/f handles the special formatting of commas/adjectives: Use Template:Convert/f, created way back in February 2013‎, to control placement of commas or adjectives or mid-text, or other new features, such as rounding to nearest 25 or 50 or 250:
  • {convert/f |875|km|mi|x1=precise|1}          → 875 precise kilometres (543.7 mi*)
  • {convert/f |875|km|mi|near=25|x3=about} → 875 kilometres (about 550 mi*)
  • {convert/f |12,345|km|mi}                  → 12,345 kilometres (7,671 mi*)
  • {convert/f |12,345|km|mi|comma=off} → 12345 kilometres (7671 mi*)
  • {convert/f |12,345|km|mi|comma=in} → 12,345 kilometres (7671 mi*)
The New World (or "next generation") of {Convert} is {Convert/f}; however, we need to keep simplifying the underlying structure of Convert, such as changing the unit-code "acre" to drop the "-Na" suffix. Then {Convert/f} can be used in more pages to provide simple customized formatting, plus all types of new features to be added in the future. -Wikid77 (talk) 18:09, 23 June 2013 (UTC)

MOSNUM allows for a few different number formatting choices as long as we're consistent throughout the page. Those applicable to quantities/measurements are the following.

  1. We have a choice between formatting with gaps or with commas.
  2. We have a choice as to whether four-digit numbers are formatted or not.

Ideally we should be aiming at the simplest way to do this, simplest for the editor not the template coder. It seems to me that the simplest solution would be to have one parameter to do this.

Wikid's {{conver/f}} uses comma. As I see it there seems to be two drawbacks here.

  1. comma=in and comma=out will fail where we have multiple outputs with (as least) one of four digits and (as least) one of more. If we want, for example, "7671 miles (12,345 km or 6666 nmi)" or "10,000 miles (16,000 km or 8700 nmi)" neither comma=in nor comma=out will give it to us. Instead we want something to take into account the number of digits (so as to turn commas off for four digit numbers).
  2. comma simply turns commas on or off but if we want gaps instead we've got to do something completely different.

The solution to the first problem could be to forget about comma=in and comma=out and have, say, comma=>4 to get rid of commas for four-digit numbers only. For the second problem it seems to be that the best solution would be to have the same parameter replace commas with gaps (but then wouldn't we want a better name?). I'm suggesting one parameter to cover all the following options.

  1. Group digits by threes using commas. (This would be the default.)
  2. Group digits by threes using commas but only for 10,000 and above.
  3. Group digits by threes using gaps.
  4. Group digits by threes using gaps but only for 10,000 and above.
  5. Don't format at all. (This is not MOS compliant but may be useful for producing raw numbers for further calculations.)

Above I suggested three new parameters (format, format_in & format_out) which would control the five options above plus scientific notation and spelling out of numbers. It would probably be better to use different parameters for scientific notation and spelling out of numbers and not use format_in & format_out (they wouldn't be needed because formatting of numerals should be consistent throughout the page). So instead of those three these three would be better: format, spell & scinote. format would control the five options above, spell would control spelling (we could have spell=on, spell=in, spell=out ...) & scinote would control scientific notation.

Perhaps to bring the /2, /3 & /4 versions under the one wing another new parameter, say range, could be introduced. Yes, there's also {{convert/gaps}} (which I'm suggesting we cover with format). Jimp 12:35, 24 June 2013 (UTC)

  • For rare exceptions use "disp=out" or hand-coded results: We have always recommended that people run {Convert} to see the numbers, and then hand-code the results for rare cases. However, for commas we could have "comma=5" to insert commas at 5-digit size, but internally, {Convert/f} formats the entire 2-number result, not each number separately. Instead, perhaps have a usage note to recommend "disp=out" for each number separately. Hence:
  • {convert|7671|mi|km nmi} → 7,671 miles (12,345 km; 6,666 nmi)
  • {convert/f|7671|mi|km|comma=out|disp=x| (| or} {convert/f|7671|mi|nmi|comma=off|disp=out})
    → 7671 miles (12,345 km* or 6666 nmi*)
By using "disp=out" then the editor still gets the calculation, but the formatting of commas must be specified for each result separately. Otherwise just hand-code the result. We want to avoid too many 4-digit decommaed amounts which can cause confusion with 4-digit years: "The goal was one per year of date, so they had 2,010 samples in 2010, and then 2,011 2011 samples" or similar text which I have seen in articles. -Wikid77 (talk) 09:42, 25 June 2013 (UTC)

Yes, hand-coding rare stuff that the template can't handle is usually a good idea but in a perfect world we'd want to reduce the stuff that the template fails on to a minimum. So, looking to the future, I'm wondering what the best solution would be given the opportunity to rewrite the template from scratch. Setting the parameter to 5 (be it comma=5 or format=5 & format=gaps5) seems like a good solution (as compared to the more cumbersome >4 or 5&up): short & to-the-point; people will have to see the doc to understand what's going on anyway. Oh, not wanting to be a drag or anything but I've thought of another reason to retire out and in in favour of 5 (or something) in this case. Say you're adding the template to an infobox (or any other template for that matter), you might not know how many digits you'll be dealing with for inputs and/or outputs. By using format=5 (or comma=5) it won't matter. By the way, I went and added format=off to this template to get rid of all commas (option 5 in the list above); as long as there are only numbers less than 10,000 (and more than −10,000) or the output is to be further munched on it'll comply with MOSNUM. Jimp 01:41, 26 June 2013 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_June_2013&oldid=1090587070"