Template talk:Convert/Archive June 2014

Writing "7 feet 0 1/4 inch"?
About writing the "0" in "7 ft $0 1/4$ in": I have put the question at WT:MOS. Please visit that one if you know more. -DePiep (talk) 14:26, 2 June 2014 (UTC)
 * I commented there, but it might be worth recording what convert currently does here:
 * → 84.25 in
 * → 84.25 in
 * Johnuniq (talk) 23:58, 2 June 2014 (UTC)

km2
Can anyone change "km2" to "km²"? Thanks in advance. --81.47.192.236 (talk) 08:36, 12 June 2014 (UTC)


 * It was changed from "km²" to "km2" years ago in conformance with the Manual of Style which states "Format exponents using, not special characters.". Jimp 11:03, 12 June 2014 (UTC)


 * Perhaps changing "km2" to "km2".  Stepho  talk 14:07, 12 June 2014 (UTC)

Add foe (unit) ?
May I request that convert support foe (unit) as a (non-SI metric) unit of energy? It may be useful in article Supernova, articles linked via navbox Supernovae, and some of the 180+ articles in Category:Supernovae and its sub-categories. Unician &nabla; 10:48, 15 June 2014 (UTC)
 * That already exists (see the full list). For example:
 * → 1 foe
 * If there is something that doesn't work as needed, please give an example. Johnuniq (talk) 11:40, 15 June 2014 (UTC)
 * Thank you for that information &mdash; I hadn't seen that full list, and the lists that I had seen didn't include &ldquo;foe&rdquo;.
 * &rarr; 1 foe
 * &rarr; 1 foe
 * Yes, that works fine. The default output style 1020 YJ is a bit odd, but that's easy enough to deal with, and not inherently the fault of the template.  Thanks again!  Unician &nabla; 16:47, 15 June 2014 (UTC)
 * Minor note: in 1 foe {convert} links to Foe (unit of energy), which is a redirect to content page foe (unit). The redirect is unnecessary, "foe (unit)" is a good disambiguation already for a long time (keeps disambiguation term simple & clear). -DePiep (talk) 13:30, 16 June 2014 (UTC)
 * Thanks, I hadn't noticed that, but have noted it now, and will fix it on the next upgrade. I should probably get a list of all the links and check them in some automated way. Johnuniq (talk) 00:02, 17 June 2014 (UTC)

Miles plus yards
currently, is there a reason why the first two are not generating an error, or the same as the third? seems as though "yard" and "yards" are valid units, so, this would be a bug? Frietjes (talk) 18:06, 12 June 2014 (UTC)
 * &rarr; 1 mile (1.6093440000000 km)
 * &rarr; 1 mile (1.6093440000000 km)
 * &rarr; 1 mile 70 yards (8.32 furlongs)
 * &rarr; 1 mile (1,800 yd)
 * &rarr; 1 mile (1,800 yd)
 * &rarr; 1 mile (1,800 yd)
 * There are two issues. The first is seen in the unit definitions for the length "Input multiples". Only "yd" is defined as being a subdivision of "mi". The module does not lookup "yard" and see that it is an alias for "yd". Instead, it looks in the definition for "mi" and sees that "yd" is a subdivision but "yard" is not. I could look at enhancing the code to do something clever—I'd have to think about what overheads might be involved. The unit definitions define both "ch" and "chain" as being subdivisions of "mi", so either can be used. That could be done for "yard", but it gets messy defining all the possible variations.
 * The second issue is that the module ignores unused parameters (that's on my to-do list). The result is the rather dumb result that the first of the following lines is interpreted as the second ( is ignored):
 * (convert 1 mile to default output, precision 70 which is truncated to 13)
 * The quick fix is to use "yd":
 * → 1 mi
 * Johnuniq (talk) 02:07, 13 June 2014 (UTC)
 * your "quick fix" has already been noted as example three in my original post. the question is how avoid unexpected results with no errors.  let me know when you decide on a solution. Frietjes (talk) 17:41, 13 June 2014 (UTC)
 * I saw that you had the fix, but my mind was working through the problem while contemplating the unit definitions. I've looked at the module now and it seems readily fixable and I anticipate a sandbox trial in a few days (it may take a while because I have to first finalize some code for viwiki; I'll post here). Johnuniq (talk) 00:58, 14 June 2014 (UTC)
 * I saw that you had the fix, but my mind was working through the problem while contemplating the unit definitions. I've looked at the module now and it seems readily fixable and I anticipate a sandbox trial in a few days (it may take a while because I have to first finalize some code for viwiki; I'll post here). Johnuniq (talk) 00:58, 14 June 2014 (UTC)

That was a bit easier than I thought, and I have updated the sandbox so input multiple units accept aliases. The first two converts in the OP gave output "1 mile (1.6093440000000 km)". When convert is updated from the sandbox, they should give the same result as the third convert because yards = yd and yard = yd. I will wait for a week or so to see if anything else arises, then post a new section saying I will update the main modules.

I took a small shortcut. The new code will only work for an alias defined in Module:Convert/data. It will not work for the "extra" units in Module:Convert/extra. For example, if the alias YARD = yd is added as an extra unit,  would fail. Johnuniq (talk) 04:50, 20 June 2014 (UTC)

gigalitres to billion gallons conversion
In the gasoline article, I would like to change this code

which outputs

476 gigalitres (1.26×1011 US gal; 1.05×1011 imp gal)

to instead output something like this

476 gigalitres (126 billion US gal; 105 billion imp gal)

Is this currently possible with ? Using abbreviations would be okay as well; anything to get rid of that clunky scientific notation. (sigh, I wonder if the U.S. Metric Association accepts donations...) —Megiddo1013 17:39, 21 June 2014 (UTC)
 * Not exactly, but how about the second of these:
 * → 476 GL
 * → 476 GL
 * The e9 is explained here. An output combination has to use "+" rather than a space when using engineering notation to avoid ambiguity concerning what the e9 applies to. Johnuniq (talk) 01:56, 22 June 2014 (UTC)
 * Thanks, that's what I was looking for. —Megiddo1013 04:08, 22 June 2014 (UTC)