Template talk:Convert/Archive December 2007

This template violates the dates and number style manual

I read "6 hectares" in an article and changed it to "six hectares". I got an error message. Please look at Wikipedia:Manual of Style (dates and numbers). Can this be fixed? Michael Hardy 03:03, 2 December 2007 (UTC)[reply]

I've always understood conversion instances to be an exception to that guideline...Wikipedia:Manual of Style (dates and numbers)#Conversions uses an example of "4 inches (100 mm) in diameter". MoS also mentions it isn't a good idea to mix cases...either use numeric form in number groups or spell them out. It would be impractical for the code to handle such instances as "8 meters (26 feet)" and "two inches (five centimeters)", in my opinion. -- Huntster ^{T • @ • C} 05:14, 2 December 2007 (UTC)[reply]

It isn't really an exception the last I saw, and if it were it should be based, as I have argued on Wikipedia talk:Manual of Style (dates and numbers), on it being a measured quantity, not on whether or not that quantity is converted. But in any case, it should only be permissible numerals rather than spelled out words, not required numerals. The problem here, of course, lies mostly in the philosophy that {{convert}} should be used for all measurements in Wikipedia. It should not be.

Michael Hardy, you can fix it by simply not using the template. Use it to get the number if you want to, then simply change it to text. Add a comment in the text (see Wikipedia:How to edit a page#Character formatting), and perhaps on the talk page too, if you want to discourage others from substituting the template in the future. They won't have to agree with you, of course, but you will have sound basis for reverting them unless it been discussed. Gene Nygaard 14:06, 2 December 2007 (UTC)[reply]

However, in any case, the spelled out numbers should only be used with the spelled out symbols. In my book, it would be this way:

Acceptable: five centimeters, 5 centimeters, 5 cm

Unacceptable: five cm

This would be supported, for example, in NIST SP811, Guide for the Use of the International System of Units (SI), 1995. Gene Nygaard 14:11, 2 December 2007 (UTC)[reply]

"Can this be fixed?" What, the template or MOS:NUM? Sure, either can be fixed. The template could be adjusted to allow for the spelling out of numbers (either by allowing another value for abbr to take or by introducing a new parameter (the more intuitive but pre-expand-size-eating option)). What, however, is the actual practice on WP? Numbers when they appear as part of a measurement are generally not spelt out. Examples of this abound even, as noted by Huntster, on the MoS. One could interpret measurements as not being just numbers and the rule therefore not applying ... my guess would be that that had always been the underlying assumption. If so, however, this is something which ought the be made more obvious but this is not the place to discuss this. --J ɪ m p 14:57, 2 December 2007 (UTC)[reply]

Feature request: commas in numerical field

Please can the template be updated to permit commas in the numerical field. This would:

make it simpler for manual cut and paste
make script coding a lot simpler
make the raw edit text marginally easier to read
make the raw edit text more consistent with the output text

Thanks Lightmouse 14:24, 2 December 2007 (UTC)[reply]

I'm afraid I don't think that that's possible. Include the commas and the number is no longer recognised as such. --J ɪ m p 14:57, 2 December 2007 (UTC)[reply]

The only thing I can think of would be to comment the commas out, e.g. {{convert|10234567|m}} (which still gives 10,234,567 metres (33,577,976 ft)). It doesn't achieve all of your aims, of course. --J ɪ m p 17:51, 3 December 2007 (UTC)[reply]

OK. I will continue to remove commas before pasting. Thanks for the response. Lightmouse 19:00, 3 December 2007 (UTC)[reply]

06-Dec-2007: The template/language processing in December 2007 is still handled by MediaWiki version 1.6, which has no parser functions to look inside a numeric field. Wikipedia is based on MediaWiki 1.6 software which is, unfortunately, still a beta-level technology, somewhat at the level of stub articles which still have spelling/grammar errors. Like stub articles drafted by novices, the MediaWiki 1.6 language is NOT at the level of computer-language technology developed 30 or 40 years ago: it cannot "substring" values to check for commas, and it does not allow local variables to be defined in a template, even though both options would be trivial to implement, even by a college freshman. Because other computer-language technology today is very advanced, a revolution in Wikipedia software might happen within a few years, if experienced computer scientists work on the MediaWiki software. The current MediaWiki 1.6 software is very primitive: it doesn't even allow a trivial search-and-replace when editing an article, and such string-substitution can be implemented in less than 3,000 lines of computer program code, with "undo" treated as multiple inserts. Anyway, thank you for your patience in tolerating today's limited Wikipedia software. -Wikid77 (talk) 14:32, 6 December 2007 (UTC)[reply]

I have found a crude work around. I let the script copy and paste the numerical value including the commas. Then I search for convert templates containing commas and fix them. It is ugly but seems to work. Lightmouse (talk) 17:29, 6 December 2007 (UTC)[reply]

Doesn't handle negative numbers?

Interesting error appeared at some point over at Uluru, in which the template errored after encountering a negative number, as in, -5 °C. Diff here, scroll down, it's impossible to miss. The entire code was: {{convert|-5|°C|°F|0|abbr=on}}. -- Huntster ^{T • @ • C} 14:42, 3 December 2007 (UTC)[reply]

My mistake, it's been fixed, sorry about that. J ɪ m p 15:53, 3 December 2007 (UTC)[reply]

Using

{{convert|-5|°C|°F|0|abbr=on}} now gives −5 °C (23 °F)

copying the then-displayed original number into the template

{{convert|−5|°C|°F|0|abbr=on}} gives −5 °C (23 °F)

Gene Nygaard 16:43, 3 December 2007 (UTC)[reply]

I guess we might warn users that only the hyphen works as a minus sign when used as input in the template (true not only for this but all templates which do any calculation with that input number) and note that although it is the hyphen which is input the output is the proper minus sign in accordance with the manual of style (we surely wouldn't want to display negatives using the far-to-short hyphen as the minus sign, e.g. -5 °C (23 °F)). J ɪ m p 17:40, 3 December 2007 (UTC)[reply]

The template documentation also fails to warn editors, in regards to Lightmouse's request above, that numbers must be entered without any thousands separators. Gene Nygaard 19:04, 3 December 2007 (UTC)[reply]

No template can handle commas, spaces, real minus signs (i.e. the non-hyphen type), real multiplication signs (i.e. × as oppposed to an asterisk), division signs (i.e. ÷ as opposed to the slash), curly brackets or square brackets as numerical input for the purpose of calculations. Yes, it is only fair that there be a warning, some templates have them. It might be worth-while creating a warning template for such a purpose: editors will recognise it at a glance if they've seen it on other templates and might come to understand that this applies to all templates which do calculations with numbers. --J ɪ m p 19:47, 3 December 2007 (UTC)[reply]

Summarized optional parameters in doc

06-Dec-2007: I have changed the documentation subpage in Purpose and Usage to clearly mention "optional abbreviation or slash" along with "optional U.S. spellings or hyphenation" to quickly alert users to the wider range of capability. It seemed obvious that the spelling of "metres" might quickly deter U.S. users unless also mentioning "optional U.S. spellings" (also the issue of being "quickly deterred" might itself be a concern in some parts of the U.S. rather than worldwide). The Notes section now briefly summarizes options as "abbreviated units (abbr=on), or U.S. spellings (sp=us for "meter"), or slash separation (disp=slash), or hyphenation (adj=on)" for similar rapid information. As major options are implemented, the documentation should probably also reflect those in a succinct manner. -Wikid77 (talk) 13:00, 6 December 2007 (UTC)[reply]

Implementation notes

06-Dec-2007: The next 3 discussion topics, here, have been added to the documentation subpage as "Implementation notes" to help users understand how many times Template:Convert can be used (per page) without fearing overuse of templates. I have repeated the text here, as 3 topics, to simplify possible discussions about the details in each section of the Implementation Notes.

Testing in December 2007 showed that Template:Convert can be used more than 300 times on one page to quickly display converted measurements, on pages that also use large templates such as infoboxes or mapper templates. Implementation is handled by invoking a few small subtemplates, selected by name substitution, where names depend on the conversion units and option names in use. There is no giant, gargantuan all-units template that would process parameter values; instead processing is selected by name-substitution invoking a few subtemplates of the form "Convert/xxx_yyy" to branch by name, not by switch-statement logic. The detailed, intricate implementation is handled by invoking a few of over 1,010 small subtemplates, rather than using a monstrous all-units template, as might be imagined. -Wikid77 (talk) 13:50, 6 December 2007 (UTC)[reply]

Anomaly/error conditions

06-Dec-2007: Because implementation is handled by selecting a few small subtemplates, very little is used of the overall template-processing resources (in the MediaWiki 1.6 language). In the rare event that template resources are exhausted, the message "Template:Convert" has appeared, repeated for each instance of the template:

Template:ConvertTemplate:ConvertTemplate:ConvertTemplate:Convert

However, the source of the problem is likely to be another, somewhat large, template used on the same page, which has exceeded template resources. With most large templates, even used several times on a page, the Convert template can still be used over 150 times per page. -Wikid77 (talk) 13:50, 6 December 2007 (UTC)[reply]

Limited template resources

06-Dec-2007: The issue of limited template-processing resources (although a very-huge limit) occurs in the MediaWiki 1.6 template/parser language: it might not be such a problem in some future release, probably beyond MediaWiki 1.8.2. The problem also involves the infamous noinclude-tag ("<noinclude>") which is implemented, internally, to actually do the exact opposite and include the skipped text within the template-processing buffers. The included noinclude text, such as "Category:" links and interwiki language links accumulates in the template buffers to allow error-traceback linked to that text. When a template is invoked 100 times, then 100 copies of that noinclude Category/ interwiki text are stored in the processing buffers: the only reason it doesn't typically matter is that the template-processing buffers are absolutely, phenomenally huge (perhaps over 1.5 megabytes or 1536kb or over 24,000 lines of accumulated template text) for a single page.

The accumulation problem is related to the concept of a "memory leak" because each time a template is invoked, resources are eroded, and there is less buffer memory for processing the next template. Thinking of an article page as a template-expansion buffer is an analogy that illustrates the processing: rather than process templates serially, and accumulate only the results of expressions or if-statement logic, consider the page buffer as an expansion of all templates, all at once, until the entire page buffer is "de-templated" as a giant glob of inline text. In that analogy, all templates, as invoked, are duplicated umpteen times, repeating all if-statements and Category/interwiki links, over and over across the entire page buffer. There is a limit to that.

When space is critical, in a utility template used over 200 times, avoid Category-link and interwiki links, which should be moved to the "/doc" subfile, not included in the actual template as "noinclude" text: it is included during internal processing.

The hope for the future, from computer science, is that future versions of the MediaWiki language might process templates in serial fashion, deallocating intermediate space when a nested template is finished, and truly "nonincluding" the "<noinclude>" text as being totally omitted from the internal buffers. The current processing, however, is basically expanding each and every template (including noinclude-tag text) as a flat-text file into the template-processing buffers.

For those reasons, in MediaWiki 1.6, there is a limit to how many times template Convert can be invoked on one page, but the limit is over 300 times. -Wikid77 (talk) 13:50, 6 December 2007 (UTC)[reply]

Eliminating duplicate 'auto' conversion templates

Is there a bot available that could search articles and replace 'auto' conversion templates with this one where there is duplication? Lightmouse (talk) 15:05, 7 December 2007 (UTC)[reply]

Mine should be able to do that, but it will be a while before I could/can program it. —MJCdetroit (talk) 16:03, 7 December 2007 (UTC)[reply]

OK. Clearly it is not urgent. It is merely on the wishlist. Thanks. Lightmouse (talk) 16:06, 7 December 2007 (UTC)[reply]

Mark those templates as deprecated with {{tdeprecated|old template name|new template name|date=December 2007}}—MJCdetroit (talk) 16:19, 7 December 2007 (UTC)[reply]

Hold off on {{auto L/100km}} for the moment. --J ɪ m p 20:13, 7 December 2007 (UTC)[reply]

I don't agree with doing that for any of them without discussion. Certainly not without discussion of it on those template pages. I don't recall the editors creating this template being given any mandate in this regard, nor for issueing a different implementation. Gene Nygaard (talk) 18:55, 12 December 2007 (UTC)[reply]

Ranges

Would it be possible to have the template handle ranges? For example: 20–30 feet (6–9 m). —MJCdetroit (talk) 18:13, 7 December 2007 (UTC)[reply]

Anything's posible. Actually I have had a {{ConverRange}} in mind but had wanted to get this one "finished" first. --J ɪ m p 20:05, 7 December 2007 (UTC)[reply]

That would be extreemly useful, I currently find that I cannot consistently use the template in a article for lack of this feature. Gaius Cornelius (talk) 13:41, 9 December 2007 (UTC)[reply]

I agree. Although I recommend formats like '20 to 30 ft' and '20 to 30 degrees Celsius' rather than '20–30 ft' and '20–30 °C'. I avoid using anything that looks like a minus symbol (all horizontal line characters look the same to me). Lightmouse (talk) 14:12, 9 December 2007 (UTC)[reply]

Sorry, that was my error. What I meant was: 20 to 30 feet (6–9 m), but I see your point about the negative sign. So 20 to 30 feet (6 to 9 m) would work just as well. —MJCdetroit (talk) 02:24, 10 December 2007 (UTC)[reply]

What I had had in mind was to use en dashes with abbreviated unit names & to where the names are spelt out (as in MJCdetroit's example). However, I can't see anything wrong with using to for both. This would avoid decidedly confusing conctructions like "−40–−20°C" ("−40 to −20°C"). What about tables?

Table A
length/m	length/ft
10 to 20	30 to 61

verses

Table B
length/m		length/ft
min	max	min	max
10	20	30	61

or even

Table C
max length		min length
m	ft	m	ft
10	30	20	61

I had been thinking B but C doesn't look too bad. J ɪ m p 00:00, 11 December 2007 (UTC)[reply]

I did not know that you were contemplating creating new table columns. I thought that editors would simply use the template inside the table and therefore create version A. But all three look fine to me except for the use of the slash '/' character. I prefer unit symbols to be inside parentheses. Thus "Speed (km/h)", this avoids formats like: "Speed/km/h". Lightmouse (talk) 18:37, 11 December 2007 (UTC)[reply]

←outdent←
B or C aren't a great deal harder to code than A and perhaps a fair bit easier to read. As for the slash ... I kind of like slashes for this since they kind of make sense: take a measurement "divide" it by a unit and get a plain number ... but you're right "Speed/km/h" is undesireable, however, I've grown so attached to that slash that I'd be likely to go for "Speed/km·h⁻¹". Of course, it doesn't matter to the template because the template will just give the numbers the labels in the tables will have to be typed seperately i.e. to produce table C, for example, you'd use the following.

{|class=wikitable
|-
!colspan=4|Table C
|-
!colspan=2|max length
!colspan=2|min length
|-
!m
!ft
!m
!ft
|-
|{{ConvertRange|10|20|m}}
|}

J ɪ m p 19:11, 11 December 2007 (UTC)[reply]

The notion of mixing together slashes for division and negative exponents on units in the same page falls under the category of really dumb ideas. Gene Nygaard (talk) 18:58, 12 December 2007 (UTC)[reply]

You wouldn't really read "Speed/km·h⁻¹" as "speed divided by kilometres per hour" but as "speed in kilometres per hour" ... hey, it could still be a really dumb idea. Of course, if you mean using both "km·h⁻¹" and "km/h" on the same page ... yeah, that's in the dumb-idea category. J ɪ m p 20:20, 12 December 2007 (UTC)[reply]

That's the part I meant, both "km·h⁻¹" and "km/h" on the same page. That, of course, is just another of the problems of trying to create a "for all times, for all people" conversion template: to achieve it, you'd have to have the exponential units option for any units involving division. And, even more importantly, you'd have to have editors adding templates who check the existing usage on the page, and/or other editors who both see the problem and are aware of all the intricacies of this template to be able to fix it if they did not do it right. If the conversions are plain text, most editors could fix it. But with conversion templates being used, it is harder to notice the problem in the first place (being totally invisible on the edit screen itself, let alone to be able to fix it. Gene Nygaard (talk) 13:14, 13 December 2007 (UTC)[reply]

Furthermore, I would point out have never much liked slash separators between a measurement and its conversion in any context. But it is especially bad with a spaced slash, and even worse without nonbreaking space at least before the slash. Furthermore, in the case of conversions within parentheses, for example, there are several other possible options:

Square brackets inside round brackets
Often a comma will do as well a slash
It is usually much easier to read and less likely to confuse anybody if you simply insert a word such as or between the numbers. There might be other possibilities, depending on the context.

Example: The tailwind exceeded the 2 meters per second (7.2 km/h or 4.5 mi/h) allowed for setting a record.

Gene Nygaard (talk) 13:38, 13 December 2007 (UTC)[reply]

Response to Jimp's "What I had had in mind was to use en dashes with abbreviated unit names & to where the names are spelt out (as in MJCdetroit's example)."

It is actually a whole lot more complicated than that. For example, our conventional English formulation when preceded by the word "between" doesn't use the preposition "to", rather we normally use "between ____ and ____". Furthermore, when it involves spatial dimensions, the components are often separated either by the word by or by a multiplication sign × or x. Furthermore, they often include interspersed among the units an identification of those dimensions with words such as "high", "long", "wide", "deep", etc. (and that is something that doesn't necessarily need to be repeated in the converted equivalents; readers can reasonably be trusted to assume that they remain in the same order, without even having to point that out). I'm sure there are a number of other ways in which these multiple conversions occur as well, each with different conventional wording, often with several possible alternatives but not necessarily including "to" nor a dash among the options. Gene Nygaard (talk) 13:23, 13 December 2007 (UTC)[reply]

Pluralisation

I have used this template to add a conversion to the St Albans article. However, I am slightly concerned that the output appears as 750 metres (820 yd). I believe the singular yd makes this look slightly odd. How do I change this to the plural yds (or yards) using this template? Andrew (My talk) 20:13, 10 December 2007 (UTC)[reply]

You can't. At least not that I'm aware of. The reason that it is 'yd' and not 'yds' is because that is what the Manual of style's section on Units says to do. That point in the MOSNUM is not likely to change anytime soon. If it still bothers you, then maybe you can switch the order to 820 yards (750 m) as most of the article is already imperial (metric). —MJCdetroit (talk) 21:16, 10 December 2007 (UTC)[reply]

Okay, thanks for your help. Andrew (My talk) 23:28, 10 December 2007 (UTC)[reply]

No, you can't. Of course, it would be a simple matter to make this an option but since it's against the MoS, I won't. If you're changing the order, why use {{convert}} at all? Instead, just type it out longhand and with a footnote stating that the metric value was the original (if this is the case). J ɪ m p 23:37, 10 December 2007 (UTC)[reply]

Don't be switching the orders willy-nilly either. Generally, the original measurement should come first. Gene Nygaard (talk) 18:59, 12 December 2007 (UTC)[reply]

No. J ɪ m p 20:21, 12 December 2007 (UTC) ... That is I agree: no, no willy-nilly switching; yes, the original measurement should generally come first. J ɪ m p 06:44, 13 December 2007 (UTC)[reply]

Gal/mi and L/km

Can someone implement gallons per mile and litres per kilometre (for fuel economies of large vehicles, such as tanks)? I'd do it myself, but I...don't know how to handle the math the way this template has it set up. Thanks! Oc t ane ^{[improve me]} 11.12.07 1442 (UTC)

I got the impression above that that is something that Jimp is going to be working on. In any case, use Template:Mpg and Template:L/100km until {{convert}} has something to offer you. —MJCdetroit (talk) 14:58, 11 December 2007 (UTC)[reply]

I'm sorry, you did say "Gallons per mile"? I've never seen that, but then again I don't build tanks? Is this how fuel economies of large vehicles are stated? I'm sure we'll have something for you. —MJCdetroit (talk) 15:05, 11 December 2007 (UTC)[reply]

It's given both ways, depending on the source, but sometimes it's easier to say "8 gallons per mile" than "0.125 miles per gallon". Thanks for the links, though. Oc t ane ^{[improve me]} 11.12.07 1821 (UTC)

One furlong per gallon ... yeah, I will be working on it. The fact that it can be stated as distance per volume or volume per distance makes things all the more tricky otherwise I'd have it up and running already. J ɪ m p 18:54, 11 December 2007 (UTC)[reply]

Fuel efficency conversions are now up & running.

unit	code (alternative)	notes	combos
kilometres per litre	km/l (km/L)	Use `km/L` to get "km/L"	km/l mpgimp km/l mpgus
litres per 100 kilometres	l/100 km (L/100 km)	Use `L/100 km` to get "L/100 km"	l/100 km mpgimp l/100 km mpgus
litres per kilometre	l/km (L/km)	Use `L/km` to get "L/km"	l/km impgal/mi l/km usgal/mi
miles per imperial gallon	mpgimp		mpgimp mpgus
miles per US gallon	mpgus (mpgUS, mpgU.S.)	Use `mpgUS` to get "US" Use `mpgU.S.` to get "U.S." `mpgus` will give "U.S." if spelling is set to US & "US" otherwise	mpgus mpgimp
imperial gallons per mile	impgal/mi		impgal/mi
US gallons per mile	usgal/mi (USgal/mi, U.S.gal/mi)	As above with the `us` vs `US` vs `U.S.`	usgal/mi

The mpgUS, mpgU.S., USgal/mi vs U.S.gal/mi, km/L, L/100 km and L/km variants work within combinations also (making 36 combinations in total). J ɪ m p 07:10, 17 December 2007 (UTC)[reply]

Thanks muchly! Oc t ane ^{[improve me]} 26.12.07 1957 (UTC)

Chains, Rods and Perches + Fathom

CHain would be usefull for railways and Fathom for ships.--Kitchen Knife (talk) 13:43, 12 December 2007 (UTC)[reply]

So much so they are already done.--Kitchen Knife (talk) 13:46, 12 December 2007 (UTC)[reply]

Yep, they're all there. Fathoms had been missing from the list. J ɪ m p 20:23, 12 December 2007 (UTC)[reply]

Converting feet and inches into meters?

I love the template! I was never really willing to get into using conversion templates before, because there were a million of them and I could never remember their names. I was wondering if it would be possible to add support for converting a length specified in both feet and inches into a single value in meters. I run into this a lot in articles about ships. It feels inauthentic to me to convert the feet+inches to decimal feet, and there's a loss of precision as well. However, I don't know how input would work. Maybe a {{Convert/ftin}} that takes an additional input? TomTheHand (talk) 15:54, 12 December 2007 (UTC)[reply]

Until that's implemented in {{convert}}, you can use {{ft in to m}} and {{m to ft in}} (watch their pre-expand size, though). Once {{convert}} is upgraded (and I trust that it can be), it is trivial to replace all instances of {{ft in to m}} and {{m to ft in}} with {{Convert/ftin}} (or whatever it will be called) with a bot. Meanwhile, you'll be able to save a few keystrokes :)—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:36, 12 December 2007 (UTC)[reply]

Thanks! I'm comfortable with converting meters to decimal feet, so I will probably use {{convert}} for that instead of {{m to ft in}}. I'll start using {{ft in to m}}, as I'm tired of the ol' manual Google conversion route. TomTheHand (talk) 18:40, 12 December 2007 (UTC)[reply]

I just want to add that {{m to ft in}} also supports feet plus decimal inches (as opposed to just decimal feet of {{convert}} or {{m to ft}}), should you ever need that capability. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:47, 12 December 2007 (UTC)[reply]

←outdent←
I had been pondering on how to do this for quite some time. I don't want to add a whole bunch of code to the template just so it can handle stuff like this (there's pounds & ounces, stone & pounds and others maybe as well). One idea I came up with would be to enter, e.g. "{{convert|6*12+3|ft & in}}" for six foot three, but that seems strange & inconvenient. Perhaps, a {{Convert2}} or {{ConvertDual}} would be the way to go. J ɪ m p 20:34, 12 December 2007 (UTC) ... Okay, I think I've figured out a way to do it without too much extra code. I'll need an admin to edit the main page though because it's protected at the moment. The new code would look like this (i.e. two more unnnamed parameters—18 bytes).[reply]

<includeonly>{{convert/{{{2}}}|{{{1}}}|{{#ifeq:{{#expr:{{{3|0}}}*0}}|0|0}}
|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|r={{#ifeq:{{{sp}}}|us|er|re}}
|d=L{{{lk|off}}}A{{{abbr|off}}}D{{{disp|b}}}S{{{adj|{{{sing|off}}}}}}|s={{{sigfig|}}}}}</includeonly>
<noinclude>
{{pp-template|small=yes}}{{esoteric}}
{{template doc}}
<!-- Add cats and interwikis to the /doc subpage, not here! -->
</noinclude>

J ɪ m p 23:27, 12 December 2007 (UTC)[reply]

Done (hopefully correctly!). TomTheHand (talk) 23:34, 12 December 2007 (UTC)[reply]

That was quick. Thanks, though I was about to say (edit conflict) please use the following instead because the above is formatted to fit onto the page nicely.

<includeonly>{{convert/{{{2}}}|{{{1}}}|{{#ifeq:{{#expr:{{{3|0}}}*0}}|0|0}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|r={{#ifeq:{{{sp}}}|us|er|re}}|d=L{{{lk|off}}}A{{{abbr|off}}}D{{{disp|b}}}S{{{adj|{{{sing|off}}}}}}|s={{{sigfig|}}}}}</includeonly><noinclude>{{pp-template|small=yes}}{{esoteric}}
{{template doc}}</noinclude>

Note I was also thinking we should ~~move {{pp-template|small=yes}} & {{esoteric}} to the doc page and~~ get rid of  since the template is protected and being monitored by editors who know where cats and interwikis go. This way we'll actually reduce the pre-expand size. J ɪ m p 23:54, 12 December 2007 (UTC)[reply]

I've copied in your updated code. TomTheHand (talk) 01:09, 13 December 2007 (UTC)[reply]

←outdent←
Thanks, okay it's up & running. Here are some examples.

A list & table in which inputs & outputs didn't match dated 6:06 am (UTC), 13 December 2007 has been removed at 7:30 pm (UTC), 27 December 2007 (made necessary due to a change in {{convert/sandbox}}). Gene's reply below refers to these. A number of the problems he noted had been caused by the mismatch. See the corrected version below.

I realize that this is only in one direction for now, in these examples. However, even with that limitation, there are several problems (including the results I see in square brackets so not so confusing if template is changed, but not bothering with links):

Lousy default choice of units converted to in 1 [6 feet 2 inches (188 cm)]
Requested "to" units ignored in 4 [16 feet 10 inches (5.13080 m)]
- The precision is wacky too
Precision also bad in 11 [6-foot-1.1-inch (185.67400 cm)]
Lousy default choice in 2 [78 pounds 11 ounces (35,692.04946 g)]
- Without explicit "to" units, precision specifications are likely to be input wrong, and specified precision of results in already existing inclusions would be disrupted if the default "to" units are changed
The conversion in 9 [4 stone 9 pounds (29.48350 kg)] only gives results converted to a single unit, the conversion in 10 [69-stone-11-pound (980 lb/440 kg)] defaults to two output conversions
- Nothing is the formatting of the template would give an editor adding the template any clue that this is going to happen.
The default precision in 10 [69-stone-11-pound (980 lb/440 kg)] is not good, giving us instead the equivalent of 70 stone 0 pounds in the "lb" figure.
The ever-continuing and improper bias against U.S. spellings, by requiring an explicit addition of a parameter to get them. Widespread use of this template will give undue preference.

That should do for starters. Gene Nygaard (talk) 14:45, 13 December 2007 (UTC)[reply]

I'm an American, but I believe that if the template is asked to convert to SI, it should really convert to SI, with the spellings specified by that international standard and all. I have no problem with such spellings being the default. TomTheHand (talk) 15:03, 13 December 2007 (UTC)[reply]

The international standards specify the symbols, not the spellings. Gene Nygaard (talk) 15:29, 13 December 2007 (UTC)[reply]

Ah, I see. Sorry. I understand your point now. I am still leaning toward being ok with the current setup. The template has to default to something, and I feel that metric conversions are generally provided to help people who are more familiar with metric units than English/Imperial; such people are more likely to prefer the "metre" spelling. TomTheHand (talk) 15:41, 13 December 2007 (UTC)[reply]

Default units easily can be changed. How about ft & in → m (instead of cm) and lb & oz → kg (instead of g)?
I'll look into the screwy precisions.
I didn't choose the default spelling. I went with what had already been in place. However, one spelling has got to be the default so there'll be undue preference one way or the other. "ever-continuing" ... as opposed to ... constantly changing ... "improper" ... so, are you suggesting a bias against Commonwealth spellings would be proper? Neither is any more "proper" than the other.

J ɪ m p 17:52, 13 December 2007 (UTC)[reply]

I think I've found what was causing the problems (or most ... or some of them). The inputs & outputs in the above list and table don't all match. Here's the

Corrected version

1	`{{convert\|6\|ft\|2\|in}}`	gives	6 feet 2 inches (1.88 m)
2	`{{convert\|78\|lb\|11\|oz\|5}}`	gives	78 pounds 11 ounces (35.69205 kg)
3	`{{convert\|6\|ft\|1.134\|in\|mm}}`	gives	6 feet 1.134 inches (1,857.60 mm)
4	`{{convert\|16\|ft\|10\|in\|dm\|-1}}`	gives	16 feet 10 inches (50 dm)
5	`{{convert\|6\|ft\|7\|in\|sing=on}}`	gives	6-foot-7-inch (2.01 m)
6	`{{convert\|6\|lb\|4\|oz\|abbr=on}}`	gives	6 lb 4 oz (2.8 kg)
7	`{{convert\|5\|foot\|4\|in\|lk=on}}`	gives	5 foot 4 inches (1.63 m)
8	`{{convert\|6\|foot\|1\|in\|1\|lk=on}}`	gives	6 foot 1 inch (1.9 m)
9	`{{convert\|4\|st\|9\|lb\|kg\|lk=on\|sigfig=7}}`	gives	4 stone 9 pounds (29.48350 kg)
10	`{{convert\|69\|st\|11\|lb\|adj=on\|lk=on}}`	gives	69-stone-11-pound (443 kg; 977 lb)
11	`{{convert\|23\|ft\|0\|in\|0\|adj=on\|lk=in}}`	gives	23-foot-0-inch (7 m)
12	`{{convert\|65\|ft\|10\|in\|mm\|sing=on\|lk=out}}`	gives	65-foot-10-inch (20,070 mm)
13	`{{convert\|12\|ft\|1\|in\|mm\|9\|adj=on\|lk=out}}`	gives	12-foot-1-inch (3,683.000000000 mm)
14	`{{convert\|13\|ft\|11\|in\|abbr=on\|lk=out\|disp=s}}`	gives	13 ft 11 in (4.24 m)^*
15	`{{convert\|6\|ft\|1\|in\|7\|abbr=on\|lk=in\|disp=s}}`	gives	6 ft 1 in (1.8542000 m)^*
16	`{{convert\|6\|ft\|1.1\|in\|m\|abbr=on\|lk=on\|sigfig=3\|disp=s}}`	gives	6 ft 1.1 in (1.86 m)^*

Table versions
	code	Imperial/US	conversion
T1	`{{convert\|23\|lb\|5\|oz\|kg\|3\|disp=table}}`	23 5	10.574
T2	`{{convert\|15\|ft\|4\|in\|abbr=on\|disp=table}}`	15 feet 4 inches	4.67 m
T3	`{{convert\|8\|ft\|11\|in\|4\|lk=on\|disp=table}}`	8 feet 11 inches	2.7178 m
T4	`{{convert\|76\|lb\|11\|oz\|kg\|lk=in\|disp=table}}`	76 pounds 11 ounces	34.8 kg
T5	`{{convert\|6\|ft\|5\|in\|cm\|lk=out\|disp=table}}`	6 feet 5 inches	196 cm

J ɪ m p 18:20, 13 December 2007 (UTC)[reply]

I've changed the defaults to m & kg and found and fixed the default precision problem (the one which was causing the st & lb to lb conversion to round up incorrectly). J ɪ m p 18:40, 13 December 2007 (UTC)[reply]

Much better on those points. There is, however, a considerably more subtle default precision problem in the new number 12. Gene Nygaard (talk) 01:03, 14 December 2007 (UTC)[reply]

You can see that subtler problem here too:

17	`{{convert\|25\|lb\|9\|oz\|kg}}`	gives	25 pounds 9 ounces (11.6 kg)
18	`{{convert\|25\|lb\|10\|oz\|kg}}`	gives	25 pounds 10 ounces (11.6 kg)	now but was giving 25 pounds 10 ounces (12 kg)
19	`{{convert\|25\|lb\|11\|oz\|kg}}`	gives	25 pounds 11 ounces (11.7 kg)

Gene Nygaard (talk) 01:37, 14 December 2007 (UTC)[reply]

Yes, quite subtle but a serious problem nonetheless. I'll see how I can fix it. J ɪ m p 02:42, 14 December 2007 (UTC)[reply]

Okay, it's fixed. P.S. For those wondering what we've been talking about: the template was not recognising the zero in the 10 as being a significant figure and was thus rounding up to a higher order of magnitude than it should have been (i.e. 25 lb 10 oz to 12 kg rather than 11.6 kg & 65 ft 10 in to 20,000 mm rather than 20,100 mm). Thanks, Gene, for pointing that (& the other problems) out. J ɪ m p 03:04, 14 December 2007 (UTC)[reply]

I hadn't noticed the first time through, but it also applies here

20	`{{convert\|343\|ft\|11\|in\|m}}`	gives	343 feet 11 inches (104.83 m)
21	`{{convert\|344\|ft\|0\|in\|m}}`	gives	344 feet 0 inches (104.85 m)
22	`{{convert\|344\|ft\|m}}`	gives	344 feet (105 m)
23	`{{convert\|344\|ft\|1\|in\|m}}`	gives	344 feet 1 inch (104.88 m)
24	`{{convert\|27\|lb\|15\|oz\|kg}}`	gives	27 pounds 15 ounces (12.7 kg)
25	`{{convert\|28\|lb\|0\|oz\|kg}}`	gives	28 pounds 0 ounces (12.7 kg)
26	`{{convert\|28\|lb\|1\|oz\|kg}}`	gives	28 pounds 1 ounce (12.7 kg)

Note that 21 differs from 22 (without any inches involved) too, which might be a separate problem? I double-checked and think I have the template right on both sides. Gene Nygaard (talk) 05:32, 14 December 2007 (UTC)[reply]

Fixed. Yeah, 21's differing from 22 is a seperate issue. Is it a problem? The input in 21 is precise to the nearest inch. That of 22 is precise to the nearest foot. Differing input precisions are what are leading to the differing output precisions. This was intentional. Compare 27.

27 {{convert|344.0|ft|m}} gives 344.0 feet (104.9 m)

J ɪ m p 05:21, 15 December 2007 (UTC)[reply]

The problem was that it was even less precise than the one just to the feet precision, giving 100 m rather than 105 m. That's why I wondered if there might be a second problem as well. It was also less precise than a conversion based on 10-inch precision in the original (and it seemed like that was the precision we were getting with the x ft 10 in examples); 344×12 = 4128, and

28 {{convert|4130|in|m}} gives 4,130 inches (105 m)

which gives the three digit precision I thought would have been more likely for the 0 inches result too. If you only fixed one problem, then there probably wasn't a second problem. Gene Nygaard (talk) 19:31, 15 December 2007 (UTC)[reply]

Okay, I see what you were getting at. Yeah, the problem ... problems were with the zero. Whereas the 10 was giving a ("correct" but mistaken) precision of -1, the 0 was just giving nonsense. J ɪ m p 17:36, 16 December 2007 (UTC)[reply]