Jump to content

Template talk:Convert

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

This is an old revision of this page, as edited by MiszaBot II (talk | contribs) at 09:11, 7 February 2011 (Archiving 3 thread(s) (older than 21d) to Template talk:Convert/Archive January 2011.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Subpages here:

Pferdestärke

This unit conversion seems to default to (SAE?) horsepower. This unit is a former DIN standard and is familiar to many "older" Europeans since we aren't as familiar hands-on with the EG units mandates. Also, for the sake of accuracy it should be corrected. The section in the template of convert should list explicit units of power allowed and abbreviations expected for input not just the 'common units etc...' as is in place now. That's how we find this problem.

SirDeath (talk) 1901, 22 April 2010 (UTC)

Possible improvement

First, to those who develop and maintain this template and its offspring - thank you for your work. I wanted to make a request of you, if anyone has the time or inclination: would it be possible to format the template's operations (or create a template option) so that a non-breaking space occurs between the number and the unit symbol for that number, when it is being produced as the result of a conversion in this template? If I'm not expressing myself clearly, leave a note at my takl page and I will try another explanation! Regards, hamiltonstone (talk) 06:06, 18 January 2011 (UTC)[reply]

  • USE: abbr=mos. Currently, the option "abbr=mos" (meaning the "WP:MOS" Manual of Style) inserts " " (as  ) for amounts less than 1,000 units. The rationale is to not wrap "1 dog" or "101 Dalmations" but to allow wrapping "9,000 kilometres" or "3,000,000 acres" (or similar numbers). Example:
      • {{convert|17|km|mi|abbr=mos}} → 17 kilometres (11 mi)*, with "17 kilometres"
    To nowrap an entire conversion, surround with {{j|...}} to join the whole as one unwrapped line of text. -Wikid77 15:13, 18 January 2011 (UTC)[reply]
That should be the default. I don't see anywhere on the MoS suggesting that whether or not to include the nbsp should depend on the number. It has always been that the template should follow (or at least default to) the MoS (remind me again why abbr=mos was introduced). JIMp talk·cont 21:12, 18 January 2011 (UTC)[reply]
The option "abbr=mos" was introduced for range conversions, to repeat the unit name twice ("2 feet by 4 feet"), just to match what WP:MOS had as written rules, even though normal people use the unit name just once, as a form of elliptical phrase (2x4 feet). Example:
  • {{convert|3|x|6|ft|m|abbr=mos}} → 3 by 6 feet (0.91 m × 1.83 m)*
Next, I extended the use of abbr=mos to single-unit conversions, to force the "&nbsp" at the unit symbol (such as "67 cm"), but then the issue of "17 kilometres" seemed like a nowrap (as would "1 dog" or "a dog"). Hence, the result was a follow-on consequence of logical wrapping in typesetting. Meanwhile, the dreaded, miserly expansion depth limit (of 40) was considered a well-decided, long-term limit (not a hideous mistake to be corrected soon, as 60 or 200, by common sense). That severely cramped limit of 40 had made me reluctant to make &nbsp be the default, for fear of increasing the expansion depth of typical Convert usage any farther. Hence, much of my time has been spent fighting the "wiki-depth war" to win back some of the 28 levels of if-else or template nesting, to allow super-smart conversions, where we would add dimensionality and parameter validation in the extra expansion levels freed by using {{Getprecision}} rather than {Precision} and such. -Wikid77 13:20, 19 January 2011 (UTC)[reply]
Thanks to you both. I tried inserting abbr=mos in place of abbr=on at Painted_turtle#Seasonal_routine_and_hibernation. It had some very odd effects. In one spot it did not work at all, producing only some redlinked gobbledygook; in another it resolve the wrapping problem, but only abbreviated the converted factor (ft), while spelling out the other in full (metres). Neither was very satisfactory. The Template:j solution worked, but of course it wraps the entire thing, which seemed a little like overkill - anyway, I ran with the template:j solution. thanks. hamiltonstone (talk) 05:34, 19 January 2011 (UTC)[reply]

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)[reply]

It could be done. JIMp talk·cont 00:39, 23 January 2011 (UTC)[reply]
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)[reply]
  • 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}}  → Template:Convert/3
• {{convert/3|8.0|x|5.3001|x|4|in|mm|abbr=on}}  → Template:Convert/3
• {{convert/3|10|-|20|+/-|0.5|m|ft|abbr=on}} → Template:Convert/3
• {{convert/3|10|-|19|never|20|m|ft|abbr=on}} → Template:Convert/3
• {{convert/3|1|to|9|rarely|10|m|ft|abbr=on}} → Template:Convert/3
• The road was lengthened as {{convert/3|5|-|7|-|12|km|mi|abbr=on}}.
 → The road was lengthened as Template:Convert/3.
• {{convert/3|8|x|5.30|by|4|m|ft|adj=mid|high}} → Template:Convert/3
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)[reply]

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)[reply]

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)[reply]

"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?

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[reply]

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)[reply]

  • 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)[reply]
Awesome, thanks! LittleMountain5 23:48, 2 February 2011 (UTC)[reply]
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)[reply]

Arpent request (resurrected)

Back in November 2010, I started this short thread:

I just had a need for convert to support arpent, a French units of measurement which depending upon context is either a unit of length or of area. I worked around its absence by using an arpent-to-acre conversion that another editor had done, and having convert do the math for the metric equivalent. If obscure units such as the arpent are within convert's charter, consider this a request that support for it be added. Thanks. 67.100.127.81 (talk) 20:50, 18 November 2010 (UTC)[reply]
  • The "arpent" was already requested & added (but not in the documentation), months ago, as the Canadian arpent (of area), used from the French Louisiana colony, which I think might be the same unit:
  • {convert|45|arpent} → 45 arpents (15 ha)
  • {convert|1|arpent} → 1 arpent (0.34 ha)
As for obscure units, we are also considering the "Egyptian cubit" as {convert|30|Egyptian cubit} → 30 Egyptian cubit[convert: unknown unit]. That's what I remember so far. -Wikid77 (talk) 14:59, 19 November 2010 (UTC)[reply]

You're right, it is the same unit, though the arpent article claims without reference that there were small variations in the conversion to acres depending on which U.S. state ended up with jurisdiction. I was going to use arpent in this version of the Webster Groves, Missouri, where there's discussion of its history as part of the Louisiana Territory, which was part of French Louisiana. I guess I should have just tried it:

  • {convert|100|arpent|acre ha} → 100 arpents (84 acres; 34 ha)

BTW, I notice you can't do the reverse:

  • {convert|84|acre|arpent ha} → 84 acres (99 arpents; 34 ha)

though you can do this if you don't mind the difference in rounding:

  • {convert|84|acre|arpent} → 84 acres (99 arpents)

though that's not the use I was looking for anyway.

Belated thanks. 67.100.127.81 (talk) 05:29, 30 January 2011 (UTC)[reply]

Case sensitivity

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

Interesting... :D Happy‑melon 23:49, 2 February 2011 (UTC)[reply]
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)[reply]
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)[reply]
What about kilotonne? JIMp talk·cont 09:40, 3 February 2011 (UTC)[reply]
An excellent question... :D Happy‑melon 14:17, 3 February 2011 (UTC)[reply]

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 "&#x202E;(&#x202C;" 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)[reply]

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):

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)[reply]

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:

Generally, for English Wikipedia, commas are preferred, to avoid the illusion of multiple 3-digit numbers in a row: Template:Gapnum 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)[reply]

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)[reply]

  • 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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert&oldid=412502620"