Template talk:Convert/Archive June 2013

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 274 km/h spits out 274 kilometers per hour (9028938 mph)? An extra tag? Maybe even 274 A or something? Liters could use it too. Red Slash 05:32, 2 June 2013 (UTC)
 * Use . J IM ptalk·cont 05:49, 2 June 2013 (UTC)
 * ... or  (for "km/h"). J IM ptalk·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 79 LT instead of 79 tons 16 cwt similar to 3 ft. 79 LT 16 cwt does not convert st all yet.


 * doesn't work because whether it's long or short hundredweights is not specified. Use  or . J IM ptalk·cont 01:26, 29 May 2013 (UTC)
 * That was not quite what I had in mind. I was more thinking like 79 LT or even 79 LT, and ah yes, both work. Peter Horn User talk 02:52, 4 June 2013 (UTC)
 * I don't recall where these came from: and  but in all cases those like these should be replaced by 33 LT and 26 LT 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 on to the template. That switches things to the adjectival format you desire. In other words, 22 km seawall produces 22 km sea wall.  Imzadi 1979  →   20:55, 8 June 2013 (UTC)
 * It's singular with a hyphen in all standard dialects of English (use  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.
 * → "22 km"
 * 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 &Prime;), and ft for foot (not ft., the apostrophe ', or the prime &prime;).
 * Non-standard abbreviations should be dotted.
 * J IM ptalk·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. J IM ptalk·cont 04:24, 9 June 2013 (UTC)

Make "disp=or" work
For Ton of refrigeration 12,000 BTU/h instead of 12,000 BTU/h. "disp=or" does not work here. Peter Horn User talk 16:51, 28 May 2013 (UTC)
 * DONE by adding new Template:Convert/LonAonDorSoffper. -Wikid77 03:56, 29 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 LT 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:
 * 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  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   like this:
 * 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.
 * → 27 LT
 * J IM ptalk·cont 03:37, 6 June 2013 (UTC)
 * But the default precision should be adjusted:
 * → 27 LT
 * → 27 LT
 * → 27 LT
 * By default, precision should be 2 decimal places. See thread: "" for amounts modulo 10. -Wikid77 (talk) 09:07, 6 June 2013 (UTC)
 * → 27 LT
 * By default, precision should be 2 decimal places. See thread: "" 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. J IM ptalk·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 + " but will default as 2-decimal precision when qtr zero. -Wikid77 15:16, 9 June 2013 (UTC)
 * I fixed it simply with  since  gives zero. J IM ptalk·cont 05:15, 10 June 2013 (UTC)

Conversions of tonne-force
For Ariane 5: 115 tonne-force instead of 115 tonnes-force (1.13 meganewtons) and 630 tonne-force instead of 630 tonnes-force (6.2 MN 115000 kilogram-force. Let's also have say 115 tonne-force. That would be comparable to 59 LTf and 59 STf that we already have. Then there could be 59 LTf and 59 STf. We also already have 59 LTf and 59 STf. 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)
 * → 115 tf
 * → 115 kgf
 * J IM ptalk·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 tf still does nor redirect to Ton-force. Can that be fixed? Ditto for 115 tonne-force as an alternative. Peter Horn User talk 02:56, 12 June 2013 (UTC)
 * Done. J IM ptalk·cont 05:04, 12 June 2013 (UTC)
 * Thanks a million. Peter Horn User talk 00:38, 13 June 2013 (UTC)
 * This one 115000 kilogram-force 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/cuft, 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/ft3.
 * 1 lb/ft3.
 * 1 lb/ft3
 * 1 lb/ft3
 * 1 kg/m3
 * 1 lb/ft3

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)


 * Created subtemplate for g/m3 units: While we are discussing the issue, I have just created Template:Convert/g/m3 to convert grams per cubic meter with other density units, such as lb/cu ft. Some examples:
 * {&#123;convert|101|g/m3}} &rarr; 101 g/m3
 * {&#123;convert|593|g/m3|lb/cuyd|abbr=on}} &rarr; 593 g/m3
 * {&#123;convert|1.0|lb/cuyd|g/m3|abbr=on}} &rarr; 1.0 lb/cuyd
 * {&#123;convert|1.0|kg/m3|g/m3|abbr=on}} &rarr; 1.0 kg/m3
 * {&#123;convert|1|lb/cuft|g/m3}} &rarr; 1 lb/cuft
 * Related units:
 * Template:Convert/kg/m3, to convert kilograms per cubic metre
 * Template:Convert/g/cm3, to convert grams per cubic centimetre
 * Template:Convert/lb/cuft, to convert pounds per cubic foot
 * Template:Convert/lb/cuyd, to convert pounds per cubic yard
 * 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?
=> 5 acre

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 17898 e6impgal or even 17898 e6impgal instead of 17898 e6impgal. 70,170 ML works nicely. Peter Horn User talk 02:30, 15 June 2013 (UTC)


 * Done. I've also added gigalitre-US-gallon conversions.
 * → "17898 e6impgal"
 * → "17898 e6impgal"
 * J IM ptalk·cont 04:47, 15 June 2013 (UTC)
 * Thanks Jimp. But "lk=on" does not work → "17898 e6impgal" etc. Peter Horn User talk 00:32, 16 June 2013 (UTC)


 * How's that? J IM ptalk·cont 07:23, 16 June 2013 (UTC)

Fractions of long ton
For Upper Nepean Scheme, 2 - 4+1/2 LT otherwise 2 - 4.5 LT. In the second case "|disp=s" does not work, see 2 - 4.5 LT. Peter Horn User talk 00:15, 16 June 2013 (UTC)
 * used to produce "2–4$1/undefined$ 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   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–4$1/undefined$ 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  should give us this but it currently fails and instead gives "2–4$1/undefined$ 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,  → "2–4$1/undefined$ 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   (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. J IM ptalk·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):
 * → 115 to −45 °F
 * 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} &rarr;
 * {convert/3 |115|to|−45|or|-48|°F|°C} &rarr;
 * 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, and others, could 1+1/2 mi 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  is evaluated as   with result:   → . The reason that convert/spell handles some fractions is that some anticipated inputs are handled as special cases. It would be simple to add , but then it wouldn't handle   or  . 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 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   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.   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: 446669320 km and/or 446669320 km. 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} &rarr; 446669320 km
 * For extra spacing, use "disp=x|&amp;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 ,   and   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. J IM ptalk·cont 06:40, 14 June 2013 (UTC)
 * For Eurotunnel Class 9 (0.13 m/s2) instead of (0.13 m/s2) and for British Rail Class 92, (-25 C) instead of (-25 C). Peter Horn User talk 19:25, 18 June 2013 (UTC)


 * Again, you could use  to get the same result formerly achieved by   but note that the slash would have to be the fourth unnamed parameter so it would have to be  or  and  or  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   instead? J IM ptalk·cont 01:06, 20 June 2013 (UTC)
 * In User:Peter Horn/Sandbox 33 ksi 33 ksi would not work but 33 ksi 33 ksi 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?
100 acre

produces 100 acre

?? 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.


 * 100 acre


 * produces 100 acre


 * - 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 (100 sqft). 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 parameter, to work without "-Na" as in.
 * {&#123;convert|4|acre/sandbox2}}   &rarr; 4 acre/sandbox2
 * {&#123;convert|4|acre/sandbox2|lk=on}} &rarr; 4 acre/sandbox2
 * {&#123;convert|4|acre/sandbox2|km2|2}} &rarr; 4 acre/sandbox2
 * {&#123;convert|4|acre/sandbox2|ha|adj=mid|-increase}} &rarr; 4 acre/sandbox2
 * {&#123;convert|2|-|3|acre/sandbox2}}     &rarr; 2 - 3 acre/sandbox2
 * {&#123;convert|2|-|3|acre/sandbox2|disp=flip}} &rarr; 2 - 3 acre/sandbox2
 * {&#123;convert|2|-|3|acre/sandbox2|disp=flip|lk=on}} &rarr; 2 - 3 acre/sandbox2
 * {&#123;convert|0.5|-|1.0|acre/sandbox2|disp=flip|lk=on}} &rarr; 0.5 - 1.0 acre/sandbox2
 * {&#123;convert|0.5|acre/sandbox2}}   &rarr; 0.5 acre/sandbox2
 * {&#123;convert|0.5|acre/sandbox2|adj=1}} &rarr; 0.5 acre/sandbox2
 * {&#123;convert|2/3|acre/sandbox2|ha}}   &rarr; 2/3 acre/sandbox2
 * {&#123;convert/spell |2/3|acre/sandbox2|ha}} &rarr; 2/3 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 "" (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. J IM ptalk·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:
 * {&#123;convert|1|acre/sandbox2|km2}} &rarr; 1 acre/sandbox2
 * {&#123;convert|400|acre/sandbox2|km2}} &rarr; 400 acre/sandbox2
 * {&#123;convert|1+2/3|acre/sandbox2|km2}} &rarr; 1+2/3 acre/sandbox2
 * {&#123;convert|1.0|km2|acre/sandbox2}} &rarr; 1.0 km2
 * {&#123;convert|2.00|km2|acre/sandbox2}} &rarr; 2.00 km2
 * {&#123;convert|2,000|km2|acre/sandbox2|lk=out}} &rarr; 2,000 km2
 * {&#123;convert|0.4047|ha|acre/sandbox2}} &rarr; 0.4047 ha
 * 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). 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: Johnuniq (talk) 04:26, 22 June 2013 (UTC)
 * → 1 acre
 * → 1 acre
 * → 1 acre
 * → 1 ST/acre
 * → 4500 acre ft
 * → 4500 - 4900 acre ft


 * "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:
 * &rarr;
 * 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): By the way, I fixed the way the module handles multiple inputs; examples: 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)
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this
 * → the Lua module does not handle this

Commas
As per MOSNUM, 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 undefined undefined 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 &#124;   ✎  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 &#124; 2¢ &#124; © &#124;  WER  17:14, 21 June 2013 (UTC)
 * we used to have nocomma, but templates like Template:Convert/LoffAoffDnocommaSoff were deleted. Frietjes (talk) 17:54, 21 June 2013 (UTC)
 * Convert/f handles the special formatting: Use Template:Convert/f to control placement of commas:
 * {convert/f |12,345|km|mi}     &rarr;
 * {convert/f |12,345|km|mi|comma=off} &rarr;
 * {convert/f |12,345|km|mi|comma=in} &rarr;
 * 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: 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  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   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 &#124;   ✎  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  or something. This could be set to, say,  for no commas (maybe   to turn off commas iff ∃ 4 digits),   for formatting with gaps,   for spelling numbers out &   for scientific notation (... of course, what do we do if we want scientific notation with gaps ...   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  &   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,   &   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, but if your conversion is in a table you can't use   also. What we really need is a new parameter to flip things around (perhaps  (which I'd had in mind) or (probably better)   (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}     &rarr;
 * {convert/f |875|km|mi|near=25|x3=about} &rarr;


 * {convert/f |12,345|km|mi}     &rarr;
 * {convert/f |12,345|km|mi|comma=off} &rarr;
 * {convert/f |12,345|km|mi|comma=in} &rarr;
 * 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)


 * Added Convert/flip to allow other disp=? options: As typical with Convert being expanded for more units or features every week, I have added another massive extension, by flipping the custom-formatter,, to create with all the same intricate options to customize the output. See below: "". -Wikid77 (talk) 21:31, 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. 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.
 * 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.

Wikid's uses. As I see it there seems to be two drawbacks here.
 * 1)  and   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   nor   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)  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  and   and have, say,   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 (,  &  ) 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  &   (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:,   &. would control the five options above,  would control spelling (we could have ,  ,   ...) &   would control scientific notation.

Perhaps to bring the /2, /3 & /4 versions under the one wing another new parameter, say, could be introduced. Yes, there's also convert/gaps (which I'm suggesting we cover with ). 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} &rarr; 7671 mi
 * {convert/f|7671|mi|km|comma=out|disp=x| (| or} {convert/f|7671|mi|nmi|comma=off|disp=out}) &rarr; )
 * 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  (be it   or   &  ) seems like a good solution (as compared to the more cumbersome   or  ): 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  and   in favour of   (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  (or  ) it won't matter. By the way, I went and added  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)