Template talk:Convert/Archive May 2010

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Idea: Table Auto-conversion possible?

Hi. Is there currently a way to configure a table to convert a whole column of data? Has someone already done this? Is this a good/workable idea?

I'm looking at the table here and thinking that it would be more useful and look better if 2nd and 3rd columns (Annual yield (Liters/hectare) and Annual yield (US gal/acre)) were combined, either

by knowing the viewer's locale and displaying one or the other, accordingly, or
having a button that used javascript to display one or the other, or
Deleting the 3rd column (the low-tech solution) (and perhaps using {{convert}} but that might look worse than the current table).

Commons has templates like {{int:license}} that work based on the user's locale.

I guess this could be done with JavaScript Array Object but I'm no JS wiz.

NOTE: We already have tables sortable via client-side JavaScript: Help:Sorting --Elvey (talk) 18:58, 28 April 2010 (UTC)

I followed the third idea, and combined column 3 into column 2 for "Ethanol_fuel", showing the unit symbols after the various numbers. When a table has a column of text paragraphs, then the best option is to reduce the other columns, so the text column can be wider. In this case, combining colums 2&3 reduced the table length 45%, by allowing more space for the column of text paragraphs. If live conversions are needed, the display option "disp=output only" could be used to show the gal/acre numbers, after the footnotes of the L/ha numbers. -Wikid77 (talk) 21:05, 8 May 2010 (UTC)

Implement this template on another wiki

I was importing some information to Wikipedia from Gardenology wiki which uses Creative Commons, and saw that some of the pages there have this Convert template called, but the template is not on the site. It looks pretty complicated. Could anyone help put this template onto that site? --Weedgarden (talk) 18:39, 12 May 2010 (UTC)

Conversion bug

29+1⁄2 by 23+1⁄2 inches (749 by 597 mm) does not work properly. Cf. 29.5 by 23.5 inches (749 by 597 mm), see broadsheet & talk:broadsheet#Conversion bug. Peter Horn User talk 21:36, 19 May 2010 (UTC)

Yes, fractions are a bit problematic. Note that 291⁄2 inches (749 mm) by 231⁄2 inches (597 mm) does work, which should help isolate the problem a bit. Plastikspork _―Œ^(talk)

Okay, Wikid77 helped me fix this one. Thanks for reporting the bug. Plastikspork _―Œ^(talk) 00:42, 24 May 2010 (UTC)

Two more bugs in Tabloid#Other countries: 141⁄2 in (368 mm)^* and 101⁄4 in (260 mm)^* Peter Horn User talk 19:48, 24 May 2010 (UTC)

Okay, I fixed half of it. I will work on the rest. Hopefully, I didn't break anything new. Thanks! Plastikspork _―Œ^(talk) 05:26, 25 May 2010 (UTC)

I believe this is now fixed. Thanks! Plastikspork _―Œ^(talk) 05:35, 25 May 2010 (UTC)

Can't figure out what's causing this bug

In this section (Nevado_del_Ruiz#Glaciers), one of the calls to {{convert}} returns an error. I can not figure out what the problem is...can someone with a little more know-how shed some light on this? Thanks -RunningOnBrains^(talk) 06:56, 25 May 2010 (UTC)

That was a new bug introduced in a recent fix. I have reverted the fix for now, and will try to figure out what went wrong. As a general note, if anyone notices bugs in display ranges, which include formatting of numbers with commas, this could be a new bug (see Wikid77's talk page). We have been trying to debug fractions in number ranges, and some new bugs in number ranges may have been introduced. Plastikspork _―Œ^(talk) 07:22, 25 May 2010 (UTC)

Okay, I believe I figured it out, it appears as though this edit, which adds reverse number formatting around the fraction check, fixes the problem. Plastikspork _―Œ^(talk) 07:42, 25 May 2010 (UTC)

More fraction converts

7.56 in ≈ 7 9/16, so 4 ft 79⁄16 in (1,411 mm), nevertheless the conversion is made!!! Peter Horn User talk 02:09, 27 May 2010 (UTC)

Okay, it looks like 559⁄16 inches (1,411 mm) works. The code that generates this message is in {{Convert/and/fra1}}, which is used to make fractions with special characters. However, there is no 9/16 character. One solution would be to call {{Convert/numdisp/frac1}} in these cases, but that would take some time for me to implement and debug, and I am leaving on travel for a week. Someone else can have a look? Plastikspork _―Œ^(talk) 03:38, 27 May 2010 (UTC)

The Convert subtemplates for ft&in do use different formatting for fractions, invoking {{Convert/and/fra1}}, which displays fractions as unicode characters (rather than 2 numerals separated by "/"). It can handle 1/8, 3/8, 5/8 but not 9/16 (because it doesn't know a character code for 9/16), and that's why the message "Sorry":

{{convert|4|ft|7+9/16|in|mm|0|abbr=on}} → 4 ft 79⁄16 in (1,411 mm)

{{convert|4|ft|7.56|in|mm|0|abbr=on}} → 4 ft 7.56 in (1,411 mm)

{{convert|4|ft|7+5/8|in|mm|0|abbr=on}} → 4 ft 75⁄8 in (1,413 mm)

As always, when format limitations occur, try using "disp=output only" and hardcode the inputs, using whatever fraction characters, font or font color, as needed:

{{convert|4|ft|7+9/16|in|mm|0|abbr=on|disp=output only}} → 1,411 mm

I am working on a new fraction-display routine which could handle 9/16, rather than generate an error message, for that number. -Wikid77 (talk) 10:34, 29 May 2010 (UTC)

Showing the output only is not really the answer. Ref: Template talk:RailGauge#And yet more oddball rail gauges Standard gauge#Origins Peter Horn User talk 13:09, 31 May 2010 (UTC)