Template talk:Convert/Archive February 2011

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Physical dimensions (e.g. A x B x C mm)

This template does not seem to currently support converting physical dimensions (e.g. "8.0 × 5.3 × 0.8 in (203 × 135 × 20.3 mm)"). Is it feasible to add this functionality to the template? --Oldak Quill 12:20, 20 January 2011 (UTC)

It could be done. JIMp talk·cont 00:39, 23 January 2011 (UTC)
However be careful, If you mean that all three numbers are measured in mm, it should be 203 × 135 × 20.3 mm3. −Woodstone (talk) 16:44, 23 January 2011 (UTC)
  • DONE, as {convert/3|...}. That is an undocumented feature (sorry), implemented on 6 November 2009, allowing mixed separator words, and people have forgotten:
• {{convert/3|8.0|x|5.3|x|0.8|in|mm|abbr=on}}  → {{convert/3|8.0|x|5.3|x|0.8|in|mm|abbr=on}}
• {{convert/3|8.0|x|5.3001|x|4|in|mm|abbr=on}}  → {{convert/3|8.0|x|5.3001|x|4|in|mm|abbr=on}}
• {{convert/3|10|-|20|+/-|0.5|m|ft|abbr=on}} → {{convert/3|10|-|20|+/-|0.5|m|ft|abbr=on}}
• {{convert/3|10|-|19|never|20|m|ft|abbr=on}} → {{convert/3|10|-|19|never|20|m|ft|abbr=on}}
• {{convert/3|1|to|9|rarely|10|m|ft|abbr=on}} → {{convert/3|1|to|9|rarely|10|m|ft|abbr=on}}
• The road was lengthened as {{convert/3|5|-|7|-|12|km|mi|abbr=on}}.
 → The road was lengthened as {{convert/3|5|-|7|-|12|km|mi|abbr=on}}.
• {{convert/3|8|x|5.30|by|4|m|ft|adj=mid|high}} → {{convert/3|8|x|5.30|by|4|m|ft|adj=mid|high|abbr=on}}
The range-words (to, -, and, or, by, +/-) can be mixed, but the 2nd "word" can be any phrase. The mid-text with adj=mid does not work yet (the template was edit-protected on 02Jan11, freezing further changes). The precision of each amount is mirrored in the output amounts. If suffix "/3" is omitted from "convert/3" it will say "Template loop detected". -Wikid77 21:11, 2 February 2011 (UTC)

translating input and output to another language

Hi, how can i use this template in another language wiki? i want to have input for example (meter==>متر) or to have output (ft==>فوت).i used dictionary file for translating input to English but i don't know how can i translate unites output in REVERSE translation! in another hand my language is right to left so if i use some English alphabets with my language inside {{}} it will be disorganized and changes the unites places! so i have to write all of them in one language. Reza1615 (talk) 01:24, 25 January 2011 (UTC)reza1615

  • I am working on Convert in the Arabic Wikipedia, so look there for some examples, in reverse order. -Wikid77 21:53, 2 February 2011 (UTC)

Convert in Arabic Wikipedia

02-Feb-2011: I have been distracted this past week, but I am extending the version of Convert in Arabic Wikipedia, where the results are reversed, right-to-left: (mi 100) km 161. So far, only 475 Arabic articles have been using Convert, probably from translations, which only recently began supporting ranges. Anyone is welcome to work there, but a username must be created (can use Latin alphabet) to edit templates. Of course, unit names are often spelled as Arabic words. The major change, in terms of keeping similar to English Wikipedia, seems to be to force the reversal of the parentheses, using unicode hex-codes of the form "‮(‬" as: ‮(‬ with ‮)‬, in order to avoid auto-reversing the order of 2 numbers, after a parenthesis, in a range. During editing, the semi-reversed template markup might be almost unreadable on Arabic screens, so use an external text-editor and copy back into the template edit-buffer to edit-preview the results. -Wikid77 21:53, 2 February 2011 (UTC)

Group separation in metric values

Perhaps there is something already available in the convert syntax that has escaped my notice but I cannot see a way to force the use of a space as the separator between groups of three digits. This is a specification of the SI Brochure. For example, a mass should be shown as 8 430 kg, not 8,430 kg. Is it already possible to force this? If so, could it be done as the default condition for outputting metric values? If not, can it be added? Metricator (talk) 18:22, 22 January 2011 (UTC)

It wouldn't be easy but it would be possible. It would be best as a function you could turn on with a parameter rather than the default for this or that type of unit (which would be even harder to implement) for the sake of consistency. I have a preference for the commaless style but not depending on the unit. The one style should be used throughout the article. If you're using the space rather than the comma for the metric units, use it for the non-metric ones (along with other numbers). Also if this is done, we should use something along the lines of {{gaps}} or even that template. JIMp talk·cont 00:39, 23 January 2011 (UTC)

Two lines?

Forgive me if I'm being ignorant, but is there a way to make the template display on two lines, instead of one? For example:

100 miles
(161 km)

Thanks, LittleMountain5 03:24, 26 January 2011 (UTC)

  • The option disp=x can be used to customize the output, and insert a "<br>" line-break, as {{convert|100|mi|km|disp=x|<br>(|)}}, giving the result:
  • 100 miles
    (160 km)
That option also works in range conversions.-Wikid77 21:53, 2 February 2011 (UTC)
Awesome, thanks! LittleMountain5 23:48, 2 February 2011 (UTC)
One problem, though... it gives me a long nasty error when I try to round the answer: {{convert|100|mi|km|-1|disp=x|<br>(|)}}
Any way around that? LittleMountain5 23:59, 2 February 2011 (UTC)
  • When using disp=x, put the rounding parameter "|-1" at the end, so {{convert|100|mi|km|disp=x|<br/>(|)|-1}} gives: 100 miles<br/>(160 km). -Wikid77 21:43, 3 February 2011 (UTC)

Case sensitivity

To what extent is {{convert}} case sensitive? Happy‑melon 11:13, 30 January 2011 (UTC)

  • Very case-sensitive, because the unit-codes are suffixes of subtemplate names, where {Convert/M} would be a different template than {Convert/m}. -Wikid77 21:53, 2 February 2011 (UTC)
Interesting... :D Happy‑melon 23:49, 2 February 2011 (UTC)
Were it not so there'd be problems, e.g. with milli- vs mega-, pico- vs peta, etc. JIMp talk·cont 00:47, 3 February 2011 (UTC)
Why did you then need to use "kn" for knot instead of "kt", if kilotesla would be "kT"?? Happy‑melon 09:28, 3 February 2011 (UTC)
What about kilotonne? JIMp talk·cont 09:40, 3 February 2011 (UTC)
An excellent question... :D Happy‑melon 14:17, 3 February 2011 (UTC)

Convert/4 for 4 amounts 1x2x3x4

03-Feb-2011: I have extended the 3-amount converter, Template:Convert/3 to become a 4-amount converter, as {convert/4} with full options (except disp=flip). It also allows any separator words or commas (you invent the words, it shows them):

  • {{convert/4 |1|x|2|x|3|x|4|ft|m}} → {{convert/4 |1|x|2|x|3|x|4|ft|m}}
  • {{convert/4 |10|x|20|rather than|15|x|25|in|cm}} → {{convert/4| 10|x|20|rather than|15|x|25|in|cm}}
  • {{convert/4 |12|-|19|, in summer|20|-|27|C|F}} → {{convert/4|12|-|19|, in summer|20|-|27|C|F}}
  • Katrina's storm tide rose 4 times: {{convert/4| 2|-|6|-|9|and finally|10|m|ft}}. → {{convert/4| 2|-|6|-|9|and finally|10|m|ft}}.

This is another case of using a complex wrapper template, which invokes Convert several times, as if an article editor wrote 4 conversions into an article, but easier for them, as just using {convert/4|...}. It allows more options than {convert/3}, which was edit-protected in January 2011, before it could be updated for adj=mid or disp=x, options which {convert/4} already supports. The precision of each amount is mirrored in the output amounts. If suffix "/4" is omitted from "convert/4" it will say "Template loop detected". -Wikid77 21:43, 3 February 2011 (UTC)

Convert/gaps to put gaps in numbers

03-Feb-2011: I have created another wrapper, Template:Convert/gaps, which displays numbers using small gaps between each 3-digit group, with 3 or 4 digits gapped in the decimal portion. The use of space-gaps in numbers (rather than commas) might be better in some other-language Wikipedia cultures, or when quoting documents which avoid commas. Examples:

  • {{convert/gaps|45100|km|mi}} → {{convert/gaps|45100|km|mi}}
  • {{convert/gaps|5100.10065|m|ft}} → {{convert/gaps|5100.10065|m|ft}}
  • {{convert/gaps|6000700.400955|km|mi}} → {{convert/gaps|6000700.400955|km|mi}}

Generally, for English Wikipedia, commas are preferred, to avoid the illusion of multiple 3-digit numbers in a row: {{gapnum|9300500700.12300044}} versus 9,300,500,700.12300044. The gaps are not spaces, so copy/paste of a gapped-number treats the number as connected digits, as one continuous number. The size limit is 999 trillion (with 12 zeroes), or 14 decimal places. The precision of each amount is mirrored in the output amounts.
{Convert/gaps}, currently, can handle any 1-number conversion, but could be changed to support more, such as miles-and-chains. However, other conversions are very rare, so 1-amount might be enough. Inside, {Convert/gaps} uses new Template:gapnum, which I wrote to be very efficient (expansion depth 10, or 5 with prec=n), and we can adjust {gapnum} to handle any computer-math precision problems (already 0.10055 had trouble). So, it is very fast, and don't be afraid to use {Convert/gaps} in articles where consensus favors the gaps. It supports all major options except disp=flip. More later. -Wikid77 21:43, 3 February 2011 (UTC)

Plan to fix precision of negative numbers

04-Feb-2011: I am finishing Template:Getprecision, as almost ready to use to fix the long-running precision problem in negative numbers:

  • Convert 65,000 & -65,000: 65,000 miles (105,000 km) & −65,000 miles (−105,000 km)
  • Convert 75,000 & -75,000: 75,000 miles (121,000 km) & −75,000 miles (−121,000 km)

The problem comes from using the complex, nested Template:Precision (written elsewhere, with several bugs), so the fix will replace {Precision} with {Getprecision} when ready:

  • {Precision| -65000} → -3 (should be -3 instead)

Until fixed, just hard-code the rounding amount as "-3" for such negative numbers. This is just a notice that the problem is nearly corrected. -Wikid77 12:54, 4 February 2011 (UTC)

Precision

Is it possible for someone to describe the algorithm used, or the algorithm you would like to be used, to establish the precision of the output value? Happy‑melon 14:08, 4 February 2011 (UTC)

The algorithm used is described at Template:Convert/doc#Rounding. The algorithm I'd like to use is the same but increasing 0.02, 0.2, 2, 20, ... to 0.01√10, 0.1√10, √10, 10√10, ... respectively, and throwing away everything from “or to two significant digits” onwards (including the absurd exception for temperatures). Also, I'd drop the assumption that all of the zeros in inputs such as 10000 should be regarded as non-significant. --A. di M. (talk) 00:41, 7 February 2011 (UTC)
Maybe with an exception that if the input is 1, 0.1, 0.01 etc. it is treated as if it were 1.0, 0.10, 0.010 etc. to avoid silly things such as 1 pound (0 kg). --A. di M. (talk) 00:56, 7 February 2011 (UTC)

Reversing output order

Hi. I'm trying to use the template to convert 50,513 long tons into tonnes, but with the output order reversed. However, when I add the parameter to reverse the order, I get: 51,324 tonnes (50,513 long tons). Any ideas? Cordless Larry (talk) 09:44, 8 February 2011 (UTC)

I'm afraid I can't help with the problem itself, but can I take the opportunity to ask what circumstance you're using the reversed-output option? I don't really understand why and where it would be useful, and seek enlightenment :T Happy‑melon 09:50, 8 February 2011 (UTC)
I'm trying to sort out the measurements at Forth Bridge, as discussed here. We have a source for the weight in tons but want the article to use metric weights and measures first. Cordless Larry (talk) 09:53, 8 February 2011 (UTC)
Did you guys try to find a source for the same weight in metric tonnes? That would solve the problem altogether. (If there's no such source, it might be that tonnes aren't really the most appropriate units for that article after all.) --A. di M. (talk) 11:54, 8 February 2011 (UTC)
There are sources that give the weight in tonnes, but the weight given varies. The source we're currently using would seem to be the most reliable because it's the visitor centre of the bridge. I don't see why we shouldn't give the weight in tonnes - all other measurements in the article are given in metric. Cordless Larry (talk) 19:17, 8 February 2011 (UTC)
  • DONE, try again. -Wikid77 19:43, 8 February 2011 (UTC)
Great, I can tell that it's worked from the conversion I posted above, which is now displaying correctly. Many thanks! Cordless Larry (talk) 20:14, 8 February 2011 (UTC)

lb -> N conversion problem

this will show something like "1 lb = 0.45 N". this is a mistake that's very easy to make, and it's silently showing wrong results, which can lead to corruption of information. is it possible to make this and similar invalid cases fail noisily, with an error message in the output? i've mentioned this problem earlier, and it gathered some responses but then it got expired/removed without resolution.Bewareircd (talk) 12:58, 8 February 2011 (UTC)

"disp=output number only" does not work for all conversions

Try the following: {{convert|10|mpgus|L/100 km|disp=output only}}, then try {{convert|10|mpgus|L/100 km|disp=output number only}}. The former works, the latter does not. I'm not sure yet how many other kinds of conversions the "output number only" option can't handle. Perhaps it could be looked at?

  • Thanks for reporting that. I have implemented new "disp=number" as shorter than "disp=output number only":
• {{convert|10|mpg|L/100 km|disp=output only}} → [convert: ambiguous unit]
• {{convert|10|mpg|L/100 km|disp=number}} → [convert: ambiguous unit]
The fix is in Template:Convert/NumoutF. -Wikid77 21:53, 2 February, revised 13:40, 9 February 2011 (UTC)

Missing non-breaking spaces

There appears to be an absence of a non-breaking space in the converted value between the converted value and unit. If the unit is linked then the non-breaking space is missing between the initial value and its unit - but present in the converted value. Tested with {[convert|22|mi|km}} and {{convert|22|mi|km|lk=on}} Keith D (talk) 00:43, 4 February 2011 (UTC)

  • Thank you for the reminder about &nbsp. It must be annoying to use "lk=on" and have the text-wrapping change. The bad news is that the wrapping-style differs, not just with lk=on, but in over 3,000 various option settings. The worse news: those 3,000 subtemplates are just the start of 24,000 subtemplates needed to handle all combinations of options. Even worse still, when we try to extend options, and re-edit some new subtemplates to all give more-consistent results, some admin comes along and edit-locks the new pages before they match in style. So Convert is part of the WIKI-NO-EDITA, where we have to fight Wikipedia's ageing bureaucracy to submit the proper forms to get partial access to make partial improvements to partial Convert sections (which I'm not partial to!). It is a TOTAL NIGHTMARE. Hence, we have "WP:A plan to reduce Convert subtemplates" to avoid needing those 24,000 different pages, and write condensed templates which apply the same style to all variations of the options.
    Meanwhile, we have one option left, abbr=mos, which seems to work consistently to apply &nbsp (for lk=on). So, try:
  • {{convert|22|mi|km|abbr=mos|lk=off}} → 22 miles (35 km)*
  • {{convert|22|mi|km|abbr=mos|lk=on}} → 22 miles (35 km)*
The wrapping style for lk=off or lk=on is the same there. I will try to submit the proper forms to request changing basic options to match that style. -Wikid77 12:54, 4 February 2011 (UTC)
Thanks for that, what a pain, I will have to change them when I come across them. Keith D (talk) 16:00, 4 February 2011 (UTC)

Separators

Having full-width spaces as separators is really ugly and untypographical. Now Unicode is becoming widespread, should we not start using the typographically correct, and elegant, thin non-break space, Ux202F?

— Leandro GFC Dutra (talk) 00:14, 7 February 2011 (UTC)

  • Use "disp=number" to set all formatting of results, such as: 12&nbsp;km&nbsp;~= {{convert|12|km|mi|disp=number}} → 12 km ~= 7.5 miles. -Wikid77 19:43, 8 February, revised 13:40, 9 February 2011 (UTC)

Currency per unit weight conversions

Is there a smooth way to convert a currency amount per unit weight, say US$700 per pound, to US$ per kilogram? I can see how to get US$700 and 1 pound (0.45 kg), but cannot figure how to do the numerical change in the numerator when the unit that changes is in the denominator using the Wiki template tools. Of course, I could just do it manually... Cheers. N2e (talk) 18:19, 8 February 2011 (UTC)

  • No smooth way, but thanks for noting those units are missing. For now, use the "#expr:" parser function to run the calculation, in the general format: US$700 per pound (US${{#expr: 700 / {{convert|1|lb|kg |disp=output number only}} round 2}} per kg)
    which gives:   US$700 per pound (US$1555.56 per kg)

    For troy ounces, just use factor 12 because the troy pound is not yet supported by Convert (we need {{convert|1|lbt|ozt}}→1 troy pound (12 ozt)): US$700 per pound (US${{#expr: 700 * 12}} per ounce), which gives: US$700 per pound (US$8400 per ounce). That will allow customization of the results. -Wikid77 19:43, 8 February 2011 (UTC)
There is a way ... or will be soon ... but I can't seem to edit. JIMp talk·cont 20:01, 8 February 2011 (UTC)
It's working {{convert|700|$/lb}} → "$700 per pound ($1,500/kg)" JIMp talk·cont 20:13, 8 February 2011 (UTC)
  • Great, and there's no restriction as to which nation's dollar is used, so in Hong Kong articles: "The gold market in Wan Chai set the price of gold as [[Hong Kong Dollar|HK]]{{convert|121,500|$/lb}}" → HK$121,500 per pound ($268,000/kg). Use similar wikilinks for the Canadian dollar, etc. -Wikid77 01:33, 9 February 2011 (UTC)
Thanks for the responsive help. Great stuff. Thanks very much folks for working on tools like this! I'll give them a try right away in the Astrobotic Technology article where I need the function for a quoted price where someone is offering to take private payloads to the moon, at a VERY HIGH cost per lb/kg. N2e (talk) 15:08, 9 February 2011 (UTC)
DONE! "... priced payload carried to the lunar surface at $700,000 per pound ($1,500,000/kg)" is now in the article. I assume you folks will add some new info to the {{convert}} template page to describe this in the future. Cheers. N2e (talk) 16:21, 9 February 2011 (UTC)

Documentation suggestion

The template seems to have some default units or something but I don't see that described anywhere in the documentation....it is very confusing.

For example

{{convert|120|km/h}}

produces 120 kilometres per hour (75 mph)

Where was "mph" specified as the units to be converted to? It is not specified in the parameters.

Sincerely, North8000 (talk) 13:15, 9 February 2011 (UTC)

  • To see the default units, just try a conversion and view the output unit. The table of units, {{Convert/list_of_units}}, is currently very crowded, so not everything about each unit-code has been listed. Perhaps we should note the defaults about the most common units in the /doc page. -Wikid77 13:40, 9 February 2011 (UTC)
Even just a sentence or two that generally says that something happens when you only specify one unit would be helpful. North8000 (talk) 14:38, 9 February 2011 (UTC)

News disp=number, Convert/incompatable, minus, Getprecision

More news about Convert:

  • Doc page {{Convert/doc}} now lists {{convert/3}} & {{convert/4}} for multi-unit ranges or sets.
  • New option "disp=number" can replace "disp=output number only" to shorten the writing of custom conversions.
  • New Template:Convert/incompatable can show error for "$/lb" conversion mismatch. Perhaps should be renamed with "i" as "Convert/incompatible". Example: {{Convert/incompatable}}
  • New Template:Convert/NumoutF has been fixed to handle "disp=number" for mpg conversions, such as: {{convert|10|mpg|L/100 km|disp=number}} → [convert: ambiguous unit].
  • Option abbr=values still shows both amounts, allowing disp=s to show slash: {{convert|10|mpg|L/100 km|abbr=values|disp=s}} → 10[convert: ambiguous unit].
  • Use &minus to avoid hyphen-as-minus bug still in Convert negative numbers: {{convert|-4|km}} → −4 kilometres (−2.5 mi), but {{convert|&minus;4|km}} →   −4 kilometres (−2.5 mi).
  • Template:Getprecision has been fixed for negative hundreds (any end "0"), and allows &minus: {{getprecision |-600}} → {{getprecision|-600}}, {{getprecision |&minus;23000}} → {{getprecision|−23000}}.
  • Negative temperatures still have precision error: {{convert|300|C|F}} → 300 °C (572 °F), but{{convert|-300|C|F}} → −300 °C (−508.0 °F).

The old display option "disp=output number only" is still supported, but using shorter "disp=number" will encourage users to write their own rare, custom conversion formats in an article, rather than have specialized subtemplates for each rare case. More news later. Wikid77 13:40, 9 February 2011 (UTC)

Yesterday, {Convert} was changed to show Unicode &minus (as "−") for negative numbers, as correcting the hyphen-for-minus problem, fixed now: {{convert|-4|km}} → −4 kilometres (−2.5 mi). -Wikid77 23:05, 12 February 2011 (UTC)

Plan fix to round negatives & 7 fewer expansion levels

13-Feb-2011: The day has finally come, after months of discussions, to fix the rounding of negative numbers, with new templates which use 7 fewer levels of the 40-deep expansion depth limit (see: m:Help:Expansion limit). As explained weeks ago, the temperature conversions are already using the new Template:Getprecision to count the end-zeroes "00" in negative temperatures, such as "-300 °F". However, the plan is also to change the default rounding of all negative numbers, to count the end-zeroes. Currently, the new version can be activated by setting option "lk=test" to invoke the sandbox-version for rounding the amounts. Some examples:

  • {convert| 1500|km|lk=off}} → 1,500 kilometres (930 mi)
  • {convert|-1500|km|lk=off}} → −1,500 kilometres (−930 mi)
  • {convert|-1500|km|lk=test}} → −1,500 kilometres (−930 mi)* - NEW
  • {convert|-300|C|F|lk=off}}    → −300 °C (−508.0 °F)
  • {convert|-300|C|F|lk=test}} → −300 °C (−508.0 °F)* - NEW
  • {convert|-170|F|C|lk=off}}    → −170 °F (−112 °C)
  • {convert|-170|F|C|lk=test}} → −170 °F (−112 °C)* - NEW

Note, in the examples, how the new resulting amounts have similar precision (of end-zeroes "0") to the input amounts. Because negative measurements are rare, few users had complained about the precision of negatives.
Although the concept of using 7 fewer expansion levels (nested 21 rather than 28 deep) might seem to be an unbelievable performance improvement, it is due to multiple new algorithms in the rounding logic. The current goal has been to reduce {Convert} to use only half of the tiny 40-deep expansion depth limit of nested templates & if-else logic, so fixing the rounding of negative numbers has also allowed reducing Convert to use just 21 (of the tiny 40 total) expansion levels. In the future, if Convert is involved in an expansion-depth problem, then it can be said, "Convert is only half the problem, as using just 21 levels, when other templates are using the other 20 levels to exceed 41." I think we should try to install this fix for rounding within the next few days, because "the wolves are at the door" of several concerns about the expansion depth of Convert subtemplates. However, I don't want to seem too pushy, so we can discuss further delays to this update, if needed. -Wikid77 12:20, 13 February 2011 (UTC)

Population density

I use this template on Warren County, Indiana population density figures. When translating {{convert|23|PD/sqmi}}, the result is "23 inhabitants per square mile (8.9 /km2)". It has been suggested that there should not be a gap before "/km2". Is that right? If so, can that be fixed? Thanks! Omnedon (talk) 13:20, 4 February 2011 (UTC)

Any thoughts on this? It's a simple formatting issue but I don't have access to fix it myself. The space before "/km2" (for example) when translating population density just needs to be removed. Thanks. Omnedon (talk) 02:52, 14 February 2011 (UTC)
Or should it be (8.9 per km2)? It is unusual to have no space between numbers and units. −Woodstone (talk) 13:44, 14 February 2011 (UTC)
That would be even better. In the current format, the slash separates the number from the unit, so that the space is not needed; but using " per " seems friendlier to the reader. Omnedon (talk) 13:51, 14 February 2011 (UTC)

Moving ahead to simplify Convert

We need to continue with plans for a hybrid {Convert}, which retains the super-efficient form for some conversions, but allows other conversions to have more formatting options. The extensive size of Template:Convert's large set of subtemplates has made it a large target to be "replaced" by a new template, unless we progress into a simplified version. Throughout the history of computer software development, new software engineers (or clueless hacks) have come to an existing, complex computer system, and soon convinced people to allow a complete "rewrite of the system" from scratch (which led to numerous other problems), due to people thinking the new, naive rewrite would solve the complex, underlying problems faced by the old system.

To wit, there are plans to "replace Convert" (ya right) as mentioned in the Wikipedia:Wikipedia_Signpost/2011-01-31/Technology_report, and I quote:

"Developer Happy-Melon prepared an extension to do away with the hackish {{convert}} template (revision #81074)."

Despite the use of the clueless word "hackish" (rather than "ingeniously brilliant") as an adjective describing "{{convert}}", the whole idea of such a rewrite is an obvious indication of profound misunderstanding about the immensely vast scope covered by Convert. We might as well expect the next WP Technology report to claim Google Inc.'s search-database, stored in thousands of PC disk drives, will be replaced by a hand-held calculator next month, or some other profoundly clueless idea. Please be patient.

However, the ominous warning is clear: Unless we move forward with major plans to reduce portions of Template:Convert, people will become very confused by unrealistic promises of "Convert nirvana" where all problems will vanish if Convert could only be made into a parser function (hehe, too funny!!). I must emphasize: Do not become angered (or "enraged"?) at people who haven't the slightest concept of what Convert provides to Wikipedia, but rather try to show how improvements are in progress, and we are working to handle complaints about the large size of Convert's subtemplate pool. -Wikid77 23:05, 12 February 2011 (UTC)

This is a very disappointing position to see, and I hope that it is not a widespread one. I did not call {{convert}} "hackish", that report was not written by me and I do not endorse that phrasing. Equally I would not call it "ingeniously brilliant" by a long way; there are very few templates to which I would extend that honour. Rather, it is as I stated in my commit summary, a "behemoth", an "extremely large or powerful entity".
Quite simply, this is not a competition, or at least not a competition in which you want to participate, because if it is, I am cheating. 'I' have access to a Turing-complete interpreted language which has object abstraction, variable retention and regular expression parsing. 'You' have a markup language with some crippled string interpolation functions, dodgy maths functions and no variable retention except by limited levels of nesting. I could port the entire functionality of {{convert}} verbatim into PHP and still observe a measurable performance improvement. But why would I want to do that?
{{convert}} is not perfect, indeed in various places it is incomplete, broken or suboptimal. You yourself have noted numerous examples of these on this very page. In most cases missing or idiosyncratic functionality is impossible or difficult to provide in the environment in which the template is built, because it must use such awkward and expensive constructions to reproduce functionality which can be done in just a few lines of a proper programming language.
Essentially, if you believe that you can build a better mathematical conversion tool for parsing and interpreting units of measurement in wikitext than in PHP, you are either arrogant, stupid or stubborn. I hope that you are none of those things. Conversely, I am neither arrogant nor stupid enough to believe that I can or should duplicate each and every feature of {{convert}} in PHP. Wikitext is a text presentation language, PHP is a scripting language, the two serve very different purposes. It is not my desire nor intention to define the formatting of the "1 foo (2 bar)" output, or when it should be "1 foo to 2 bar", "1 foo or 2 bar" or even "2 bar (1 foo)". That is definitely text presentation, best handled by wikitext. But determining what "1 foo" is in units of bar, is a function which you will never be able to efficiently or completely construct in wikitext.
I still expect there to be a {{convert}} template, but I expect it to be a single template, not the tip of a city-block-sized iceberg of subtemplates. I have made a very crude start on such a wrapper template at translatewiki:Template:Convert, and will continue to work on that; I would love you to join me in development there.
There are a few more items which need to be completed in the existing phase of {{#convert:...}} development, principally the handling of SI prefixes, and finishing the list of supported units. But even before that is completed, I would be delighted to hear your constructive comments on the system and its behaviour. You are quite correct to say that when rebuilding a system, it is important to be informed of all the subtle issues that influenced the development of the old system, to ensure that the new system takes adequate account of them. What is not constructive is to push for an optimisation which improves the performance of {{convert}}, by over 3,000% in some metrics, to be ignored without good reason. You who have been running round optimising everything that doesn't get out of the way fast enough cannot defend against that argument here. You simply cannot build a "super efficient" {{convert}} core that matches even the most inefficient PHP implementation.
You're not so much throwing the baby out with the bathwater as selling the baby into slavery, and I have yet to understand why you even want to ignore the bathwater. You have done some amazing work with {{convert}} and other templates, and as a template programmer myself I can appreciate that more than many. The fact that you have taken on a challenge which simply cannot be fully solved by the tools you have available, does not diminish that. Blindly arguing that you don't need metalworking because flint spears can be made sharper and stronger than they currently are, on the other hand, does. Happy‑melon 11:57, 14 February 2011 (UTC)
  • I am not trying to stop people from writing whatever parser functions they wish to have. However, let me see if I can clarify the situation about Template:Convert for everyone else: the strategy of writing a parser function to replace part of what Convert provides, is like solving a non-existent problem by returning to a variation of the previous problem. There was a simpler template, years ago, which handled only 200 units or such. However, users have requested far more units to be supported in 2011. The day-to-day problems which users of Convert emphasize are more like: "I am working on 78 articles for the British Museum in London, and I need to convert many sizes in Sumerian cubits to both metres and French linear arpents" or "I want to round the input unit to 2 decimals while quoting a source with 5 decimals, and convert to new unit milli-webdings in 17 ship articles". No one tells us they can't view an article because it converts 6 km to miles where the page won't load. That is NOT a problem. By contrast, several chemistry articles or pharmacology editors have hit the post-expand include size limit of 2,000 kb (2,048,000 bytes) due to large navboxes and {Cite_book} or {Cite_web} templates generating 4kb per footnote to exceed the MediaWiki preprocessor size limits. Please understand, by comparison, Convert is 7,300x times smaller than that. Using {Cite_web} and large navboxes is over 7 thousand times more of a problem. All concerns about Convert being "too big" are superstition, or misunderstandings, about how Convert works. Convert can be ported, or adapted, to run in Kiswahili or Yiddish using perhaps 35 templates (total), for simple conversions of a few units. The growing family of 3,400 subtemplates has been created to support the extravagance of numerous rare units and special formats around the simple amounts being converted. However, that can be simplified by using reduced subtemplates which each pass parameters to support the options to replace groups of 300 current display-formatting subtemplates. Convert can be ported, or adapted, quite easily to support conversions for the Siriono tribe in South America, if they wish to have custom measurement units defined for use in several articles. Hence, we know, from a practical standpoint, that Convert cannot be "replaced" by a parser function. However, we need to focus our efforts, now, on what many other users want us to develop. So, we are moving ahead. -Wikid77 02:13, 15 February 2011 (UTC)
What about some hybridisation. Instead of replacing the entire template, just redo some of the internal workings as parserfunctions. Yes, any trancslusion of convert is the tip of an iceberg of subtemplates but in some ways that's good. The unit subtemplates, I think, should stay. We're always creating new units. How could we do that if they're all tucked away in a parser function?
And what about the task of replacing thousands of transclusions with the new parser function? It would have to be at least semi-manual since there may be things that the template might be doing that the parser function cannot. And then what about the confusion on the editor's end, "Do I use put a "#" in (now) or not?" JIMp talk·cont 05:04, 15 February 2011 (UTC)

[undent]

  • Need feasibility study: Well, considering the use of the proposed "#convert" syntax, then a "feasibility study" should be conducted to determine which articles, realistically, could be changed to use #convert, and how many years would that take. I was too busy thinking, "Why change Convert to a parser function" rather than "how could it be done", so I forgot to think about coordinating with other activities during those years. Assuming Convert is used just 2 million times in articles (340,000 articles averaging 6 uses per article), and updating/saving 2 verified conversions per minute, 60 minutes per hour, 24/7: gives 694 endless days of editing old conversions (2,000,000/2/60/24). However, some articles use {Convert} many times, such as 38 instances of Convert in "Apollo 8" (first manned spacecraft to orbit the Moon). So, multiple people could help, if there was a "transition plan" with a training program, to teach other users how to update the text to use #convert for each of the main 17 types of conversions and spellings (single-unit, ranges, multi-unit, multi-unit ranges, temperatures, temperature ranges, non-abbreviated, US customary, U.S. customary, etc.). Developing a user-training program would take a while to write and conduct, so plan another 4 months for that. In total, considering those other factors, the overall task still seems like it will take years for English Wikipedia. Time could be saved by changing conversions and not checking to see if they still worked (I know that sounds bad, but it is an option), perhaps with a failure rate of 1/100, or 20,000 incorrect conversions, where only a relative few would be noticed. But if any incorrect conversions were in high-profile articles, the outrage could be tremendous. So that is another reason I would not want to be associated with the blame for the high-profile cases among those 20,000 mistakes using #convert. With a feasiblity study, it is important to run a "cost/benefit analysis" to see if the whole effort is worth the risk and time expended. Writing a study is a major task, but not compared to the gargantuan task of editing most of 340,000 articles to use #convert and still give precise results. -Wikid77 14:00, 15 February 2011 (UTC)
That is not the suggested implementation plan at all. As I said explicitly above ("I still expect there to be a {{convert}} template" etc), and have also said elsewhere, there is no expectation of removing {{convert}} altogether. It should be rare to ever see {{#convert:...}} syntax in article wikitext directly. What is expected is that existing uses of {{convert}} remain, and that the template code itself is altered to appropriately use the parser function for its heavy lifting. {{#convert:10km}} doesn't produce the full "10km (10,000m)" output, it just does the grunt work of generating "10,000m"; the remainder of the functionality is presentation and formatting, which is what wikitext is ideally suited for. At an absolute minimum, {{convert}} would comprise code like:
{{{1}}} ({{#convert: {{{1}}} | {{{2}}} }})
So the answer to your question, no transition, plan for the transition, or feasibility study for the plan for the transition, is needed. What is needed is a comprehensive set of testcases for {{convert}} so that the updated code can be thoroughly tested to ensure it behaves similarly to the old template. Happy‑melon 15:16, 15 February 2011 (UTC)

[undent]

  • Using a #scale to round with end-zeroes: Yes, using a parser function inside of Convert sounds more realistic, to be ready within a few months, but just pass both the conversion factor, currently {b} such as 9/5, with a {shift} such as 32, as parameters into a {#scale:} parser function, and let the wikitext handle all unit names and symbols. The big issues are in matching precision of the input amount, plus adding end-zeroes (or scientific notation). That #scale could do the precision-calculation work, such as for temperatures:
• {{#scale:19.5|9/5|32|-99}} → 67.1
• {{#scale:19.5000|9/5|32|-99}} → 67.1000
• {{#scale:19.5060|9/5|32|-99}} → 67.1108
The "-99" would be set to override the rounding precision, where a "7" would mean 7 decimal digits, adding trailing zeroes to have all 7: "45.6700000". Then, for miles to km:
• {{#scale:34.5|1.6093440 |0|-99}} → 55.5
• {{#scale:1.0000|1.6093440 |0|-99}} → 1.6093
• {{#scale:1.00000000000|1.6093440 |0|-99}} → 1.60934400000
• {{#scale:20,000,000,000|1.6093440 |0|-99}} → 3.2×1010
The conversion of miles-to-km does not need an offset shift, so the 3rd parameter would be 0, as simply "miles * 1.6093440 round m" (or omitting the 3rd parameter would mean set to "0"). Using a #scale could remove all the complexity currently used, based on order of magnitude, to ensure the resulting precision does not round a small fraction to return a result of "0" (as being precise to 1 digit). There is a considerable amount of overhead, currently in Convert, for checking the precision of the input amount, getting order of magnitude, comparing the user's rounding count, and then padding for end-zeroes. Plus, Convert currently cannot determine the precision of scientific-notation numbers:
• {{convert|1.2345000E12|km|mi}} → 7.670827×1011
So, if a #scale could get the digit count for scientific notation, it would surpass Convert's math skills. The extra complexity, to be avoided in a parser function, is in trying to keep arrays of unit names and the related symbols, with the alternate spellings for British English, American English, Canadian English, Australian English, Indian English, (etc.) which users have wanted us to implement (only in units where there is a difference in terms). -Wikid77 18:27, 15 February 2011 (UTC)
It's not exhaustive but there's [1]. JIMp talk·cont 21:14, 15 February 2011 (UTC)

degree needs to read as degrees

In this expression: {{convert|30|to|66|F|C|lk=on}} it renders as "...66 degree Fahrenheit" instead of "degrees". I couldn't figure out how to fix it. Could someone give her a look? —MJCdetroit (yak) 02:44, 14 February 2011 (UTC)

  • Thanks for spotting that: it is indeed a simple spelling error, where the plural case is using the singular word "degree..." rather than "degrees...". Hence, it is simply a 1-letter fix by adding "s" when lk=on:
      • {{convert|30|to|66|F|C|lk=off}}     → 30 to 66 °F (−1 to 19 °C)
      • {{convert|30|to|66|F|C|lk=on}}     → 30 to 66 °F (−1 to 19 °C)
      • {{convert|30|to|66|F|C|lk=test}}   → 30 to 66 °F (−1 to 19 °C)* - FIX
    I will submit an edit-protected request to correct that particular case of the options. -Wikid77 06:13, 14 February 2011 (UTC)
Done. Plastikspork ―Œ(talk) 06:49, 14 February 2011 (UTC)
Gracias señors. —MJCdetroit (yak) 19:10, 16 February 2011 (UTC)

Brackets/square brackets instead of parentheses. disp=br

I started a new display function for using brackets(U.S)/square brackets(U.K.) instead of the parentheses(U.S.)/brackets(U.K.) that are normally rendered. In other words: these [] instead of (). It would be grammatically correct to have [] inside of (). For example: (Blah blah 55 miles [89 kilometres]). The code looks like this: {{convert|55|mi|km|disp=br}}. Unfortunately, the way it is set up it automatically does not abbreviate the units and it needs additional subtemplates added. But it is a start and if anyone wants to tweek it or start creating the needed subtemplates, by all means go for it. —MJCdetroit (yak) 19:32, 16 February 2011 (UTC)

How do you combine disp=br with disp=flip ?  Stepho  (talk) 19:56, 16 February 2011 (UTC)
You don't. Not yet anyway. —MJCdetroit (yak) 21:38, 16 February 2011 (UTC)
  • Currently, the option "disp=x" is intended to customize most of those special separators, such as allowing custom brackets with other options:
• {{convert|9|km|mi|disp=x| [|]}} → 9 kilometres [5.6 mi]
• {{convert|9|km|mi|disp=x| [nearly |]}} → 9 kilometres [nearly 5.6 mi]
• {{convert|9|km|mi|disp=x| [nearly |]|adj=flip}} → 9 kilometres [nearly 5.6 mi]*
Note the space before each " [". The temporary option "adj=flip" (usually "disp=flip") avoids "disp=x", but we were talking about having "order=flip" in the new condensed {Convert}. Meanwhile, the limited use of "disp=br" is fine, we just don't want to have all variations of options with "disp=br" because that requires over 1,100 more subtemplates for all the various names "Convert</Dual>/L*A*DbrS*[2|US*|Imp|Na|per|F|T]" (...already more than 7,000 subtemplate names before disp=br was added). Try to use disp=x with other options, but disp=br is fine with the defaults, and could be used with any option in the reduced Convert. -Wikid77 13:54, 17 February 2011 (UTC)
I had tried disp=x before, but I guess that the example just didn't sink into my very busy and thick head. I'll make some notes on the doc page. I don't want to reinvent the wheel. Thanks —MJCdetroit (yak) 14:05, 17 February 2011 (UTC)

Trailing zeros

I've noticed that the template is dropping trailing zeroes when used in prose now. The problem is that this is expressing less precise measurements than it should. There is a difference between saying that a road is 15.300 miles or 15.3 miles in length, especially when the source data for that measurement is precise to three decimal places. Imzadi 1979 → 06:51, 17 February 2011 (UTC)

  • Thank you for reporting that problem. I will submit the fix. Here are some examples to compare the trailing zeroes:
• {{convert|15.300|mi|km}} → 15.300 miles (24.623 km)
• {{convert|15.30000|mi|km}} → 15.30000 miles (24.62296 km)
• {{convert|760,000.55000|mi|km}} → 760,000.55000 miles (1,223,102.32514 km)
The problem was introduced when displaying the Unicode &minus sign, which used the absolute value for all amounts: abs( {{{1}}} ). I will fix the positive amounts. -Wikid77 14:09, 17 February 2011 (UTC)
Wikid77's fix has now been applied. Plastikspork ―Œ(talk) 20:10, 17 February 2011 (UTC)

Inconsistent conversion

I was reading the article on Douglas MacArthur and came across the statement, "approximately 4,700,000 acres (1,900,000 ha)... was purchased... and 4.6E+6 acres (1,860,000 ha) was resold". Since scientific notation is inappropriate here, I went to edit the page but found that the source reads "approximately {{convert|4700000|acre|ha}}... was purchased... and {{convert|4600000|acre|ha}} was resold". So, why is the template converting 4700000 to 4,700,000 but 4600000 to 4.6E+6 and can this be fixed? In the mean time, I assume there's a work-around that could be inserted into the MacArthur article so that both figures are formated as 4,-00,000 — if so, could somebody who knows the template better than I do please do that?

As a second issue, is it ever appropriate to write "4.6E+6" rather than "4.6 × 106"? My understanding is that the scientific community always uses "×10n" and "E+n" is, essentially, a legacy of seven-segment calculator displays. Dricherby (talk) 17:17, 17 February 2011 (UTC)

Is this first issue still a problem? I just checked {{convert|4600000|acre|ha}} vs. {{convert|4700000|acre|ha}} → 4,600,000 acres (1,900,000 ha) vs. 4,700,000 acres (1,900,000 ha). Neither is using scientific notation. I'm not sure about the second issue. Thanks! Plastikspork ―Œ(talk) 20:16, 17 February 2011 (UTC)
Use {{convert|4.7|e6acre}} to get "4.7 million acres (19,000 km2)". "4.6E+6" isn't appropriate but it sometimes gets through. JIMp talk·cont 21:05, 17 February 2011 (UTC)
  • The amount "4.6E+6" was probably caused by the same bug which chopped trailing zeroes, fixed today at 20:00. Yes, using "e6acre" to say "million" is more typical for common English usage. The new rounding logic (above under "#Plan fix to round negatives & 7 fewer expansion levels") will avoid scientific notation for millions & small billions:
• {{convert|2,000,000,000|acre|ha|lk=off}} → 2,000,000,000 acres (810,000,000 ha)
• {{convert|2,000,000,000|acre|ha|lk=test}} → 2,000,000,000 acres (810,000,000 ha)*
The intent is to support $billions of dollars with 9 zeroes, but use scientific notation for larger amounts. -Wikid77 22:51, 17 February 2011 (UTC)

Mass per volume

For Steel#Material properties: 7.75 and 8.05 g/cm3 (4.48 and 4.65 oz/cu in) and 7.75 and 8.05 g/cm3 (4.48 and 4.65 oz/cu in) Peter Horn User talk 18:09, 19 February 2011 (UTC)

  • DONE. With the default output unit, it gives:
• {{convert|7.75|and|8.05|g/cm3|abbr=on}} → 7.75 and 8.05 g/cm3 (0.280 and 0.291 lb/cu in)
So, new oz/cuin will multiply that by 16 (hence, divide {b} by 16, or {b}=.../16.)
• {{convert|7.75|and|8.05|g/cm3|oz/cuin|abbr=on}} → 7.75 and 8.05 g/cm3 (4.48 and 4.65 oz/cu in)
• {{convert|7.75|and|8.05|g/cm3|oz/in3|abbr=on}} → 7.75 and 8.05 g/cm3 (4.48 and 4.65 oz/cu in)
Change Template:Convert/oz/cuin to adjust density results, setting the default precision of j as needed. Thanks. -Wikid77 22:06, 19 February 2011 (UTC)
I tweeked the abbr output to reflect the more common cu in. —MJCdetroit (yak) 04:02, 20 February 2011 (UTC)

Porting Convert to other-language wikipedias

21-Feb-2011: There are a few other wikipedias which have variations of Convert, for converting one measurement to another. However, most wikipedias are years behind English Wikipedia's Convert. Meanwhile, {formatnum:} is wiki-specific, to format numbers for each language, 47305.6 in French as "47.305,6" or Norwegian "47305,6" where {#expr:} uses the same numbers everywhere, for portable calculations. Also, I am thinking to support options which are easier to translate into other languages. For example, "lk=1" would be lk=in, where "lk=2" would be lk=out. For "disp=output only", the equivalent would be "disp=out" to use the simpler word "out" (rather than the phrase "output only") or use disp=2.

Some other wikipedias have the old giant-switch version of Convert (from October 2007) which contains 6 sets of internal #switch statements for perhaps 35 unit-codes. After the January 2008 upgrade to the MediaWiki NewPP processor, that old Convert has similar resource usage to modern enwiki Convert. However, they do not support option "abbr=none" and the output always shows the unit symbol. The precision must be hand-rounded, but the template checks the input amount for "1" as being singular. They need "disp=out" ("disp=output only") to allow hiding a foreign input unit, such as hiding data from a foreign source reference, to show only the common unit for that language. To upgrade to the modern Convert, and get automatic rounding, they might need 50 subtemplates. For example:

However, many other-language wikipedias do not use Convert:

  • For German Wikipedia, de:Vorlage:Konvert is a new formula calculator (30Dec2010), requiring a conversion factor, each time, with English-number input but German-number output using "=" not "( )" as: {{Konvert |x=12.3|a=9/5|b=32|e=2|von=°C|nach=°F}} → 12.3°C = 54,14 °F.

Fortunately, the title "Template:Convert" can be a redirect in the other-language wikipedias to a real, equivalent version of Convert. So, I was thinking to create a list of the 50 basic Convert subtemplates which would enable any wikipedia to support the typical 35 unit-codes (such as: m, yard, ft, inch, cm, kg, pound, gram, ounce, etc.). From that base, they could extend Convert to handle any of the hundreds of other units. Many languages have the English unit "foot" (ft) as a word in their own languages (often the same word as the human foot). More later. Wikid77 12:09, revised 14:12, 21 February 2011 (UTC)

Fixing other-language wikipedias

23-Feb-2011: As a first step to upgrading conversions in other-language wikipedias, I have attempted to fix their current templates. The Norwegian switch-based no:Mal:Convert was easy to fix, with few problems, so far. However, currently, there are numerous problems in other wikipedias, such as French Wikipedia, with a wrong formula, wrong spelling, and incorrect wikilink for gram-to-pound (gramme à livre):
    • WAS:   {{fr:Modèle:Conversion|454|g|lb}} → 454 grams (205 930,93598 livre |lb)
    • NOW:   {{fr:Modèle:Conversion|454|g|lb|2}} → 454 grammes (1 lb)
The French spelling should be "454 grammes" and the incorrect formula caused it to miss 454 g is actually "1 lb" (not 205,930.9...lb). To avoid all those numerous problems, the English Wikipedia has used an "ingeniously brilliant" system of dynamic templates (since October 2007), allowing any user to add a new unit (as just 1 subtemplate), and set the formula, spelling and wikilinks in just one spot, rather than sleuthing the other formulas and logic needed to interface a new unit with older units. A new unit can be added, live, into English Wikipedia without affecting the prior 2 million conversions already in other articles. By comparison, some wikipedias must typically modify many parts of their template structure, such as 15 places to add a new unit into French Wikipedia's template "Modèle:Conversion" to handle "gramme" (hence explaining why the French WP template still has many errors in some of those 15 parts). Anyway, I have begun updates to the French template, which were reverted by them, so it will be a slow process. More later. Update: I have fixed the 3-year errors in formula numbers and spelling in the French template (fr:Modèle:Conversion), but within minutes, an admin restricted editing as a fully-protected template, so I could not fix 50 other errors. -Wikid77 15:21, 23 February 2011, revised 20:17, 24 February 2011 (UTC)

Giant-switch Convert unmaintainable in other wikipedias

25-Feb-2011: I have been correcting problems for the giant-switch versions of Convert, on Norwegian Wikipedia, French Wikipedia, Spanish Wikipedia, and Italian Wikipedia. From examining multi-year problems in those templates, I can confirm that the giant-switch design (using 8 major #switch sections) is not maintainable, in a volunteer effort. In those templates, rather than having each unit defined as a few lines in 1 specific subtemplate (as done on English Wikipedia), the giant-switch design fractionates the effort into 7 or 8 giant #switch sections, for each unit. The result has been just too convoluted for volunteers to pinpoint all the scattered details to define each unit name. The multi-year problems in the giant-switch design have been horrendous: almost no new options had been added in 4 years, the French WP could not correctly convert grams to pounds ("livres" or onces: "onces"), and the Spanish template could not always spell meter as Spanish "metro" (using British "metre" instead), depite use in over 5,000 articles on Spanish WP. Dozens of spelling errors have existed in unit names for the past 3 years, and these templates were unprotected, to allow even IP addresses to correct unit names, but it did not happen.

The problems caused by fractionating details into multiple sections (known in computer IT as the "dual maintenance problem"), have been insurmountable to the volunteer editors. Because each unit name is scattered among 7-or-8 major #switch sections, the editing for details is, perhaps, 30x-90x times more difficult than having a small 1-per-unit subtemplate. Inside the major #switch sections, there are up to 151 #switch cases to set the spelling of unit names. The grammatical correctness of handing each unit becomes nearly identical to the correctness of all details inside the giant template, because: to most users, there is no obvious pattern as to why each unit appears in 7 or 8 places inside the enormous, complex template. Copy-editing for the spelling of each unit gets buried into copy-editing for all details, hence, 30x-to-90x times more difficult than 1-per-unit subtemplates. The result: major problems have persisted for more than 3 years, and almost no new units have been added. These problems were not buried inside some parser function, restricted to only annual updates, or locked inside edit-protected subtemplates; no, these spelling and formula problems were hidden inside just 1 complex, confusing template to be freely edited on each other-language Wikipedia. More later. Wikid77 22:04, 25 February 2011 (UTC)

Spelling things out?

It would be nice to have an option to spell the input and/or output numbers out by adding a parameter, |word= or something. For example, {{convert|2|lb|kg}} would yield two pounds (0.91 kg) instead of 2 pounds (0.91 kg). Obviously, there would also need to be a parameter called |cap= or something that, if set to on, would capitalize the input unit. --- c y m r u . l a s s (talk me, stalk me) 21:41, 27 February 2011 (UTC)

Why would we need to capitalise to input unit? JIMp talk·cont 22:08, 27 February 2011 (UTC)
I think he means 'two' instead of '2' for the output (ie words instead of numbers). Presumably it would have to automatically choose to do words only for single digit numbers.  Stepho  (talk) 23:56, 27 February 2011 (UTC)
Yeah, that's what I meant. And then also, if one were using the template at the beginning of a sentence (e.g., "Two pounds (0.9 kg) of flour was loaded into the truck."), the input unit would have to be capitalized. --- c y m r u . l a s s (talk me, stalk me) 00:32, 28 February 2011 (UTC)
  • It would need to be a separate wrapper template, somewhat like {{Convert/gaps}}, which is external to Convert. We have to limit what options are supported, internally, by the "standard Convert" due to MediaWiki's severely small expansion depth limit of a mere 40 levels of if-else logic (see: m:Help:Expansion depth). When I recently added the Unicode &minus (as in "−6.500"), I realized why the simple hyphen had been used for years. You see, putting an &minus required reversing the sign of the number, by invoking a #expr expression which trimmed trailing zeroes, as another level of expansion depth, requiring re-padding of zeroes (+1 more level) for the length for the prior string-length (+2 more levels), or else use a {str_right} after the hyphen-minus, invoking perhaps 18 more expansion levels. Other templates in Wikipedia are also demanding about 20+ levels of nested logic, effectively limiting Convert to only 20 levels (half of the 40-level limit, as each template competes to offset the other). Every time the total limit is exceeded, then all forms of Convert are likely to get blamed, and someone will claim that Convert is a useless, inefficient resource hog, while they use 35 {Cite_web} consuming 1,500x times more resources than Convert. However, a specialized wrapper template, perhaps called {{Convert/spell}}, could be used to dip into Convert's 28-level depth, and then come back up to level 2, with "disp=number" to format the numbers as spelled-out phrases, dipping into another 20-deep(?) set of number-to-word templates, as needed (to show "Negative two-and-one-half degrees"). The other magic is "disp=unit" to display the unit name (or symbol), as singular or plural for the amount, after the spelled-out numbers.
    Consider Template:Convert/gaps to be the "poster child" example of how to write exotic wrapper templates to perform very sophisticated tranformations of conversions, as if the expansion depth were beyond 100 levels deep, as in modern computer software. In this age of video-phone calls, please don't feel limited by the current Convert options, but understand: at this point, "worry [tremendously] about performance". The naive days are over, where developers assumed, "Users are too stupid to ever understand how templates are parsed". Instead, we must focus on ways to avoid the performance bottlenecks, while also adding functionality. Of course, Spanish Wikipedia uses "g/m3" for density, but not in their es:Plantilla:Convert, which is still limited. And of course Spanish WP needs to show English unit names, in Spanish articles: half of the Spanish-speaking people on Earth are illegal aliens living in the U.S. or along the Canadian border (well, maybe not half). That's why U.S. television news often reports that immigration screening is a hoax, and everyone should go to work today, or the American cities would collapse if illegals stopped working. Spanish speakers might be more likely to weigh their vegetables in pounds, rather than kilógramos. Hence, a tri-lingual Convert is needed in the Spanish WP, with sp=en, sp=us, and sp=espanol. If a source says a length was "10 feet" then that would be shown with Spanish "metros". So, yes, we need Convert to support more options, but some must use Convert wrappers to fit within the template limits. Putting numbers into words, with decimals and fractions, would take some time. Meanwhile, prefix the text as "Nearly 35 miles" or just hard-code the words, of the input amount, and follow with a "disp=out" for the result, until a spell=on, spell=in, and spell=out, can be implemented. The most common numbers seem to be 3-digit integers ("120 miles"). -Wikid77 06:51, 28 February 2011 (UTC)

Wouldn't it be easier to just write the original value outside the template and then put the template in parentheses using the disp=output only parameter? Typing Two pounds ({{convert|2|lb|disp=output only}}) of flour yields Two pounds (0.91 kg) of flour. Actually, I had hoped that disp=unit would do this more efficiently, but that parameter actually suppresses the conversion too. Two {{convert|2|lb|disp=unit}} of flour yields Two pounds of flour, but it would be better if it (or some other parameter) yielded Two pounds (0.91 kg) of flour. Pais (talk) 10:33, 28 February 2011 (UTC)

Using disp=out is always an option: The new disp=2 or disp=out (formerly disp=output only) allows much flexibility, but I try not to judge if particular features are not needed, because: some people claim "not using Convert" is the easiest solution of all. Of course, we know, now, what happens if Convert is not used: people would simply neglect to show conversions in most cases. Avoiding fractions seemed to be an obvious "not-needed feature", but in fact, fractions are more common than thought: a fathom was once 5–5+1⁄2 feet (1.5–1.7 m), depending on which ship measured the depth. So, I would support a {{Convert/spell for, at least, the common 3-digit integers. Adding new features has had an excellent "spinoff effect" in expanding Wikipedia's general utility templates. -Wikid77 15:08, 28 February 2011 (UTC)

Line wrap

Today I noticed a line wrap that I did not expect.

{{convert|1400|ft|m|-1}} → 1,400&nbsp;feet (430 m)

The line wrapped between 430 and m. There is no &nbsp; between 430 and m. I didn't think that was supposed to happen. Has something changed?  –droll [chat] 08:21, 28 February 2011 (UTC)

  • Use abbr=mos to insert "(430&nbsp;m)" until we get the default options fixed to put no-wrap of the result. I realize the wrapping has been a frustration for a while. -Wikid77 15:08, 28 February 2011 (UTC)
  • Thanks for the reply. I'm not going to worry about it as long as I know its on someones "to do" list.  –droll [chat] 20:34, 28 February 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_February_2011&oldid=1130196880"