Template talk:Convert/Archive September 2011

Latest comment: 12 years ago by Lightmouse in topic acre foot

Convert/2

Why does horsepower convert to feet?

  • {{convert/2|15|/|25|bhp|abbr=on}} -> 15/25 bhp (37,000/61,000 ft)

Lightmouse (talk) 15:45, 31 August 2011 (UTC)

By my reckoning, it should be around four feet per horse. - TB (talk) 17:39, 31 August 2011 (UTC)

This is not good, is it? Why not just stick with the regular {{convert|15|or|25|bhp|abbr=on}} (slashes look like division anyway: 1525 bhp (450 W))? The other answer is, if you look at the doc for {{convert/2}} you'll note that "The output unit must be specified, or put '0' for the default output unit." So{{convert/2|15|/|25|bhp|0|abbr=on}} would get you what you're after. Of course, this is at odds with how ordinary {{convert}} works. I hope we can iron this out but I think it'll take a while. JIMp talk·cont

Thanks. I like the gag about "four feet per horse", it made me laugh. I agree slashes shouldn't be used for ranges or alternative options because they look like division. I try to eliminate them when adding the convert template. Sometimes I can't resolve the ambiguity so I have to pass it through. Lightmouse (talk) 11:09, 1 September 2011 (UTC)

The "sortable" option

I did some work on the {{Number table sorting}} and {{ntsh}} templates so that this template's sortable option should work most of the time. There are still some limitations involving numbers with an absolute value equal to or greater than 1×1016, and numbers with more than 6 digits following the decimal point. –droll [chat] 05:37, 2 September 2011 (UTC)

disp=br

I'm reassigning disp=br. It was for square brackets. From now on it will be for a forced line break. The new code for square brackets will be disp=sqbr. The reason is two-fold.

  1. The term bracket is unclear. Outside of North America it has a more general sense which also includes parentheses (round brackets) & braces (curly brackets).
  2. Forced line breaks are useful where horizontal space is in short supply (e.g. in infoboxes & tables with many columns). disp=br is the most logical code for this.

I have started the transition but I can't be sure when it'll be complete. If you want square brackets but disp=sqbr isn't giving you them or if you want a line break but disp=br isn't working yet (maybe still giving square brackets), let us know. JIMp talk·cont 13:31, 4 September 2011 (UTC)

I never understood disp=br and disp=sqbr is marginally better. But is it the best? Solutions closer to wysiwyg would be disp=[, disp=[] or something like that. Don't we already have disp=/ ? Lightmouse (talk) 14:49, 4 September 2011 (UTC)

I could go with disp=[ or disp=[]. My main concerns were that disp=br was good for line breaks and not so good for square brackets. JIMp talk·cont 15:50, 4 September 2011 (UTC)

I could go with disp=[ or disp=[] ... but it doesn't seem to agree with ... the computer ... or something. No, it's not like it absolutely cannot be done but it doesn't seem to agree with the way the template works. The template takes the value of disp and calls a subtemplate with this in its name. If you try to create a page with "[" in the title, here's what you get.

Bad title
The requested page title was invalid, empty, or an incorrectly linked inter-language or inter-wiki title. It may contain one or more characters which cannot be used in titles.

Now, we could have the template check for disp=[] and replace it with disp=sqbr but I'm just not feeling as if it's worth the {{#ifeq:}}. JIMp talk·cont 23:48, 4 September 2011 (UTC)

  • Remember disp=x|[|] works: The disp=sqbr is just a convenience for users who dislike putting the symbols "[|]" which can seem confusing around the wikikinks "[[xx]]". However, the symbols have been available for years:
• {{convert|9|ft|m|disp=x| [|]}}   → 9 feet [2.7 m]
• {{convert|9|ft|m|disp=sqbr}} → 9 feet [2.7 m]
That also allows the approximate symbol "~" for scientific accuracy:
• {{convert|5|usqt|L|disp=x| [~|]}}   → 5 US quarts [~4.7 L]
     when Template:Convert/usqt passes {5},{6},{7} (or in /usgal & /uspt).
Those options should be enough. -Wikid77 15:42, 8 September 2011 (UTC)

Hundredweight, Quarter & Pounds

Does anyone know how to express Hundredweight, Quarter & Pounds in this template to give a kg equivalent? I am working on Wells Cathedral and in the section on the Bells, their weights are expressed in Hundredweight, Quarter & Pounds. I know these are long cwt (as it is a British topic) and have worked out how to use that, but where smaller divisions are used they are given in quarters (and this site tells me there are 28 Pounds in a quarter and four quarters in a hundredweight. So therefore a hundredweight is 112 Pounds in weight.) but I can't find an abbreviation or format to display this. An example is: Bell 1. weight: 7-3-12, cast: 1891 Mears & Stainbank. If anyone can help with that one I'll work out the rest. Any help appreciated.— Rod talk 16:30, 4 September 2011 (UTC)

This template can't handle this type of thing at the moment but you might like to check out {{CwtQtrLb to kg}}. JIMp talk·cont 17:14, 4 September 2011 (UTC)
Thanks. I had no idea that existed. I've used it where quarters & pounds are mentioned but if anyone wanted to check out Wells Cathedral#Bells to check I've not mucked it up that would be great.— Rod talk 17:31, 4 September 2011 (UTC)
'Hundredweight' was only used by the Royal Navy when they had to transport their goods to different ships, so I think that a hundredweight is the equivelent to eight stone. A useful thing I learned in maths a few weeeks ago. Jaguar (talk) 20:46, 4 September 2011 (UTC)

Please change default double output to default single output: "1 carat (0.20 g; 3.1 gr)" to "1 carat (0.20 g)"

The default output for carats is:

  • "1 carat (0.20 g; 3.1 gr)"

please can we change it to

  • "1 carat (0.20 g)"

Regards Lightmouse (talk) 09:41, 28 July 2011 (UTC)

Why? A. di M.plédréachtaí 12:02, 31 July 2011 (UTC)

Consider the following:

The grain value is only necessary if Americans understand neither the carat nor the gram values. Is it normal in America to say "a 160 grain sapphire ring"? Lightmouse (talk) 12:29, 31 July 2011 (UTC)

Any more comments? Lightmouse (talk) 16:35, 20 August 2011 (UTC)
I can't speak for Americans, but I don't see any reason to change the default here. I'm presuming the reason we default to two units is that none of the three unit is universally more commonly understood than the others. If for stylistic or other reasons two conversions are not appropriate in some circumstances then the default can be overridden for those pages without reducing the informativeness elsewhere. Thryduulf (talk) 21:44, 20 August 2011 (UTC)


i vote for removing the grain amount, and only showing gram. my reasoning is that people who use traditional units (carats, grains), use one unit for one purpose. they won't want to know a gem in grains, they want to know it in carats. one-unit-for-everything is the SI philosophy.Bewareircd (talk) 08:18, 29 August 2011 (UTC)

The default-default is one output only. Each case of non_default-default needs a strong case. Some, like this one, are just legacy that hasn't been challenged lately. This should be reset to the default single output unless anyone claims formats like "a large 52 carat (10 g) sapphire ring" need the value in grains. Lightmouse (talk) 13:07, 21 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

Please change US pint default output to suit majority need

  • 8 US pints (3.8 L; 6.7 imp pt)

The US pint is converted by default to ml and imp fl oz. The majority need for US pint conversion doesn't include imp fl oz. It may also be that litre is better than ml, but that's another issue. We have (or should have) a higher standard for multiple output defaults. In the few cases where the imp fl oz is needed, it can be specified. Please can the default be updated? Lightmouse (talk) 11:44, 31 July 2011 (UTC)

It should convert to litres and imperial pints, for consistency with the imperial pint which converts to litres and US pints (13 imperial pints (7 L)): in the situations where an American uses small pints, a Briton uses large pints and a continental European uses litres. A. di M. plé dréachtaí 12:01, 31 July 2011 (UTC)

You say there's 1:1 usage between Americans and British pints but the ratio is a *lot* more imbalanced. The pint commonplace in the US but legacy in the UK except for one notable exception: draught beer (bottles and cans are ml). The litre is the default unit in the UK. There's no need for Wikipedia to turn back the clock to the days of Empire and the colonies. Lightmouse (talk) 12:41, 31 July 2011 (UTC)

Don't they use (milli)litres and/or fluid ounces for bottles and cans in the US, too? Also, that “one notable exception” makes up for a sizeable fraction (if not the majority) of all the times I've ever used any unit of volume when speaking English. A. di M. plé dréachtaí 12:46, 31 July 2011 (UTC)

Yes, Americans use fluid ounces but it's the US one, not the old British Empire version. Yes, the pint of draught beer is a *notable* exception and your experience fits with that. It's great that the template permits multiple outputs by choice. But Wikipedia articles aren't dominated by beer usage. they add clutter and are only *default* as exceptions. In this case, we should reset it back to the normal convention of only a single default output. Lightmouse (talk) 13:20, 31 July 2011 (UTC)

My point is that even in American articles pints are much more likely to be beer or milk than petrol or Sprite (the latter would likely use gallons and litres/ounces respectively, instead), so converting to imperial pints seems reasonable to me. (Also, the difference between a US fluid ounce and an imperial one is quite small, so I wouldn't normally worry about that: if they are rounded to two sigfigs you can't even always see the difference (12 US fluid ounces (12 imp fl oz)) and more precise measurements than that are likely to come from technical contexts where it's unlikely they'd use ounces in the first place). A. di M. plé dréachtaí 14:34, 31 July 2011 (UTC)

As far as I can detect, the 'USpt' or 'U.S.pt' template option is only used as input in:

Article Default chosen? What was done Default imp fl oz output appropriate? imp pt output appropriate? L or ml only output appropriate?
Energy star No Chose to output in litres only No No Yes
Hypovolemia No. Chose to output in litres only No No Yes
Ink cartridge Yes No No Yes
Milk Yes No No Yes

In all cases here, the litre-only output was either chosen or would have been appropriate. It may only be four instances for this unit but it's an indication that other multi-output *defaults* are excessive. Lightmouse (talk) 11:38, 1 August 2011 (UTC)

How is the imperial pint inappropriate in Milk? According to *that same article*, in the UK “[m]ost stores stock imperial sizes: ... or a combination including both metric and imperial sizes. Glass milk bottles ... are typically pint-sized...” As for hypovolemia, I did heard about pints of blood in Ireland once (though I admit that a sample size of 1 is insufficient). (I have no idea of how dehumidifiers are rated in the UK and I didn't even know they sold printer ink in bulk, so I won't comment on the other two.) A. di M. plé dréachtaí 13:12, 1 August 2011 (UTC)

Let's look at each conversions within the article:

  • In the Milk article it has a section about *America* that says:
    • The .5 US pints (0.24 L; 0.42 imp pt) milk carton is the traditional unit as a component of school lunches, though some companies have replaced that unit size with a plastic bottle, which is also available at retail in 6 and 12-pack size.
    • It's describing an American carton of 0.5 US pint. The ml conversion as required by UK law is appropriate for British readers. The "8.3 imp fl oz" is weird and "0.42 imp pints" wouldn't be an improvement.
  • In the hypovolemia, the editor chose to convert US pints into litres. I would have done the same. British and Irish medicine uses litres to measure blood. Any mention of 'pints' is colloquial and just means an amount that could range from 400 to 600 ml. In any case, we're straying from the point - real conversions from US pints only need ml or litres.

I hope that helps Lightmouse (talk) 14:09, 1 August 2011 (UTC)

  • Agree. So, the change will be inside Template:Convert/USpt to set "|o=ml" (rather than "|o=ml impoz"). -Wikid77 17:05, 1 August 2011 (UTC)
    In any event, litres would be more appropriate than millilitres, IMO. A. di M. plé dréachtaí 15:14, 2 August 2011 (UTC)
The one in hypovolemia isn't about “medicine”, it's about a f***in' film, for heaven's sake. What would be wrong with using a “colloquial” unit there? I'm not sure the movie used US pints in the first place because that's what US medicine uses, either. (And the fact that UK law “requires” millilitres doesn't, by itself, mean that they're commonly used: for that matter, the EU requires energy values in kilojoules on food labels, but I don't think I've ever heard an European use kilojoules for that unless they were compelled to. A. di M. plé dréachtaí 15:14, 2 August 2011 (UTC)

The Hypovolemia article has a litre-only conversion. We don't know what you think it should say. Please can you show us? 15:46, 3 August 2011 (UTC)

Any response? We'd like to make progress. Lightmouse (talk) 15:24, 10 August 2011 (UTC)

Any response from anyone? Lightmouse (talk) 16:34, 20 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

Mach

I see 'Template:Mach'. Is it needed? Lightmouse (talk) 16:17, 20 August 2011 (UTC)

  • Because Convert puts the amount first, followed by unit number or unit symbol, then it would require special coding to show "Mach 1.5" for a Mach number of 1.5. Currently, using Template:Mach:
  • {{mach|1.0}} → Mach 1.0 (1,225 km/h; 761.2 mph; 661.7 knots)
  • {{mach|1.5}} → Mach 1.5 (1,838 km/h; 1,142 mph; 992.6 knots)
  • {{convert|1.0|Ma}} → 1.0 megaare (1.1×109 sq ft)
  • {{convert|1.0|Mach}} → Mach 1.0 (1,230 km/h; 761 mph)
There might be no need for Convert to handle Mach, although Template:Mach currently has few options. -Wikid77 04:45, 21 August 2011 (UTC)

I agree that there's no evidence of demand for a version in Template:Convert. The 'Template:Mach' was created in 2006 and only has two uses. It seems like 'Template:Mach' isn't adding much value either. Should it be put up for deletion? Lightmouse (talk) 10:58, 21 August 2011 (UTC)

Since the speed of sound in air varies according to the temperature & pressure, how can a single conversion factor cover it in the first place? The figures above appear to be based on normal conditions at sea level, but that’s scarcely relevant to the environment in which most supersonic flying is done, where the air is thin & cold.—Odysseus1479 (talk) 02:00, 10 September 2011 (UTC)

Kelvin

  • 1 K (−272.15 °C; −457.87 °F) -> "1 K (−272.15 °C; −457.87 °F)"
  • 1 K (−272.15 °C; −457.87 °F) -> "1 K (−272.15 °C; −457.87 °F)" - should be 1 kelvin (−272.15 °C; −457.87 °F)

Lightmouse 09:20, 13 August 2011 (UTC)

Since the template's creation temperatures have defaulted to the abbreviated form. I suppose Drumguy did it this way since "°C" and "°F" are more common than their spelt-out forms. To change this now would almost certainly lead to chaos. When I added kelvins and degrees Rankine I followed this for consistency. You might argue, though, that since these are not as well known they should be spelt out by default but my gut feeling is that this could lead to potential ugliness like "1 kelvin or −272.15 °C" (whereas you'd prefer the consistency of "1 K or −272.15 °C" ... or at least I would). Note that {{convert|1|K|abbr=out}} is now working and will give the result you desire (but {{convert|1|K|abbr=off}} is broken). JIMp talk·cont 02:19, 14 August 2011 (UTC)

Interesting and understandable. I didn't realise all temperature units were anomalous. If I understand it correctly, the migration to consistency is easy:

  • Bot run to add '|abbr=on' as required
  • Update the default.

I can't see any downsides to that. I think it's worth doing. Lightmouse (talk) 12:44, 21 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

The change would be as follows:
Step 1: Do a bot run to add '|abbr=on' to templates using C, F, or K (with or without '°').
Step 2: Change the default to abbr=off
If I do step 1, is anybody willing to do step 2? Lightmouse (talk) 13:08, 19 September 2011 (UTC)
I could look into it. I do prefer consistency. My only worry here is that we might start seeing a whole lot of "degrees Celsius" and "degrees Fahrenheit" spelt out in all their glory when we'd prefer the abbreviations. People will almost surely neglect to turn the abbreviations on. JIMp talk·cont 01:22, 20 September 2011 (UTC)

It's a legitimate worry. But I don't think it'll be a major problem and at least it's a correct format. There are already lots of incorrect formats like '22 C', '14 degrees', '12degF'. But I'm planning on doing a bot run on temperatures to fix all these. I'm quite keen on the convert template improving consistency across WP and within itself (hence the attempt to reduce low-added-value double output units). Lightmouse (talk) 18:32, 20 September 2011 (UTC)

conversion of regionally used units

It would nice to have the ability to use the convert template for regional units such as below:

more info here

I come across these from time to time patrolling new articles, particularly on India, and would like to make them more accessible to readers by converting them to units more recognizable worldwide.--RadioFan (talk) 14:07, 18 September 2011 (UTC)

It would be nice, yes, however there seems to be a rather major problem here. I've just had a look at the article you link to and discovered that there is no consistent definition for the unit. We cannot just choose one as the official bigha. If we do that, we're sure to get miscalculations. We'd have to have several: bigha (Assam), bigha (Himachal Pradesh), bigha (central India), bigha (Madhya Pradesh), bigha (Uttar Pradesh), bigha (Uttaranchal), bigha (West Bengal), bigha (Bangladesh), bigha (Nepal), bigha (Fiji) ... Which would be used? Which would be misused? JIMp talk·cont 01:50, 20 September 2011 (UTC)
Yuck. I see your point. It sounds like the best course of action is to discourage use of these regionalized measurement systems where there is no consistent conversion possible. --RadioFan (talk) 18:21, 20 September 2011 (UTC)

Volume divided by time

Can we have volume divided by time conversion? For example:

  • 1,000 cubic feet per year (0.90 m3/Ms)
  • 1,000 cubic feet per minute (28 m3/min)
  • 1,000 cubic metres per minute (35,000 cu ft/min)

Lightmouse (talk) 15:38, 20 September 2011 (UTC)

Cubic feet per year exists in the form of cuft/a ("a" for "annum"). I'll look into the other two. JIMp talk·cont 23:21, 20 September 2011 (UTC)
1,000 cubic feet per annum (28 m3/a)
Done. JIMp talk·cont 00:19, 21 September 2011 (UTC)

Thanks. Can you also do other unit permutations:

  • 1,000 inches per day (290 mm/ks)
  • 1,000 square kilometres per day (4.5 sq mi/ks)
  • 1,000 kilometres per day (620 mi/d)
  • 1,000 cubic centimetres per day (0.71 cu in/ks)
  • 1,000 cubic millimetres per day (0.00071 cu in/ks)
  • 1,000 cubic kilometres per day (3.5×1013 cu ft/d)
  • 1 to 1,000 cubic kilometres per day (3.5×1010 to 3.5315×1013 cu ft/d)
  • 1,000 billion US gallons per day (44,000 m3/s)
  • 1 to 1,000 US gallons per day (4.4×10−8 to 4.3813×10−5 m3/s)
  • 1 to 1,000 billion US gallons per day (44 to 43,813 m3/s)

Lightmouse (talk) 11:28, 21 September 2011 (UTC)

Also:

  • 1 to 1,000 barrels per second (9.5 to 9,539.2 m3/min)
  • 1,000 barrels per second (9,500 m3/min)
  • 1,000 barrels per minute (2.6 m3/s)
  • 1,000 barrels per hour (44 m3/ks)
  • 1,000 million barrels (160,000,000 m3)
  • 1,000 billion barrels per day (1.6×1011 m3/d)

Regards Lightmouse (talk) 14:24, 22 September 2011 (UTC)

An apparent inconsistency

Look at the following:

  • 1 million cubic feet (28×10^3 m3)
  • 1 million cubic feet (28,000 m3)

Why are the output formats different? Lightmouse (talk) 14:37, 22 September 2011 (UTC)

The formats are different because the output default for e6cuft is not m3 but e3m3 or e6m3 (depending on size). These e3, e6, e9, etc. codes serve two purposes: they either add "thousand", "million", "billion", etc. or they output engineering notation. Which of these is actually output depends on whether or not we're using the abbreviated form. When they were created what I had in mind is that it would make sense to go from e3, e6, e9, etc. to e3, e6, e9, etc. (e.g. e3cuft to e3m3). Well, it does make sense if the input and output are in the same form (with respect to abbreviation) but where they are different (as in the example above) it doesn't. I wouldn't mind if we change it but it would be good if we could have a bot go through and find any transclusions with an e3, e6, e9, etc. input plus abbr and/or disp set (to something other than the default) since abbr or disp can be used to make the output & input the same with respect to abbreviation. JIMp talk·cont 23:59, 25 September 2011 (UTC)

I'd be happy to do this by bot although I don't quite understand all the permutations. Can you provide:

  • A sample list of target units to get me started - it doesn't need to be complete. If this extends into units outside my existing bot scope, I'll need to apply for an extension. That's not a bad thing, it's just to let you know there'll be a delay before I can address those units.
  • The range of 'e'. I know it goes from 3 to 12 but I don't know if it goes lower or higher.
  • If it applies to all values of 'disp'. It's much easier to code if I simply detect the presence or absence of disp. I don't quite understand the role of 'disp' in this issue.
  • Some examples of the before and after permutations you'd like. I understand the principle of your explanation but I don't quite get how it works in detail.

Lightmouse (talk) 08:43, 26 September 2011 (UTC)

What's the difference

Between 'e6' and 'M' in the following:

  • 1 million cubic feet (28×10^3 m3)
  • 1 million barrels (160×10^3 m3)

Lightmouse (talk) 17:11, 22 September 2011 (UTC)

The difference shows up when the input is abbreviatied.
  • 1×10^6 cu ft (28×10^3 m3)
  • 1 Mbbl (160×10^3 m3)
JIMp talk·cont 00:01, 26 September 2011 (UTC)

Ah. I see. Thanks. Lightmouse (talk) 08:28, 26 September 2011 (UTC)

Convert e9m3 with abbr=off

I have a rare case of converting a "33-billion-cubic-meter" amount, but the "abbr=off" did not work with adj=on, so I hard-coded the conversion as the "1,200-billion-cubic-foot" result (in article "Economy of Israel"). As always, I hard-code the conversion when it is a rare option, to allow more weeks to fix it. The current status:

  • {{convert|33|e9m3|e9cuft|adj=on}}       → 33-billion-cubic-metre (1,200×10^9 cu ft)
  • {{convert|33|e9m3|e9cuft|abbr=off}}      → 33 billion cubic metres (1,200 billion cubic feet)
  • {{convert|33|e9m3|e9cuft|adj=on|abbr=off}} → 33-billion-cubic-metre (1,200-billion-cubic-foot)

I am still looking, in Template:Convert/LoffAnoneDbSonEng, to see why the final "cubic-foot" gets a calculation error, after correctly showing "1,200 billion". Internally, the singular {{{n}}} should be "cubic foot" but shows "{{{n}}}" by plural "cubic feet" for {{{l}}}. It is a very rare conversion, so there is no hurry to fix the problem. -Wikid77 (talk) 11:19, 17 September 2011 (UTC)

Somehow a comma was finding its way into an #expr ... JIMp talk·cont 02:15, 20 September 2011 (UTC)
That's got half the problem fixed but somehow the template seems to be forgetting adj=on by the time it gets to the output unit. JIMp talk·cont 03:27, 20 September 2011 (UTC)

Fixed. JIMp talk·cont 06:16, 20 September 2011 (UTC)

There is still some problems as {{convert|2.8|to|3.3|e12oilbbl|e9m3|abbr=off}} for Oil shale article does not work. Another problem occurred with [edit] by Lightbot. Beagel (talk) 16:05, 26 September 2011 (UTC)

I notice from your contributions you've been helping a lot with oil and gas articles. Thanks. I'm a frequent user of this template but I don't understand all permutations. I look forward to seeing what others say about these problems. Lightmouse (talk) 16:22, 26 September 2011 (UTC)

Use of "|to|" or "|and|" in {convert|x|LT|t...}

Here are examples of conversions that give me headaches:
950 to 1,000 long tons (965 to 1,016 tonnes)
950 and 1,000 long tons (965 and 1,016 tonnes)

Using "to" or "and" in most other units I've needed it in so far, works just fine. Examples:
950 to 1,000 miles (1,529 to 1,609 kilometres)
950 and 1,000 miles (1,529 and 1,609 kilometres)
950 to 1,000 pounds (431 to 454 kilograms)
950 and 1,000 pounds (431 and 454 kilograms)

Please help! André Kritzinger (talk) 21:39, 26 September 2011 (UTC)

fixed by creating a redirect here. Frietjes (talk) 22:33, 26 September 2011 (UTC)
Perfect, thank you! André Kritzinger (talk) 23:40, 26 September 2011 (UTC)

Experimenting with Template:Decomma

I have created a simple Template:Decomma to show the rejection of improper commas:

  • {{Decomma|1,600}} → 1600
  • {{Decomma|1,60}} →
    {{Decomma}} - invalid comma format "1,60". 
    160
  • {{Decomma|16,0}} →
    {{Decomma}} - invalid comma format "16,0". 
    160

However, when considering how other users often change templates (without prior discussion with even the people who recently edited those templates), then I think it is too dangerous for Convert to use common utility templates, and instead we should create a {Convert/decomma} which is specifically optimized for Convert and not an easy target for non-discussed "improvements". Because working on WP involves a zillion details, many people do not have time to "gain consensus" for changes, so they just change templates with no prior discussion and no post discussion to explain what all has been changed. That seems to be human nature in busy situations, so {Convert/decomma} should be controlled to avoid unneeded changes. Hence, Template:Decomma can be used to try various comma-validation tests, but do not be surprised when it is radically changed by other users, some day when having the least time for unexpected problems. The main concern, now, is to try using some specific markup to reject improper commas. -Wikid77 (talk) 12:16, 27 September 2011 (UTC)

acre foot

In the template, I see people use 'ft', 'foot', 'feet'. People using hyphens, dots, and spaces between 'acre' and 'foot'. Yet, I see two templates:

  • Template:Convert/acre.ft
  • Template:Convert/acre.foot

Do two templates cover all the permutations? If so, why can't it be just one? Lightmouse (talk) 12:41, 28 September 2011 (UTC)

Are we talking output or input?
  • If you mean what the template spits out, I don't believe we should be trying to cover all possible permutations. We should settle on what is to be used. The acre-foot is like the newton-metre and kilowatt-hour: hyphens when spelt out and dots when abbreviated ... but there is no abbreviation for the acre (and it wouldn't do to half abbreviate) so "acre-foot" (in some varieties of English, as far as I know, "foot" pluralises to "foot") and "acre-feet".
  • If you mean the template code, I notice acre-feet & the three versions with spaces all redirecting to the dot versions & all hardly used. We could dispose of them.
JIMp talk·cont 04:51, 29 September 2011 (UTC)

I was talking about the template code. We can't conclude the current permutations are evidence of what editors do. I did a bot run to eliminate all permutations apart from 'acre.ft' and 'acre.foot'. Furthermore, I've added a lot of acre feet templates over the years, so a lot of what was there may be permutations I chose. Other instances may be due to people copying formats I've used within the same page or others. I've not been consistent so it doesn't surprise me that others aren't.

I asked the question because the number of input permutations exceeds the number of templates, I'm merely curious about whether having two templates is efficient. If we can reduce complexity in the code without reducing flexibility for editors, that would be ideal.

You raise a new point that acre foot is similar to newton metre and kilowatt hour. I just looked and found article titles are inconsistent. See:

I note that editors use several template input permutations for those units too. The BIPM says "Multiplication must be indicated by a space or a half-high (centred) dot (·)". I note the SI unit titles are compliant with that. I'm not sure what to conclude. Lightmouse (talk) 09:16, 29 September 2011 (UTC)