Template talk:Convert/Archive May 2009

REQUEST: Changes to formatting of parens and suppression of parts of output

First, thanks

First, thanks very much for this template, I find it very useful-- a bit fiddly when one first uses it, but valuable not only for itself but because I always think metadata is good (e.g. this probably helps translators put non-SI units into context).

Changes to characters to use for parens

Now, request: it would be nice to be able to use [ ] instead of ( ) to surround the output. My reason for this is so it could be used correctly in quotations. As it happens, currently I use it anyway (where appropriate of course, not "I'd walk a 1,000,000 miles (1,609,000 km) for one of your smiles..."), but technically I am out of order there for changing the quote. I think the sin is minor.

But if there were an easy way to change these, it would be very handy. Indeed a general mechanism would be best. In fact, it would also sometimes to be nice to change the parens to something else note that the " or " and "/" are really special cases of that. e.g.:

I am not very tall—{{convert|5|ft|cm|open=", which is "|close=""}}— but small is beautiful

• I am not very tall —5 ft, which is 152cm—but small is beautiful.

I am not very tall—{{convert|5|ft|cm|open=", which is "|close="—"}} but small uis beautiful

• would give the same but is rather bad form to imbalance the dashes one inside and one outside.

The chairman said "This year we produced {{convert|17162482|mi|open="["|close="]"}} of red tape"

• The chairman said "This year we produced 17,162,482 miles [27,588,690 km] of red tape"

I am not saying the "open"/"close" is necessarily the best way to do it but I am sure you see my general point. A simple "quote=on" parameter or something like that might be better and simpler. I am just hoping, if the addition of the parentheses is a simple part of the template (cos it's about the only constant thing about it) then it would be easy to add this and, of course, it would not break any existing functionality.

This would be handy. It's on the to-do list. JIMp _talk·cont 20:04, 28 April 2009 (UTC)

Suppress output of original value

Similarly by extension, it would sometimes be nice to SUPPRESS the output of the original value. i.e. only provide the converted value. In doing so almost certainly one would not want the parentheses-- though of course the suppression mechanism might automatically suppress them, it would seem nice to bring it under a general mechanism; one only has to look at the cite template to see what happens when there are too many competing parameter combinations.

I find when I am translating articles I sometimes want to suppress the original value. The reason for this is that the original value will not make sense to readers in the other language (it's rather an English-speaking-world thing); but it is useful for editors/translators to have the value from the original article, and also saves having to do the conversion oneself, which is after all what convert is all about.

How about putting the original values in a footnote? As for what you're asking, I've got this working but only in a limited way: currently it'll only work with abbreviations/symbols, no linking & not with all units.Use disp=output only e.g. {{convert|10|mi|disp=output only|abbr=on}} → "16 km". JIMp _talk·cont 20:03, 28 April 2009 (UTC)

Yeah that's cool. Probably the original values should go in a footnote (or somewhere), but if there's already references either to the original article or to its references it might be overboard-- the aim is not to hide the information, but to reduce clutter in the flow of text so yeah a footnote may well be appropriate sometimes. I tend to edit rather technical articles and it can just become a flurry of units, also especially automotive articles seeem particularly susceptible to having mixes of RS in Imperial/US Customary or metric (even though virtually all cars are now built in metric, including American ones).SimonTrew (talk) 11:40, 2 May 2009 (UTC)

Identity conversions

Let a value be converted to itself, simply for consistent formatting. Especially handy if ever one day we picked up separators etc from user's locale (nuff said there considering the date format wars etc), but even so it is not quite as useless as it may seem, since some units are quite difficult to type on some keyboard layouts. Suppress=on might be implied here since it's pretty pointless to put the same thing out twice.

I'd walk {{convert|1000000|mi|mi}} for one of your smiles.

• I'd walk 1,000,000 miles for one of your smiles.

Currently loops: I'd walk {{convert|1000000|mi|mi|suppress=on}}<nowiki> for one of your smiles. An alternative may be to have a special symbol representing identity of any unit, let's say "I", if that were easier to avoid loops in the implementation (I don't think I is used, but anyway any symbol would do). <nowiki>I'd walk {{convert|1000000|mi|theidentitysymbol}} for one of your smiles.
I'd walk {{convert|1000000|km|theidentitysymbol}} for one of your smiles.

• I'd walk 1,000,000 miles for one of your smiles.
• I'd walk 1,000,000 kilometres for one of your smiles.

Perhaps {{val}} is what you're looking for. JIMp _talk·cont 18:26, 28 April 2009 (UTC)

Looks like it, thanks. I am so fed up with template help (or lack thereof), not only are the template doc pages themselves often entirely useless ({{convert}} isn't, though there are gaps), but it's just impossible to find a template unless you already know it exists (or there is some amazing hidden mechanism I've not found yet). SimonTrew (talk) 11:43, 2 May 2009 (UTC)

Switch output order

Similarly by further extension, I sometimes want to switch the order so that the converted value comes out first and the original value afterwards. For multiple outputs that probably makes little sense. This is mostly when parts of an article are added from a source that uses SI but the existing article uses Imperial/US Customary; there's no way to use Template:Convert yet keep the ordering consistent.

I can imagine this could be very difficult to implement. With the suppress suggestion it's unnecessary to have this option, since one can work around it simply suppress the original value then write it afterwards longhand (since it's already there close by in the source so the redundancy is no big deal). e.g. if you look at Think Global you will see that some units are first-SI and some first-Imperial; I've kept one that way as it is in a direct quote, but the others I have switched manually and then fiddled with the values to get the output to match the original, which is rather defeating the object of the template.

As I say come to think of it a perfectly good workaround, with original suppression, would be to write it twice:

She must walk {{convert|10|mi|suppress=on}} (10 miles) each day to fetch gin from the well

• She must walk 16 km (10 miles) each day to fetch gin from the well

The 10 miles, though duplicacted, is fairly patent and close by in the document source, so I don't see the problem with that as a workaround. Indeed, identity conversions i.e. convert something to itself, purely for formatting, could do this too. In these last two examples I've left the convert template actively in place in the output, indeed the first one (for km mi) nicely prints out the miles after the km, if the suppress worked then that would be just perfect! Unfortunately the second one grumbles about template loop detected (i.e. can't do an identity conversion):

She must walk {{convert|10|mi|km mi|suppress=on}} (10 miles) each day to fetch gin from the well
She must walk {{convert|10|mi|mi|suppress=on}} (10 miles) each day to fetch gin from the well

• She must walk 10 miles (16 km; 10 mi) each day to fetch gin from the well
• She must walk {{convert|10|mi|mi|suppress=on}} each day to fetch gin from the well

Switching the order has been brought up before. It's on the to-do list but will take a bit of work. JIMp _talk·cont 19:24, 28 April 2009 (UTC)

Thanks again

Thanks again, great template, and documentation is not perfect but better than a lot of others. Hope you don't mind me bashing these suggestions at you. SimonTrew (talk) 20:21, 25 April 2009 (UTC)

Converting a unit to itself

An attempt to convert a unit to itself (e.g. km to km) will result in a template loop. This has been mentioned in Identity conversions above with one example but is true more generally. Can this be fixed? Debresser (talk) 12:31, 29 April 2009 (UTC)

How do you think it should be fixed? The invocation needs fixing—not the template. {{convert|6.023|km|km}} is doing its job crying for help to be fixed. —EncMstr (talk) 16:07, 29 April 2009 (UTC)

How to fix it, I wouldn't know. If have only a very superficial understanding of what goes on in these templates.

The user who wrote that section above explained why one would want to use such an invocation. You might agree with him or not, but it would be preferable if the template could handle this. Debresser (talk) 16:11, 29 April 2009 (UTC)

It might be preferable if this worked ... the template would be doing just what it's told: elegant simplicity. The question, I've got, though is why you'd want something like "6.023 kilometres (6.023 km)". If this is what the template is being asked to do, it's most likely an error on the part of the editor. It might be preferable if this worked ... might be better still if the template output an error message specifying the exact problem. Is it worth the trouble to include such an error message when an explanation on the doc could clear up any confusion? Suppose, though, we really did want to convert a unit to itself. The best way to do so I'd say would be to create the kind of "identity" code mentioned above. If you're entering this specific code, you know what you're asking for. So I'll be right on it the moment anyone can dream up a valid reason for converting something to itself. JIMp _talk·cont 01:38, 30 April 2009 (UTC)

PS Yes, Simon Trew did explain why one would want to use such an invocation: "simply for consistent formatting" not to convert something to itself "since it's pretty pointless to put the same thing out twice". I believe what he was looking for is something along the lines of what {{val}} does. JIMp _talk·cont 01:46, 30 April 2009 (UTC)

I just don't like template loops. So we could do three things: ignore the whole thing, make the template display an error message other than template loop, make the template work for identical input and output units. Do I have to point out that the last option is the most friendly and elegant one? My guess is, it isn't even hard (just that I don't have the foggiest how to be about it). Debresser (talk) 01:55, 30 April 2009 (UTC)

I don't like template loops either but remember that you can only get this particular loop by asking the template to do something absurd. No, you don't have to point out the elegance of the third in your list of options (not to me, anyway, I've already acknowledged it). As for being hard, there'd be easier and harder ways of doing such a thing some more greedy than others. By "greedy" I mean that however it be done the template limits will be pushed. The further these are pushed the fewer transclusions of the template can fit on a page. Please understand my reluctance to push those limits to make the template elegantly capable of doing the completely undesirable. JIMp _talk·cont 07:16, 2 May 2009 (UTC)

Absolutetly I did indeed say why, and was pointed to {{val}}. It is VERY hard to find a template if you don't know it exists, that is just a very bad problem in the Wikipedia search or help system and I find it increasingly frustrating. Not your fault though.

Asssuming that val spits out the same text as convert, I have no problem with using that instead. If it does not spit out the same text, then I will just grumble on those specifics either here or at the val template talk.

I think actually it is better, given now I know about {{val}}, for it to spit out the error message, since it likely indicates a typo or something in the invocation, and that's better than hiding it by spitting out apparently good but meaningless (or wrong) output. I am thinking of {{cite}} and <ref> which grumble noisily if something is wrong — a pain in a way because if just editing a section one can't see the references section, though I've learned now to add {{reflist}} into the section before preview and then remove it afterwards. OK, I haven't yet learned to remove it afterwards. Sheesh. SimonTrew (talk) 11:58, 2 May 2009 (UTC)

Well, if it's a problem, then let's just forget about it. I have no problem cleaning up a template loop a month (which is about the frequency I see this particular one).- It's just that my mathematicians nature likes elegant solutions. :) Debresser (talk) 18:04, 2 May 2009 (UTC)

Feet per mile

Is it possible to get the above to accept nautical miles? As in something like ft/nmi? Thanks. Enter CambridgeBayWeather, waits for audience applause, not a sausage 22:34, 1 May 2009 (UTC)

How's this?

{{convert|46.3|ft/nmi}} → "46.3 feet per nautical mile (7.62 m/km)"

JIMp _talk·cont 06:57, 2 May 2009 (UTC)

Thanks. That works perfectly. Enter CambridgeBayWeather, waits for audience applause, not a sausage 15:03, 2 May 2009 (UTC)

Is the "/" notation common? I'd come to convert thinking it was quite generic, then slowly learnt each conversion was done separately so for example ft/nmi might exist but not mm/m. Is this generic? Let's try:

Millimetres per metre (was translating article about the river Durance):

It falls {{convert|80|mm/m}} in its final stage.

It falls 80 millimetres per metre (0.96 in/ft) in its final stage.

This fails, as of 2009-05-02.

(Made up)He inflated the tyres to {{convert|28|lb/in2|abbr=on}}

He inflated the tyres to 28 lbf/in² (190 kPa; 2.0 kgf/cm²)

This succeeds, and without abbr=on also, though "psi" would be more common than its abbreviation, I think.

If you want psi use psi {{convert|28|psi|abbr=on}} → "28 psi (190 kPa)" JIMp _talk·cont 01:08, 3 May 2009 (UTC)

I am quite good at mental arithmetic and so did the conversions in my head, but that's really unsatisfactory because then the numbers aren't from reliable sources (my head is very unreliable), that's kinda what I meant by liking the metadata, since it gives editors a reference to where the numbers came from. There's actually a comment on the French WP for the first example saying it should be a ratio (a percentage) so 46.3 ft/mi should be 46.3/5280=0.877% but that's not always possible because the dimensions may be in orthogonal directions i.e. a vector.

I had this in another article where the conversion was length <times/> length but the result was not an area, rather a ratio. It's an argument I have had in designing a lot of units of measure systems that dimensional analysis is pretty pointless because, for example, people measure pressure in millimetres (of water or mercury), sound in dBel (which is a logarithmic formula of watts per square metre using the inverse square law), and so forth. Would be totally over the top here, and do more harm than good. It's partly why I wanted identity conversions, so that one could put e.g. dB in a conversion simply to say "THIS IS A UNIT PLEASE TRANSLATE IT", so a bot or translation-bot (i.e. human) can easily spot it-- but {{val}} is just fine for that purpose. SimonTrew (talk) 12:19, 2 May 2009 (UTC)

I should perhaps expand a little about translation, and why I think it important. As you may know, a lot of articles are translated to other wikipedias, and en.wikipedia being the largest, more come into or out of it than from others. Units of measure are very important in the articles I translate; generally a French article will only use SI but our US friends would in most circumstances prefer US Customary (though one must use judgment because in getting into very scientific fields it's best to use SI, as per MOS, it depends really if it's a scientific/engineering measure or just "it's about 6 kilometres from Rouen" which should be "about 4 miles" since the vagueness is more important to preserve — see my convert additions at Newmarket racecourse for my struggle here). Since say at Newmarket the Rowley Mile is not actually a mile (though of course races are of 8 furlongs SimonTrew (talk) 13:05, 2 May 2009 (UTC)

Furlong

Can we have furlong please for racing. We need to do miles and furlongs (for over the sticks) and I would imagine convert into SI metres (for shorts on the flat) and also US Customary (where a furlong is the same but not heard of). See my struggle at Newmarket racecourse. SimonTrew (talk) 13:05, 2 May 2009 (UTC)

Multiple-value units, and fractions

Is there general handling of multiple-value units? I mean degrees, minutes seconds; hours, minutes, seconds; six feet two inches; three pounds one ounce; six and a half kilometres; that kind of thing? See my struggle at Rationing in the United Kingdom here, also at Coca-Cola formula where, you shall be pleased to here, I used the unwonted drachm!

What may or may not be related, fractions are multiple value units: 1m 4f is not substantially different from 1/4, it just happens in the latter that the two units, for the nominator and denominator, are the same. I note that in some conversions (e.g. usfloz, see Coca-Cola formula) the fixup to display as ¼ (etc) doesn't work. SimonTrew (talk) 13:05, 2 May 2009 (UTC)

Automatically produce hidden output so sortable tables work correctly

I'd like to add a new parameter to {{convert}} to automatically output a hidden sort key for sortable tables.

Sortable tables depend on the contents of each table cell so each column can be sorted via Javascript. One way to provide the correct output in each cell so they are sorted correctly, it to add a hidden sort key. If I have the values 5, 10, and 15 in a column that I want sorted, I can add hidden keys like this: <span style="display:none">0005</span> <span style="display:none">0010</span> <span style="display:none">0015</span>. Now, instead of being sorted 10, 15, 5, they will be sorted correctly: 5, 10, 15.

I have a modification that can be added to {{convert}} that will optionally output this hidden sort key for use in the sortable table. Add this {{#ifeq:{{{sortable|}}}|yes|<span style="display:none">{{padleft:{{{1}}}|16|0}}</span>}} at the beginning of the main {{convert}} template, and now the template will accept an optional parameter sortable, which, if set to "yes" will automatically output the hidden sort key, left-padded with zeros. I have a test version of {{convert}} here {{User:LinguistAtLarge/Sandbox/Convtest}} which shows this in use. For example, {{User:LinguistAtLarge/Sandbox/Convtest|5|acre|sortable=yes}} produces: {{User:LinguistAtLarge/Sandbox/Convtest|5|acre|sortable=yes}} (If you look at the HTML source, you'll see the hidden sort key). This would be very helpful for articles like List of lakes in Michigan which currently have the hidden sort key hard-coded.

Known caveats-- this doesn't work with syntax like "5|ft|9|in" (it will only use the "5").

So, I'd also like to hear what others think. Can anyone see any problems with how I have this set up? Can it be added to the template? Thanks! — LinguistAtLarge • Talk  20:20, 4 May 2009 (UTC)

In the absence of objections, I have been bold and added this functionality to the template. I also updated the sandbox and template documentation. The parameter is sortable=on, using "on" instead of "yes" for consistency with other template parameters. — LinguistAtLarge • Talk  18:43, 7 May 2009 (UTC)

Discussion at MOSNUM regarding large numbers

In October last year, a user edited the MOSNUM section on large numbers to specify that only numbers greater than 10,000 should have comma separators, with an edit summary of "as per talk page". I can't find any discussion myself, though I may have overlooked it. Since then, this guideline page has been in conflict with the {{Convert}} template, which uses a comma separator for >=1,000 as seen in the following examples: 1,000 kilograms (2,200 lb), 1,000 metres (3,300 ft), 1,000 hectares (2,500 acres), etc.

I've initiated a request at the MOSNUM talk page that this contradiction be resolved, if you'd like to contribute. I don't have any concern as to which standard is adopted, although others may have stronger opinions. Regards, --DeLarge (talk) 12:05, 9 May 2009 (UTC)

Dual conversions

Dual conversion |°C|°F|

Boiler#Superheated steam boilers & Boiler (steam generator)#Superheater 1,300–1,600 °C (2,372–2,912 °F) or1,300–1,600 °C (2,372–2,912 °F)?? or vice versa. Can some one take a go at this??

Dual conversion

Boiler#Supercritical steam generators & Boiler (steam generator)#Supercritical steam generatorr 3,200 psi (22.06 MPa) 3,200 psi (220.6 bar). Can some one morph this into 3,200 psi (22.06 MPa; 220.63 bar) similar to 3,200 short tons (2,903 t; 2,857 long tons) or 3,200 short tons (2,903 t; 2,857 long tons)? Why does "|abbr=on" not work?? Peter Horn 01:17, 12 May 2009 (UTC)

I could certainly create a megapascal/bar conversion subtemplate but since a bar equals a tenth of a megapascal exactly I wonder what the use is. I say just convert to megapascals and forget bars (along with dynes & ergs) ... but, of course, it's not my encyclopædia, so, hey, if you reckon it's useful ...

Per MoS there is no abbreviation for the long & short ton.

Use long ton or short ton and not just ton; these units have no symbol or abbreviation and are always spelled out. The tonne, 1000 kilograms, is officially known as the metric ton in the US. Whichever name is used, the symbol is "t".

JIMp _talk·cont 06:50, 12 May 2009 (UTC)

Bug in this template

I just did this edit to air well (condenser). Before this edit temperatures looked like this:

68 °F

After this edit, they looked like this:

68° F

The code that appeared before the edit was this: {{convert|20|C}}.

As far as I know, the way I left it is standard. I've done a few dozen edits to other articles in which I changed things like 68 °F to 68° F, but this is the first time I've seen that this template is where this came from. Can someone fix this? Inadvertently altering standard conventions is not what Wikipedia should be doing. Michael Hardy (talk) 15:17, 1 May 2009 (UTC)

I traced through the templates to fix it, but saw correct code in {{Convert/°C}} and {{Convert/°F}}. Puzzled, I tried some examples. It seems okay when an explicit destination conversion is given: {{convert|68|°F|°C}} = 68 °F (20 °C) and {{convert|104|°C|°F}} = 104 °C (219 °F). The example you have is different though: {{convert|68|°F}} = 68 °F (20 °C) and {{convert|22|°C}} = 22 °C (72 °F), but those are okay too. Confused, I looked again. Your spacing is nonstandard. See WP:MOSNUM#Unit names and symbols. —EncMstr (talk) 18:19, 1 May 2009 (UTC)

I see nothing wrong in the behaviour of the template...tested several variations, and they all correctly show °F and °C, not ° F or ° C. Michael, you say you changed several articles to read with a space between ° and C or F? That's not what MoS recommends (or at least, I can find nothing showing that). Or am I misreading something? — Huntster (t • @ • c) 23:47, 1 May 2009 (UTC)

If "68 °F" is non-standard, it'll have to be brought up at WP:MOSNUM since, as noted above, the template is following MOSNUM. JIMp _talk·cont 07:30, 2 May 2009 (UTC)

Nope, WP:MoS says:

<quote>Temperatures are always accompanied by °C for degrees Celsius, °F for degrees Fahrenheit, or K (but not °K) for kelvin. Further, a space—preferably a non-breaking space ( )—always separates the value and temperature symbol (e.g. 35 °C, 62 °F, and 5,000 K.</quote>

I must admit I once misread this as having the space between the degree symbol and the unit, I am not sure why, but I vaguely recall something about "the exception is temperature, where a space...." or something; perhaps this got changed or I've gone mad. SimonTrew (talk) 11:23, 2 May 2009 (UTC)

I'm surprised to see that only one of my comments in this thread is here. I posted another one, and it's nowhere to be found. Michael Hardy (talk) 05:22, 13 May 2009 (UTC)

Is it possible to correct this?

Talk:Coca-Cola formula#Convert templates & Coca Cola formula#purported secret recipes 2.5 US gal (9.46 L; 2.08 imp gal) versus 2+1⁄2 US gal (9.5 L; 2.1 imp gal). Is it possible to correct this anomaly in the second conversion? Peter Horn 01:33, 13 May 2009 (UTC)

As noted above, fractions aren't fully up and running but, yeah, it's fixable. JIMp _talk·cont 06:26, 13 May 2009 (UTC)

Unnecessary identity conversions for fluid ounces and long tons

By the way there is an identity conversion between US fluid ounces and British fluid ounces (and it doesn't always get it right, I've seen 0.9999998 or something though can't reproduce it); it will spit out

{{convert|1|usfloz}} → 1 US fluid ounce (30 ml)

As of 2009-05-02 that prints "1 US fluid ounce (30 ml; 1.0 imp fl oz)". What, a fluid ounce is a fluid ounce? Wow. In fact the distinctions for usfloz etc are unnecessary, though obviously it would be wrong to get rid of them as it would break existing articles.

I think this is specific to ounce, since US pint and multiples thereof are based on 16 fl oz = pint (US) not 20 UK). I have learned this the hard way because living in both places I have to check measuring jugs for whether they are UK or US. (OK I don't usually measure, but I do the first time I make a recipe.) SimonTrew (talk) 13:05, 2 May 2009 (UTC)

In editing Rationing in the United Kingdom I also found an identity for tons:

{{convert|1|LT}} → 1 long ton (1.0 t)

Worse, {{convert|3/4|LT}} → 3/4 long tons (0.7620351816000 t); as of 2009-05-02, 3/4 long tons (0.7620351816000 t. (I've put in the convert template itself and its results on that date, since with a fix the first-mentioned may change, I hope.) Call me Mr. Floating point, but that's a shite conversion: it's easily expressed in binary as 0.11. What's going on there to get it so wrong?

As always I hope you appreciate this is constructive criticism and I *love* this template and use it always to get it right, even if I know that an inch is 25.4 mm (I have an old dictionary that has it as 24.39999) and I am just trying to help you all make it better. I can program myself but obviously it would be wrong for me just to go changing the templates without discussion. SimonTrew (talk) 17:16, 2 May 2009 (UTC)

I see my mistake with the latter example that is converting a long ton to a metric tonne, thus the partial difference. That doesn't excuse the former. In real life a metric tonne and Imperial ton are so close to each other that nobody give a shit, henceforth template should not give a shit either: I tried adding rounding factors but it rounds to 0.76 where patently 3/4 is not 0.76. SimonTrew (talk) 17:28, 2 May 2009 (UTC)

The fluid ounce bit id due to rounding. If I use "{{convert|1|usfloz|impfloz|3}}" I get 1 US fluid ounce (1.041 imp fl oz) and I can see the non-identity relation.

The long ton one is perfectly correct, .75 of a long ton is indeed .76 of a metric tonne ("tun-n-n-ee":). It's very difficult to instruct software on what exactly humans don't give a shit about, and identity relations are especially difficult, since there's all those unseen decimal places. Try it with 1000 tons.

Fooling around with these examples though, I think I've come across a curious one: "{{convert|1|LT|ton}}" emits 1 long ton (1.0 long ton; 1.1 short tons) which don't look right. Why is "1.0 LT" repeated in the result?

I'm an amateur here, so take my reply with a grain of salt. I too love the template! It would be nice if it could figure out rounding and significant figures by itself, but that's a pretty touch task. Franamax (talk) 18:08, 2 May 2009 (UTC)

But a fluid ounce UK is the same as a fluid ounce US. No doubt there is some bizarre definiton otherwise, but for every parctical purpose they are the same. So 1 fl oz = 1 fl oz (identity) and so no need to regurgitate it or convert it, especially if it gets it wrong-- 1 us fl oz = 0.99999998 imp fl oz is just stupid. SimonTrew (talk) 18:57, 2 May 2009 (UTC)

Well, both my Pocket Ref and my CRC handbook says that 1 US fluid ounce equals 1.0408 British fluid ounces. That's one extra sip of beer per glass, which I feel is significant. :) Here again the template is doing that weird thing of repeating the base unit though: 1 US fluid ounce (1.041 imp fl oz; 1.000 US fl oz) Franamax (talk) 21:11, 3 May 2009 (UTC)

Rounding is an excuse it is desired rounding that is lacking. Rounding FP numbers is a right pain, because of radix and so on (worst when you try doing it for bases that are coprime), but this is a template for readers not for seventeen-point accuracy for mathematicians. It's pretty obvious 3/4 should round to 0.75 not 0.76, in the example I gave that's because of the difference in the metric tonne and the long ton, but conversely it rounds 1 to 1.0. I don't mind any of this, but it should be documented. The documentation for convert is better than for a lot of templates, but is still a bit obscure-- for example the |0| notation I am still quite not sure what that is supposed to do; is it to let the template do its stuff or is it to specify no decimal places? In minor ways the doc should be improved for that, cos it's a great and very useful template, in fact should become kinda a standard if you don't have convert you don't get GA, at least. (Obviously excluding articles that have no units of measure.) SimonTrew (talk) 19:04, 2 May 2009 (UTC)

Agree the docs can always be improved and I've tried to help with that in the past. 'Tis better for us to do it and leave the wizards to their strange alchemy IMO. A little matrix showing what happens when you use different numbers in the |0| notation and sigfigs would probably be helpful. Franamax (talk) 21:11, 3 May 2009 (UTC)

Further comment: the thing is, the actual conversions are done using DP calculations, so the rounding issue is inescapable. Numbers can not be stored exactly in a fixed number of bits. Using single-precision, I can easily give you examples where A - (2*A - A) is NOT equal to zero. Double-precision just pushes the problem farther down, but it's still there. COBOL was a great language for letting you define arbitrary precision (PIC 999V9999) since the math was done on the actual decimal digits and the rounding was automatic - but it was made for writing accounting programs, not MediaWiki software. We're stuck with those niggly issues... Franamax (talk) 22:46, 3 May 2009 (UTC)

Yeah I see how it rounds to 0.76. It's just bad that it does. Anyone with an ounce (that would be a UK ounce) of sense will wonder why 3/4 rounds to 0.76. I know it's cos the metric tonne is a little shorter, but it's awkward, and (AFACT) there's no way to round it to 0.75, which is sig fig but not dp. I know there is a sig fig option but that won't work either, at least as far as I have tried.

The thing is though, .75 long tons X 1.01605 = .7620 metric tonnes, so forcing it to show as .75 would be wrong. Franamax (talk) 21:11, 3 May 2009 (UTC)

Obviously, I think we would all agree, one should not have to try at all to get these things right: it should "just work". Actually it usally does prety well; it's only the edge cases that end up here. And thank you to all the dedicated people working on this to make it better! So nice to have people who address criticsms constructively. SimonTrew (talk) 19:39, 2 May 2009 (UTC)

I've interleaved my responses, feel free to refactor them all down here if that's not to your taste! Franamax (talk) 21:11, 3 May 2009 (UTC)

The British Imperial ounce is slightly different from the US ounce, and the long ton is slightly different from the tonne. The calculations are done in floating point, floating point numbers are inherently inaccurate, and the arithmetic is actually done in binary floating point rather than decimal floating point, so there are bound to be fringe cases where you get a hiccup in the conversion process and get a different value every once in a while. These anomalies will probably occur at different values on different computers. The amazing thing is not that there are annoying discrepancies, but that it works as well as it does, considering the gyrations going on behind the scenes to do the conversions.RockyMtnGuy (talk) 06:36, 4 May 2009 (UTC)

I will accept that the UK and US ounces are a bit different and yeah it's hard to know which way to jump there cos I guess convert has to be accurate, but three quarters of an ounce is not, to a reader, 0.76: and I simply could not get it to round to three quarters, which was in a recipe, where nobody's gonna be using a measure that goes that close.

I'll argue as they day is long about FP innaccuracy, but you can represent 0.75 exactly in binary as 0.11. (And integers up to the size of the mantissa can also be exactly represented). I'm assuming it's using IEEE 754, not a BCD FP representation.

I've been a software programmer for about 25 years and it's tempting to have a go helping you with this template, but it seems a complicate one and probably too tricky for my first attempt, I should start with something simpler I think. Hence my criticism, which I hope is seen in the constructive manner it is written.

Best wishes to you all SimonTrew (talk) 13:38, 13 May 2009 (UTC)

Nomenclature measure/measurement

This topic has moved to WT:MOSNUM#Units of measure.

This is something I am going to take to WP:MOS talk or where anyone will listen. I should appreciate your views.

They are units of measure, it is redundant (and wrong) to call them units of measurement. Measurement is the process; a particular act of measurement gives you a measure. It is simply wordiness. SimonTrew (talk) 13:21, 2 May 2009 (UTC)

Sounds logical. And semantically correct. Logically speaking. Debresser (talk) 20:35, 3 May 2009 (UTC)

Measurement can mean either the process or the result. Using either is not "wrong", it is simply a matter of personal preference. _wjemather^bigissue 21:28, 13 May 2009 (UTC)

Problem with km/h ↔ mph

200 kilometres per hour (120 mph)

124 miles per hour (200 km/h)

The conversion from km/h to mph is wrong! axp_de^Hello! 19:12, 5 May 2009 (UTC)

It's not wrong. Please see the note on the significant figures in the Rounding section of the template documentation. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 19:16, May 5, 2009 (UTC)

What?? Do you honestly call 120 mph = 200 km/h = 124 mph "correct"?!? Whatever you say, 120 is not the same as 124, thus the conversion of km/h to mph is definetly wrong! axp_de^Hello! 13:19, 7 May 2009 (UTC)

No one said that exactly 120 miles per hour is exactly 200 km/h. The short version is this: if I have speed that is exactly 200.000 km/h, the conversion {{convert|200.000|km/h|mph}} provides this output:

200.000 kilometres per hour (124.274 mph)

Try 200 km/h (124.274 mph)! See my comments below towards the end. Peter Horn 14:23, 13 May 2009 (UTC)

(For other ways to get this level of precision without specifying the ".000" part, read the template documentation.) But most people, when they speak of a speed of 200 km/h generally mean about 200 km/h, which is what {{convert|200|km/h|mph}} provides:

200 kilometres per hour (120 mph)

It's exceedingly silly for me to say something with a speed of about 200 km/h translates to 124.274 mph. User:Ëzhiki urged you to read the discussion of significant figures in the rounding section of the template for all the details, and I will encourage you to do the same. — Bellhalla (talk) 17:41, 7 May 2009 (UTC)

What's the sense of rounding to 120 mph instead of 124 mph?? If I want to convert 200 km/h (which for example is the exact value of top speed for German Intercity), I want a converted value of mph of the same accuracy! Normally you tell a function to round if you want to, not the other way round! axp_de^Hello! 20:53, 8 May 2009 (UTC)

But it is impossible for the template to know whether "200" is precise or general...more often, it will be a general figure, so the template deals with significant digits. This is easily dealt with by using {{convert|200|km/h|mph|0}} → 200 kilometres per hour (124 mph). That zero at the end tells the template to round to the decimal point, rather than to a significant digit. — Huntster (t • @ • c) 22:45, 8 May 2009 (UTC)

Hmmm, you're talking about "a significant digit", 120 has two significant digits ... so what do you call "a significant digit" ?!? axp_de^Hello! 08:56, 9 May 2009 (UTC)

P.S.: Where is your "rounding to a significant digit" with {{convert|125|mph|km/h}} → 125 miles per hour (201 km/h) ?!? axp_de^Hello! 09:09, 9 May 2009 (UTC)

{{Convert|125|mph|km/h}} is doing just what it's supposed to do: rounding output to the same precision as the input. Just as there is no problem with {{convert|200|km/h|mph}}. The sense in it is that the template reads the precision of the input: 200 km/h is precise to the nearest 100 km/h. A similar precision would be the nearest 100 mph, however, 200 km/h ≈ 100 mph is not particularly accurate. To deal with this kind inaccuracy the template is designed to output a minimum of two significant figures (though it has been argued that even this may be over doing it). Thus you get 120 mph. So, you argue

If I want to convert 200 km/h (which for example is the exact value of top speed for German Intercity), I want a converted value of mph of the same accuracy!

As I've demonstrated this is what the template is designed to do (you mean precision not accuracy). You point out that

Normally you tell a function to round if you want to, not the other way round!

You do have that option (as has been noted). One of the strong points of {{convert}} (if I may boast) is that you can let the template take care of things by itself ... and it generally does a decent job. JIMp _talk·cont 18:33, 11 May 2009 (UTC)

Satisfactory results may be obtained by 200 km/h (124 mph) or 200 km/h (124 mph). If more precision may be "required" or requested. try 200 km/h (124.3 mph), 200 km/h (124.27 mph) or 200 km/h (124.3 mph), 200 km/h (124.27 mph). One only needs to "play" with |0|, |1|, |2| etc. etc. or |sigfig=3|, |sigfig=4|, |sigfig=5| etc. etc. Peter Horn 15:18, 12 May 2009 (UTC)

Malfunctions in fractions

Note that fractions it not yet functional for everything. It's still in the prototype stage and works only with abbr=on; linking, adjectives (& sing) and disp left as their defaults; and only for some (most) units. JIMp _talk·cont 06:16, 7 May 2009 (UTC)

Note also that the default rounding does not currently work with fractional input. JIMp _talk·cont 18:39, 11 May 2009 (UTC)

Fractions of a mile

How do I convert a mileage that has a fraction in it so that it displays as a fraction and not a decimal? For example 15¾ miles (25.4 km). If I've read it correctly, {{convert|15+¾|mi|km}} should work, but neither it or {{convert|15+¾|mi km}} work.

• {{convert|15+¾|mi|km}} miles (km)
• {{convert|15+¾|mi km}}

Also, I don't want the "+" to show in the conversion. Any suggestions? Mjroots (talk) 08:28, 6 May 2009 (UTC)

It currently won't give conversions as fractions. Nor will it accept the pre-made fraction characters: enter it as 15+3/4 ... but better hold out till it working properly. Jimp 08:37, 6 May 2009 (UTC)

I've currently done a manual conversion on {{Kent and East Sussex Railway}}. Distances were obtaine by a decimal milage conversion and then transposed to fractions and conversion. Mjroots (talk) 10:02, 6 May 2009 (UTC)

15+3⁄4 miles (25 km) or 15+3⁄4 miles (25.3 km) now work just fine. Peter Horn 14:30, 13 May 2009 (UTC)

Wrong answer for {{convert|11+1/4|in|cm|2|abbr=on}} - 11+1⁄4 in (11.64 cm) vs expected (28.58 cm)

Moved from higher up because it seems to be the same issue! — Martin (MSGJ · talk) 15:46, 6 May 2009 (UTC)

{{convert|11+1/4|in|cm|2|abbr=on}} Gives the following result: 11+1⁄4 in (28.58 cm). {{convert|11.25|in|cm|2|abbr=on}} gives this result: 11.25 in (28.58 cm).

As of 4May2009, it yields 11.64 cm; one expects a result closer to 28.59 cm.

This is the example given at Template:Convert#Parameters, for "Display input value as a fraction," last row in the table.

--AndersW (talk) 09:21, 4 May 2009 (UTC)

Just encountered this problem as well -- the code which deals with fractions seems to need some tweaking? Fattonyni (talk) 14:22, 6 May 2009 (UTC)

Tweak LoffAonDbSoff

{{edit protected}}

Here's the new code for Template:Convert/LoffAonDbSoff (edit | talk | history | links | watch | logs)

{{convert/numdisp|{{{1}}}}} {{{u}}} ({{convert/{{#if:{{{2|}}}|{{{o}}}|{{{3}}}}}|{{{1}}}|({{{1}}})*{{{b}}}|{{#if:{{{2|}}}|{{{3|}}}|{{{4|}}}}}|{{{s|}}}|r={{{r}}}|j={{{j}}}|d=LoffAonSoff}})<noinclude>
[[Category:Subtemplates of Template Convert]] {{pp-template|small=yes}}
</noinclude>

Jimp 08:37, 6 May 2009 (UTC)

 Done. This request has nothing to do with this thread though? I think we need a reorganization here ... — Martin (MSGJ · talk) 15:44, 6 May 2009 (UTC)

Threads moved about! — Martin (MSGJ · talk) 15:47, 6 May 2009 (UTC)

{{edit protected}} That seems to fixed things. Now let's get the same done for Template:Convert/LoffAoffDbSoff (edit | talk | history | links | watch | logs)

{{convert/numdisp|{{{1}}}}} {{#ifeq:{{{1}}}|1|{{{n}}}|{{{l|{{{n}}}s}}}}} ({{convert/{{#if:{{{2|}}}|{{{o}}}|{{{3}}}}}|{{{1}}}|({{{1}}})*{{{b}}}|{{#if:{{{2|}}}|{{{3|}}}|{{{4|}}}}}|{{{s|}}}|r={{{r}}}|j={{{j}}}|d=LoffAonSoff}})<noinclude>
[[Category:Subtemplates of Template Convert]]{{pp-template|small=yes}}
</noinclude>

JIMp _talk·cont 06:08, 7 May 2009 (UTC)

What is the change from formatnum to convert/numdisp for ? I can't grasp it from the discussion here. —TheDJ (talk • contribs) 00:35, 8 May 2009 (UTC)

{{convert/numdisp}} can handle fractions and negatives. JIMp _talk·cont 11:45, 8 May 2009 (UTC)

 Done. I also restored the nbsp's in both templates, which seem to had get lost in copy pasting of the wikicode. —TheDJ (talk • contribs) 14:33, 9 May 2009 (UTC)

Alcoholic content

Since I'm on a roll, how about Alcohol by volume against Alcoholic proof (respectively ABV and proof spirit redirect to those pages). These terms are often confused. Proof spirit is, at least in UK according to my Collins, 49.28% of alcohol by volume, 57.1% by weight, in water at 48 °F (9 °C). SimonTrew (talk) 13:05, 2 May 2009 (UTC)

Harrr, Billy (Simon, whatever), have you ever been to sea? Have you ever seen rum proofed? The traditional test in the British navy was to mix the rum with gunpowder and touch a match to it. If it burst into flames, it was 100 proof. On the other side of the sea (the United States), it was twice the percentage of alcohol by volume at a temperature of 60°F (15.5°C). Since Britain joined the EU, it is supposed to be the percentage of alcohol by volume at a temperature of 20°C, not the old naval proof test.RockyMtnGuy (talk) 18:34, 3 May 2009 (UTC)

Well I managed to ruin the insides of a hovercraft with chewing gum when I was about seven years old, does that count? Personally I tend to test my christmas puddings by making sure they light up, if not, add more brandy. And if so, oh dear, you've just burned it off... add more brandy. My puds are probably about 300 proof. And they let me give it to children! (Don't tell them that the sauce is about 500 proof....)

But seriously yeah you have a good point, that's maybe then not going to be as simple as I thought if the measure has changed a lot. I get fed up with people thinking 100 proof is 100% alcohol. The match test I believe is valid, I would have to look up the figures, but it is down to the boiling point/volatility of alcohol (ethanol) which is quite low, but when held in an aqueous solution it is unlikely to burn.

Assuming, me hearty, your suggestion was at least half serious, what should we do here? Nothing, perhaps, and just add mention into the alcoholic proof and ABV articles? It's mostly the current US/everybody else conversion that I think important, since of course many other units have changed over time. The UK govt also generally takes 25ml=1 unit of alcohol, though I think this is technically incorrect because spirits generally are now watered down to 37.5% not 40%, the cheating hounds.SimonTrew (talk) 20:43, 3 May 2009 (UTC)

I believe, by the way, the gunpowder test was made to prove the quality of the gunpowder, not the rum. SimonTrew (talk) 21:35, 3 May 2009 (UTC)

I think the point I was trying to make (before I got too deeply into the rum) was that there are two different systems of measuring alcoholic proof: the British Imperial System, and the American system, neither of which equals percentage. This is consistent with all other liquid measures - none of which are the same between the traditional UK and US systems. The Brits and Yanks could never agree on anything of a liquid nature.RockyMtnGuy (talk) 06:03, 4 May 2009 (UTC)

Yeah the damyanks even got short measures at the Boston Tea Party. SimonTrew (talk) 17:08, 13 May 2009 (UTC)

We could go "such-and-such degrees proof (UK)" vs. "so-and-so degrees proof (US)" or something like we do for the various gallons, pints, etc. but it seems that what's really getting in the way is the temperature issue. If ABV is at 20 °C and US proof is at 60 °F we can't really expect any linear conversion between them ... can we? I'm guessing that the UK proof is something similar. JIMp _talk·cont 18:47, 13 May 2009 (UTC)

In Europe things are always specified as Alcohol by volume (ABV) and in the US (I believe, I've not been there for a whole) as "percentage proof". The essential problem here is one is a volumetric measure and one using an implicit unit. I think, therefore, we can dismiss the trouble with what proof is in the UK (that can go into an article such as Gunpowder) but to get a practicle everyday conversion: VERY roughly speaking it's twice as much proof as ABV. But I don't know how the templates work and I know they don't do dimensional analysis (a good thing as I've said before) it's translating a volume into an dimensionless unit (proof). As long as the US proof measure is accurate I would be happy with that.

I know we have to cater for audiences neither in the UK or US but that would be a start. I am not sure what Canada does, I think they use the same proof measure as US, but my memory is a little hazy; obviously outside the EU it may also be different, but giving the ABV gives an exact measure which nobody can complain of, to convert to US proof measure for US audience that's good, I think. To put as UK proof is entirely pointless cos nobody uses it here. SimonTrew (talk) 19:35, 17 May 2009 (UTC)

Ah you said something I only just noticed. Of course it is degrees proof not percentage proof. SimonTrew (talk) 19:38, 17 May 2009 (UTC)

Canada uses percent alcohol by volume, usually abbreviated "% alc./vol" since that is the same in both English and French. In the US, liquor labels must state the percent of alcohol by volume, although they can optionally give the (US) proof if they want to. In the US, proof is twice the percent by volume, i.e. 50% alcohol by volume is "100 degrees of proof". In the UK it is i.e. 1.75 times the percent by volume, so 50% would be "87.5 degrees proof" - except that the UK stopped using the proof system in 1980. In the US alcohol content is measured at 60 °F (15.556 °C), in the UK before 1980 it was at 51 °F (10.556 °C), and in European countries it is at 20 °C (68.00 °F). RockyMtnGuy (talk) 03:23, 18 May 2009 (UTC)

Hmmm that would seem like a good idea to drop the conversion proposal then. My remaining concern is since I mentioned it in the first place, I can't be the only one. But yeah, if it's in ABV pretty much anywhere it's pointless to put it in proof I think? But I'm glad it was discussed SimonTrew (talk) 06:39, 18 May 2009 (UTC)

Fantastic work

Hello all, would like to thank everyone for their contributions to this template. It certainly has come a long way since I created its first stable version... I have not been around to maintain or improve it so I am thankful that the community has done such a fantastic job transforming it into something extremely useful.

I would wager that probably 20% of the pages on the English Wikipedia employ the template. But then, I really have no idea. Someone should check, I remember a wikimedia tool server that used to check things like that, but I have no idea where it has gone.

Anyway, well well well done, to all involved!!! drumguy8800 C T 05:33, 19 May 2009 (UTC)

Hello Drumguy,

I'd always felt a little bad for the part I played in completely reworking your creation beyond all recognition but I'm glad to read that you're happy with the direction in which it has been taken.

JIMp _talk·cont 17:30, 21 May 2009 (UTC)

More units we might want

Cup (1/2 pint, 8 fl oz)-- very common in US cookery, unheard of in UK as a formal measure. SimonTrew (talk) 13:05, 2 May 2009 (UTC)

There are so many cups. The US cup may be 8 US fluid ounces but Aussies use a cup of 250 ml. Of course, we can handle that like we do other volumes. JIMp _talk·cont 00:56, 3 May 2009 (UTC)

Yeah I think it's best to forget this one. Americans will be able to work out a cup is half a pint and nobody else can fathom it anyway.

Can we have fathoms then? :) SimonTrew (talk) 19:44, 17 May 2009 (UTC)

{{convert|10|fathom}} → "10 fathoms (60 ft; 18 m)" JIMp _talk·cont 17:33, 21 May 2009 (UTC)

Haaarrr! Have you ever been to sea, Jimpie???? The old charts such as are still used by the Yankees are all in fathoms and feet, and the conversion is to decimal metres. For instance, 10 fathoms 4 feet is 13.12 metres. The reason is that a fathom is the distance between your outstretched hands as you're hauling up the leadline, and what's left over after the last fathom you can estimate in feet. Next, you can convert nautical miles and cables to decimal kilometres for the benefit of those still navigating with sextants instead of GPS receivers.RockyMtnGuy (talk) 18:18, 22 May 2009 (UTC)

Miles and feet conversion

I'm trying to convert "26 miles 385 feet" into km at List of winners of the London Marathon, but I'm having trouble working the template. How do I fix it, please? Matthewedwards :  Chat  23:50, 16 May 2009 (UTC)

The miles subtemplate needs to be adjusted to allow for it. It would also be good to allow for miles & furlongs too (for horse racing as mentioned above). JIMp _talk·cont 19:03, 17 May 2009 (UTC)

Shouldn't that be 26 miles and 385 yards? The distance for which the Marathon article states. —MJCdetroit ^(yak) 18:03, 19 May 2009 (UTC)

Yes it should be, I imagine it was just a slip. SimonTrew (talk) 17:03, 21 May 2009 (UTC)

Yes, yards :) Matthewedwards :  Chat  20:26, 21 May 2009 (UTC)

What about furlongs and chains? (If I didn't remember that an acre was one furlong in in length by one chain in width, I'd never be able to figure how big it was. :) RockyMtnGuy (talk) 18:33, 22 May 2009 (UTC)

Area conversion (X by Y)

There seems to be an inconsistency when using the template to convert an area (X by Y). The original comes out as 'X by Y [uom]', yet the conversion comes out as 'X [uom] × Y [uom]'. Shouldn't it be consistent and use the unit of measure after each param or only at the end?

Input	Currently Displays as	Recommended Display
{{convert|60|by|120|m|ft}}	60 by 120 metres (200 by 390 ft)	60 by 120 metres (200 × 390 ft) or 60 metres by 120 metres (200 ft × 390 ft)

-- BullWikiWinkle 20:27, 22 May 2009 (UTC)

This is, as I recall, intentional. Only abbreviated units will appear with the unit beside both numbers. You can see this by appending |abbr=on to the template, which forces both the input and output to be abbreviated, as with {{convert|50|by|100|m|ft|abbr=on}} → 50 by 100 m (160 by 330 ft). — Huntster (t • @ • c) 22:59, 22 May 2009 (UTC)

Thanks for the explanation. -- BullWikiWinkle 06:28, 24 May 2009 (UTC)

Rounding

The Tropical Cyclone Wikiproject does not use the convert template in its articles as it needs to round to the nearest 5 to follow what the RSMCs and TCWCs (official reporting agencies) use in their operational and post storm products. Would it possible to expand the convert template by adding a "rounding parameter" to make the template more useful? Suggested enhancement would be":

• "|rndto=X" - round to the nearest X, ex: "rndto=5" would cause 42 to become 40
• "|rndup=X" - round up to the nearest X, ex: "rndup=5" would cause 42 to become 45
• "|rnddown=X" - round down to the nearest X, ex: "rnddown=5" would cause 42 to become 40

Such an enhancement would allow this project (and possibly others) to use this very useful template and help our readers by using dimensions and units that they are familiar with. Could someone with programming knowledge comment. Thanks. Truthanado (talk) 01:57, 26 May 2009 (UTC)

Someone else will probably jump on this as well. The template only performs rounding on the converted value not the input value. The rounding of the value provided by the official reporting agencies should relate to the accuracy of the recording equipment. The value that the template converts from this should be able to reasonably reflect the precision of the original value. In general, use the value that can be cited and then use the template to provide an approximate conversion into another system of units. Unless you are converting to the same units that you start with the reasonable precision of the output will not be to the nearest 5. Do you have some article examples? Some other things; are you a member of the Tropical Cyclone Wikiproject? I didn't notice your user name on the project page. No biggie, though. Knowing that what you are asking is close to the consensus of the project would add more weight. I had a quick look at Hurricane Charley, which does use the template, sometimes. Could you also give some examples of actual source info that is used as a reference that shows that nearest '5' thing? Thanks. 04:35, 26 May 2009 (UTC)

Truthanado, if you are referring to your dustup with User:Jason Rees at Cyclone Aila I wouldn't worry about it. User:Thorwald set him straight. The article now has several shiny examples of {{convert}}. Bleakcomb (talk) 05:27, 26 May 2009 (UTC)

Singular for -1 thro' 1 values?

I am using the Convert template to generate the following text: "0.0074 acres (320 sq ft; 30 m²)". I think it should display as "0.0074 acre (320 sq ft; 30 m²)" using my first-grade teacher's rule that plural is for values greater than one (also less than -1, I presume). Should the template be able to generate this automatically? Can a forced-singular parameter be set? Or is there a better work-around? — Eoghanacht ^talk 10:13, 21 May 2009 (UTC)

There seems to be some "manual of style" issues. My reference for the unit actually states "containing 0.0074 acres more or less" (Calvin Coolidge, presidential proclamation #1745, 1925 September 5) but the current GPO style manual gives an example of "0.25 inch" (Chapter 12.9d). — Eoghanacht ^talk 10:55, 21 May 2009 (UTC)

I disagree: decimal figures are always plural to me ("zero point two five litres"). I'd agree that fractions between -1 and 1 should be singular, but not decimals. Chris Cunningham (not at work) - talk 10:59, 21 May 2009 (UTC)

Yeah I would find that weird in singular, I disagree too. I imagine wanting it singular is hypercorrection, but I am British, perhaps it's a regional thing? SimonTrew (talk) 17:00, 21 May 2009 (UTC)

Gene has brought this up too. He also follows this rule but it doesn't seem right to me. Could it be a dialect thing? Should we bring it to MOS? As for forcing singular forms (which would make perfect sense if it is a dialect thing), yes, it could be set. In fact sing could be used for the job but this would take a couple of things: firstly sing now works like adj so before sing gets changed all the current sings out there would have to be changed to adjs (or at least checked to make sure that they should stay as sings), secondly some major changes need to be done to how the template works. You'll probably guess that this is going to take some time ... plenty of time to thrash this out at WT:MOS/WT:MOSNUM and finally get to the bottom of this singular-between-plus-&-minus-one business. JIMp _talk·cont 17:24, 21 May 2009 (UTC)

I started a discussion on WP:MOS(numbers) talk on the matter. I still think singular is logical, but since when is language logical? I never readed or heared an irregular verb I didn't put to use. — Eoghanacht ^talk 01:38, 22 May 2009 (UTC)

I say "0.75 of an acre" and "75% of an acre" and "three quarters of an acre". -- Wavelength (talk) 02:24, 22 May 2009 (UTC)

From here and the other talk page, there does not seem to be enough concensus to set a rule one way or the other. From a programming perspective for the template, I presume it is easiest just to leave it as-is (plural). — Eoghanacht ^talk 15:02, 28 May 2009 (UTC)

Avoiding unicode fractions

Can we please be generating HTML fractions for {{convert|9+3/4|...}}. The display of Unicode fractions is inconsistent with other subscripts, relies on the font having the glyphs and presents accessibility issues. —Sladen (talk) 01:10, 28 May 2009 (UTC)

Can you please perhaps expand a bit on this? I am not saying you're wrong, just perhaps some more information would better support your argument.

• Why should fractions be consistent with other subscripts/superscripts? Part of the aim of convert, as I see it, is to provide measures in a way that is natural for an "average" reader of a particlar article, and I don't necessarily see that using the composited characters is out of line with that, for common fractions.

• The font hints + glyph rendering engine *should* manufacture approximate characters using composition, shouldn't it? Whether it does or not of course is a different matter.

• What accessibility issues? Are you saying e.g. a speech browser will not necessarily know how to say "one-half" or "three-eights" if it sees them as a UNICODE character? But then why would saying "nine plus three slash four" be any more "accessible"? My good friend heads up the test department of a respected electronic publishing firm, I can ask her about it if you want.

Thanks. SimonTrew (talk) 08:49, 29 May 2009 (UTC)

I'm not quite sure what you're saying. The fraction display was intended to be consistant with {{frac}}.

• {{convert|1+1/2|mi}} → "1+1⁄2 miles (2.4 km)"
• {{frac|1|1|2}} → "1+1⁄2"

JIMp _talk·cont 17:44, 29 May 2009 (UTC)

Are these template mods OK?

New-ish user Depictionimage (talk · contribs) has been doing some work on Convert templates - see his contributions in the early hours of 30 May. I may be doing him an injustice, but on the basis of some of his other edits I am not entirely sure he knows what he is doing. However I certainly don't - could someone who knows take a look and see if all is well? Regards, JohnCD (talk) 19:37, 30 May 2009 (UTC)