Template talk:Convert/Archive January 2011

This is an archive for Template_talk:Convert for 2011.

Some editors do not like conversion templates

Outside of engineering, railway and geography articles some editors object to conversion templates, claiming that they slow down the "load time" of the article. E.g. Daniel Lambert, calling them "pointless" as voiced by User:Iridescent 2. Peter Horn User talk 20:25, 7 December 2010 (UTC)

Do they have any statistics on this alleged slow down? I use it heavily in automobile articles and haven't noticed any significant slow down. I like to use it because it privides a constency of style (not mixing km/h, km/kr, km/h, etc) and always uses the correct conversion formula. Manual conversions may or may not use the correct formula. And not providing any coversion at all (using this template or manual) leaves readers in the dark when they see unfamiliar units. I'm also hoping that one day all usage of this template will show only the units according to the reader's preferences (ie a particluar article has some value in miles and some values in km but an Australian reader sees everything in km and an American reader sees everything in miles).  Stepho  (talk) 03:57, 8 December 2010 (UTC)

In the past 6 days, I finally checked template-performance issues in article "Daniel Lambert" and found the usage of Convert had little overhead, while the citation templates, in that article, were using 1,500x times more resources than Convert. So, accusing Convert of slowing the load-time, for Internet display of the article, was like saying, "Your 5 drops of water are the reason my full bucket will overflow". From what I saw, IMHO, the "pointless" templates in that article are {{sfn}} (used 159! times to put <ref> footnote links) along with various huge citation templates.
If fact, the templates {{citation}} with massive {{citation/core}} are gargantuan templates to put italics on reference titles and use questionable "scholar-format" where Volume 1 is shown as bolded "1." rather than stating "Volume 1" which most people would realize was volume 1 (of a book set). I think the root problem is, perhaps, essay "WP:Don't worry about performance" where people have been badgered to NOT learn, over the years, what really slows down article-load times, and instead, people imagine what might be a problem, due to almost everyone not studying performance (for years now) to really explain the priorities. Hence, we shouldn't blame any particular person for imagining Convert had caused a timing problem, when in fact, the citation templates were 90%-95% of that article's content. I will write an essay, "WP:Comparing Convert to WP gigantic templates", to begin explaining the performance issues. Some admins have even argued about the enormous size of the citation templates, for something as trivial as footnotes, while requiring users to put "http: //" in every URL (which should be automatic). Anyway, that's enough talk about problems in other templates, here (continue at Template_talk:Citation). -Wikid 17:54, 14 December 2010 (UTC)

• Navboxes are slow: The only real slow-down, of article load times, seems to come from those bottom navboxes (which are each multi-nested large templates). Tell people to comment-out most of those bottom navboxes (by putting "<!--" & "-->") during edit-preview, to make articles load 2x-4x times faster during each re-display. If they forget to uncomment navboxes before saving, it is no problem because other editors will re-add the navbox overhead processing if needed desperately enough. I am working on fixing {Navbox} so that it does not store HTML comments in each of 1.3 million formatted articles. However, navboxes make articles often 2x-4x times larger, hence obviously 2x-4x slower to load. I've never seen an article load slowly because someone used 10 instances of {Convert} - it just doesn't work that way. However, we are trying to make Convert even faster. -Wikid77 (talk) 23:07, 8 December 2010 (UTC)

Upon inspection, I see that the most common subtemplates of Convert could be changed to allow "subst:Convert" to save just the formatted results of a conversion, and omit the 19 subtemplates from an article's internal structure. This would be a possibility in articles with just a few conversions, where the numbers would be unlikely to change. So, using {subst:Convert|4|ft|m} would store "4&#160 ;feet (1.2 m)" in the article text, and no longer invoke all the 19 {convert/ft}, {convert/m}, {precision}, {rnd}, etc. Of course, now, anyone is free to run Convert, to just copy/paste the results into an article, so if people want to hard-code the results of a few conversions, then that is fine. The trouble comes when an article has 9 or more conversions, and numbers are likely to change, so that conversions would need to be easily adjusted by other people, not just someone who wants to copy/paste results in every article edited. Plus, if an article is seldom read, there is no need to optimize it by hard-coding the conversions.
So, that is why I mentioned the huge navboxes: they are a problem every time an article is edited, or read, where the navbox links are not of much interest to general readers. Before gigantic navboxes are forced into an article, there needs to be an objective study to determine how many, of "700 wikilinks", the readers will need to use. Even now, the See-also links are rarely clicked in articles. Hence, bypassing the unneeded navboxes probably releases 1000x times more speed, than worrying about using Convert a few times in a popular article. In a sense, most navboxes are like forcing a list of each category's members to appear at the bottom of an article: it is just too much "tramp data" to be practical in a computer system of limited resources. So as long as an article has navboxes, worrying about Convert overhead is like drying grains of sand along a beach shoreline: thinking that Convert makes articles slow is "straightening the deck chairs on the Titanic" slow-down problems caused by navboxes. -Wikid 17:54, 14 December 2010 (UTC)

After looking at some of the above reactions I feel that the use of conversion templates ({{template}})should be mandatory as it appears to be the only way to get accurate and errorless conversions. How do we get the "dynosaures" in line? I will need to look thru my past contributions to find those editors who reversed my insertions of {{template}}. Peter Horn User talk 05:47, 4 January 2011 (UTC)

I forgot to mention that Chesapeake Bay Bridge and Talk:Chesapeake Bay Bridge#Dimensions show that "longhand conversions" (non use of templates) are problematic. Peter Horn User talk 16:33, 17 March 2011 (UTC)

Preparations for 2011

I have prepared the supporting files for new year 2011, as follows:

• Template_talk:Convert/Archive_January_2011 - new talk-page archive
• Template_talk:Convert/updates/Archive_1 - archive of prior updates
• Category:2011 Convert unit subtemplates - subtemplates of 2011
• Category:2010 Convert unit subtemplates - subtemplates of 2010

There are still many small changes needed, among the 3,200 subtemplates, to make all the various options of Convert to be more consistent in all cases. Plus, we have been talking about the "dimensional analysis" issues, to have Convert warn a user when some combinations of units are a mismatch, such as catching "mi" miles with typo "kg" (kilogram) rather than "km".

With the supporting files prepared now, we can continue making daily improvements as time permits. -Wikid77 22:06, 1 January 2011 (UTC)

Abbr=on error?

Recently, when I fill in new parameters of an infobox with the convert template and use "abbr=on" at the closing of the string, I get an error (Expression error: Unexpected < operator|Expression error: Unexpected < operator|(Expression error: Unexpected < operator)|Expression error: Unexpected < operator) for each as you can see here. I get this error most of the times and at others I don't. Any idea what the problem is?

Yes, this is a known issue. Basically when you don't specify the rounding precision, this template has a deep transclusion depth. The power station infobox is using subclassing, which adds two to the depth over the usual infobox. This is just enough added to the transclusion chain to break stuff. Take a look at the threads discussing this at rnd if you are interested. Long story short, it wasn't the "abbr=on", but the lack of the "0" or "sigfig=x" in the call to this template which caused it to transclude too many templates in the transclusion chain. Plastikspork _―Œ^(talk) 03:31, 8 January 2011 (UTC)

Thanks for the help, that makes sense. I will add the "0" in from now on. The power station infobox was redone a few months ago too which is probably why this has happened recently.--NortyNort (Holla) 03:42, 8 January 2011 (UTC)

That's right. That was what sparked the most recent thread at Template talk:rnd. There is some hope that we might be able the reduce the depth of this template, but until then, it's safest to just specify the precision manually. Thanks! Plastikspork _―Œ^(talk) 05:37, 8 January 2011 (UTC)

pounds per square foot

I'd like to be able to show grams per square metre. However I can't work out how to do it. I tried:

• {convert|0.026|lb/sqft} = 0.026 pounds per square foot (0.13 kg/m²)
• {convert|0.026|lb/sqft|g/m2} = 0.026 pounds per square foot (130 g/m²)

Can anyone help? Lightmouse (talk) 13:59, 8 January 2011 (UTC)

Sure, there are a couple problems here. (1) People often mistake lb for lbf, so many of the lb templates have been redirect to lbf templates, (2) The lb/sqft template is broken, which is why it just says "pounds", rather than "pounds per square foot". I will try to fix it, but we should probably strongly consider moving this to "lbm/sqft" and adding "mass" to the label. Plastikspork _―Œ^(talk) 16:57, 8 January 2011 (UTC)

Okay, it looks like the top two are fixed, but I still think we may run into problems since lbf/area is common for pressure. Plastikspork _―Œ^(talk) 17:10, 8 January 2011 (UTC)

Thanks. Yes, I'm aware that there is a popular use of 'lb' for pounds force. It's frustrating. We'll just have to keep it as a known issue and do what we can to solve it. Thanks for updating Corrugated fiberboard which was the article that drew my attention to the issue. In fact, that article originally had '26 lb/1000 sq.ft'. I was bold and changed it to 0.026 lb/sqft but I suspect that won't be universally welcome. I come across such formats infrequently. Is there a generic solution? Lightmouse (talk) 11:31, 9 January 2011 (UTC)

If you check the transclusions of Template:Convert/g/m2, Template:Convert/kg/m2, and Template:Convert/lb/sqft, you can double check to make sure all are being used appropriately. The biggest potential problem is there is no error checking between the input and output unit. So, this template will readily perform nonsense conversions like {{convert|50|m|lb/sqft}} → 50 metres (). I had some thoughts about a straightforward way to fix this, but have had no chance to test these ideas. There was some discussion about this a month or two ago. Plastikspork _―Œ^(talk) 16:30, 9 January 2011 (UTC)

Thanks. I'll try to go through the transclusions when I've some free time. Checking mismatched input and output units would help. I've seen discussion about that too. I'll leave that up to others. Lightmouse (talk) 16:40, 9 January 2011 (UTC)

HELP:Convert now links to How-to guide

You might recall, several months ago, how we had talked about collecting technical details, about the inner workings of Template:Convert, which became essay "WP:Advanced Convert coding" now with shortcut HELP:Convert. Other people have considered that essay to be a "How-to guide", so now I have re-worded it and added the newer options. It also describes how to write (and test, or debug) a new unit subtemplate (such as Convert/whatsit), using {Convert/LoffAoffDbSoff} inside a unit subtemplate during edit-preview of the markup code. By experimenting with parameter settings, during edit-preview, the values of conversion factor {b} and precision {j} can be adjusted, over and over, to set the exact values before saving the edit. The How-to guide is a separate document from the FAQ sheet, Template:Convert/FAQ, which lists some common questions. -Wikid77 05:38, 10 January 2011 (UTC)

MediaWiki extension

It may be possible, and desirable, to implement some of the functionality of this template as a MediaWiki extension. For instance, it would be easy to create a {{#convert: 5km | mi }} which would output 3.1 mi, and a link could easily be incorporated: {{#convert: 5km | mi | link }} → 3.1 mi. Various other things would be possible as well, but there's no question of incorporating all the functionality of this template, it's just too multifaceted (and function-specific). My question is: do you have any suggestions about which functionality could be included in a parser function, and which would be best left in the template? Remember that, unlike wikitext, input to a parser function can be easily processed by string manipulation: we could incorporate {{#convert: 5-7km | mi }} → 3.1-4.3 mi, where the output uses the same separator as the input: {{#convert: 5 to 7km | mi }} → 3.1 to 4.3mi. What else would be useful to incorporate? Happy‑melon 20:46, 7 January 2011 (UTC)

Having this in a MediaWiki extension would be amazing, but my experience has been that the folks that maintain the backend are very cautious about adding new features. However, as a start, I would say getting any parserfunctions which can help reduce the depth of this template would be welcomed. I believe the biggest issue is the precision detection / rounding logic. It's been awhile since I dug into this template, but I know there are others who would have more opinions on this matter (e.g., Jimp and Wikid77). Plastikspork _―Œ^(talk) 03:35, 8 January 2011 (UTC)

What algorithm does it (endeavour to) use for precision/rounding at the moment? Happy‑melon 12:13, 8 January 2011 (UTC)

Precision algorithm: - I have begun using new Template:Getprecision to determine the rounding parameter which can set the output amount to match the precision of the input, plus any fraction (such as "2+34/125" as "3" because denominator 125 has 3 digits). We did not write Template:Precision which has several complex bugs. Anyway, one day, it would be good to handle scientific notation, as with 3.6745E-5 having precision "4" to match 4 decimal digits. Meanwhile, we are planning to overlook commas but count many zeroes such as 6 quadrillion (6,000,000,000,000,000 as "15"). Overall, it is an annoying variety of numbers to handle, but perfect as a parser-function for engineering work. Of course, we desperately want {#len:xxx} and {#substr:xxxzzz|0|3} for 4 million other cases, but any help with Getprecision would be beneficial in 325,000 conversion articles. -Wikid77 06:24, 10 January 2011 (UTC)

Handling exponentials is very easy in an extension; the precision of the whole number is equal to the precision of the precision of the base, since the exponent is exact, so you can just discard the exponent altogether. Why is the precision of 6 quadrillion 15?

In my draft of the extension at the moment, it calculates the default precision to be the least precise value for which the percentage error in the output is less than the percentage error in the input. So in the example from NIST, "36 ft" has a percentage error of 0.5/36=1.4%, and so the output "11.0" is chosen as that has an error of 0.45%, whereas "11" has an error of 4.5%. Is this a reasonable algorithm to use?

A better idea would be to have the percentage error in the output to be between 1/√10 and √10 times that in the output: to be pedantic you might get slightly excessive precision sometimes, but on the other hand you don't normally want to round a value such as 84 kilograms (185 lb) to the nearest ten pounds or 6 feet 1 inch (1.85 m) to the nearest 0.1 metres. --A. di M. (talk) 14:05, 10 January 2011 (UTC)

I had misread your proposal, which I think is not as bad as the way I had misunderstood it, but I still think mine is better: I'm not sure you'd normally want to give tenths of a kilogram in 185 pounds (84 kg) or tenths of an inch in 1.85 metres (6 ft 1 in). --A. di M. (talk) 14:12, 10 January 2011 (UTC)

It has to be a heuristic algorithm, a "keep iterating until foo" process, but the "foo" is very much open to interpretation. Note that it's possible for there to be two precisions falling within the range you suggest (eg 28 ft = 9 or 8.5m); which should be chosen in those instances? Happy‑melon 14:49, 10 January 2011 (UTC)

Ah, you're computing the relative error directly on the rounded output, so that algorithm isn't exactly equivalent to the one I had in mind. 28.0 ± 0.5 feet equals 8.5344 ± 0.1524 metres, so the requirement that the error should be preserved to within a factor of √10 means that it should be between 0.048 and 0.48 metres, which can be achieved by taking it to be 0.05 metres i.e. rounding to the nearest 0.1 metres (yielding 8.5 m, though in this case it's a very close call). This would be equivalent to the current default rounding as described in the template documentation, except that the thresholds would be increased from 0.2, 2, ... to 0.316, 3.16, ..., and except for temperatures.

Then there's the issue of how many zeros should be considered significant when the input is a number such as 800, of whether there should be an exception when the output would otherwise have one smallish significant figure as in 1 kilometre (1 mi), and so on. --A. di M. (talk) 17:26, 10 January 2011 (UTC)

Indeed, many algorithms are justifiable, to a greater or lesser degree. I've just closed the spreadsheet in which I found that edgecase, unfortunately, but IIRC I was applying the √10 factor to the percentage error rather than the absolute, which is a slightly different process again.

There's no obvious way of deciding the precision of a number with trailing zeros by hand, let alone by computer. Interestingly, though, the precision of 8.00E2 is not in any doubt, nor is 8E2, so that may be a good way of dealing with that issue. Happy‑melon 23:07, 10 January 2011 (UTC)

Are there any units other than feet and inches where the input is two separate numbers? Happy‑melon 13:09, 10 January 2011 (UTC)

Stone and pounds might pop up in historic British contexts, and maybe something else. --A. di M. (talk) 00:03, 11 January 2011 (UTC)

XX km² (XX sq mi; XX acre)

Could we somehow fix this problem?
1.7 km² (0.66 sq mi; 420 acres)
Flying Saucer (talk) 23:50, 10 January 2011 (UTC)

Appears to be fixed? Plastikspork _―Œ^(talk) 23:07, 11 January 2011 (UTC)

Yeah, now it's fine. Thanks to Jimp. Flying Saucer (talk) 01:47, 12 January 2011 (UTC)

Troy ounces

For Sullivan Mine, conversion of troy ounces (?) to grams etc. Peter Horn User talk 05:22, 6 January 2011 (UTC) Peter Horn User talk 05:24, 6 January 2011 (UTC)

Use ozt. JIMp _talk·cont 08:22, 6 January 2011 (UTC)

Thanks, implemented. Works fine. Peter Horn User talk 01:40, 15 January 2011 (UTC)

I made a new one e6ozt. JIMp _talk·cont 05:32, 15 January 2011 (UTC)

Rejecting nonsense conversions in each subtemplate

10-Jan-2011: This is a reminder about changing subtemplates to issue error messages when users attempt to use (some) nonsense output units. The warning messages can be displayed by Template:Convert/try, to reject the most likely mistakes. The following example warns about 5 possible mistakes in converting g/m2 to other units, using a #switch with 3 branches:

</nowiki>
{{#switch: {{{3}}}
| lb|sqft
  = {{convert/try|use=lb/sqft|was={{{3}}}|{{{1}}} g/m2|}}
| kg = {{convert/try|use=kg/m2|was={{{3}}}|{{{1}}} g/m2|}}
| cm|cm2 = {{convert/try|use=g/cm2|was={{{3}}}|{{{1}}} g/m2|}}
}}
</nowiki>

For example, using Template:Convert/g/m2, suppose someone wanted to convert 9.5 grams/m2 into square-feet, but forgot the output unit-code should be lb/sqft, and they just used invalid "sqft" by mistake, in {{convert|9.5|g/m2|sqft}}, giving the warning:

• 9.5 grams per square metre ()

In the past, we have studied the general problem, for years, and decided to only reject the most likely mistakes, because re-structuring for complete "dimensional analysis" seems like too much overhead in processing each conversion. Hence, for each Convert subtemplate of unit-per-unit (such as: g/m2), expect 5 typical invalid units (such as: lb, sqft, kg, cm, cm2) to be rejected using 1 switch with 3 branches, as shown above. In other cases, also reject common typos, such as "km" for "kg" or similar.
This process of warning users is still new, so expect some unusual cases which might require re-thinking of tactics. Using a #switch is extremely fast, even for rejecting 30 or 100 invalid units, and the internal MediaWiki post-expand size of the templates (with #switch warnings) will remain small (after the January 2008 upgrade to the streamlined preprocessor which omits unmatched #switch branches). None of that invalid-unit #switch will be formatted into articles, unless a conversion actually uses one of those invalid units. I will add this information into HELP:Convert. -Wikid77 05:38, 10 January 2011 (UTC)

Is the 'dream' goal of this that the conversion performs dimensional analysis and rejects all inter-dimensional conversions, but accepts all conversions with correct dimensions? How would you ideally like to handle compound units with the same dimensions (eg converting megawatt-hours to foot-pounds)? Happy‑melon 12:30, 10 January 2011 (UTC)

Switches are still very "expensive" in terms of template limits. It'll also be pretty time-consuming to implement them all around. How about just targeting only the more common errors? JIMp _talk·cont 23:32, 10 January 2011 (UTC)

Remind me again why we can't just make sure the input conversion template is producing a number in units expected by the output conversion template? For example, all the length templates appear to use meters as the intermediate unit. I could be missing something, since I have only looked at a small subset of the templates. Plastikspork _―Œ^(talk) 23:10, 11 January 2011 (UTC)

• If the focus is only to reject an incorrect unit and not recommend a better unit, we could, instead, redesign Convert and put a dimensionality parameter (perhaps "{{{dimcode}}}" set to "L" for length) in many of the Convert-unit subtemplates (such as inside {Convert/ft} and many others), while defaulting to "don't reject" if {{{dimcode}}} is not set. However, that method would simply reject "kg" with miles (and not suggest "km") or reject "sqft" with g/cm but not mention to try "lb/sqft". Also, that method would then require modifying many of the {Convert/<unit>} subtemplates and some intermediate templates: if ever one of any 2 units did not have {{{dimcode}}} set, then no check for dimensionality would be possible. However, long term, that probably is the best method for spotting a unit mismatch; yet, meanwhile, we can use #switch checks to quickly warn of problems for each specific unit (and suggest "not kg, try km"), by changing just 1 subtemplate to handle 5 or more problems, rather than set {{{dimcode}}} in 5 or more subtemplates and all the intermediate supporting subtemplates.
  At this point, the mental gymnastics are easier when using a #switch to warn of problems with one specific unit, plus all the logic (for proofreading the warnings and/or debugging, or explaining to new users) is in that one #switch, rather than spread across a "hive mind" effect of the {{{dimcode}}} parameters being passed and then rejected in various intermediate subtemplates. The #switch is just much, much simpler, right now, in the midst of making numerous other improvements, such as {{Getprecision}} & {{Rndpad}}, which solve bigger, major problems about precision and expansion depth. -Wikid77 18:03, 15 January 2011 (UTC)

I don't oppose using these switches here and there as long as they're not too big. If the aim is to have a large number of units included in each switch and/or to have a large number of these switches deployed, then something along the lines of a {{{dimcode}}} would be better. However, I don't see it as necessary. Let's target the errors that we'd expect to find (like lb for pounds force or oz for US fluid ounces). There are bigger fish to fry in this template. JIMp _talk·cont 14:21, 16 January 2011 (UTC)

Am/Brit spelling

Spelling of SI units seems to default to British, i.e., metre instead of meter. Shouldn't this somehow be adjusted for location?

You can adjust it using sp=us. There is no way of adjusting according to the location of the reader (currently on WP). JIMp _talk·cont 04:18, 17 January 2011 (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)

• USE: abbr=mos. Currently, the option "abbr=mos" (meaning the "WP:MOS" Manual of Style) inserts "&nbsp;" (as &#160;) 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&#160;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)

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)

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&nbsp;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)

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)

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)

• 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. That's what I remember so far. -Wikid77 (talk) 14:59, 19 November 2010 (UTC)

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)

Linking "thousand" and "million"

There has recently been made an edit such that the words "thousand" and "million" are linked (e.g. 123 thousand cubic metres (4.3×10^⁶ cu ft) and 123 million cubic metres (4.3×10^⁹ cu ft)) when using the e3* and e6* unit codes. Do we want to link to these common words? Is this not overlinking? It is, of course, consistant with the linking of "billion" and "trillion" (e.g. 123 billion cubic metres (4.3×10^¹² cu ft) and 123 trillion cubic metres (4.3×10^¹⁵ cu ft)), however, these words are ambiguous (a billion was originally defined as a million million but this template uses the American billion of a thousand million). "Billion", "trillion", etc. are linked to help aviod this ambiguity. "Thousand" and "million" are unambiguous, let's unlink them. JIMp _talk·cont 03:11, 13 March 2011 (UTC)

• Yes, I agree to unlink them, and I see your point: if "million cubic feet" is linked, plus "million miles" is linked, and "million pounds" is linked, then the word "million" could become overlinked as 3 nearby instances, while each of the unit names is linked only once. -Wikid77 05:39, 13 March 2011 (UTC)

convert/3 should accept other separators

I need to list three diameters. See this edit.

With four diameters, I could use this: {{convert/4|18|,|28.5|,|46|and|99|inch|m}} to give:

{{convert/4|18|, |28.5|, |46| and |99|inch|m}}

However {{convert/3|18|,|28.5|and|46|inch|m}} gives an error:

{{convert/3|18|, |28.5| and |46|inch|m}}

This is because convert/3(but not convert/4) restricts the first delimiter to a short list of options.

This behaviour is unhelpful and I can see no useful reason for it. If it is to be restricted like this, it should certainly allow the use of a comma as a commonplace list delimiter. Andy Dingley (talk) 23:14, 13 March 2011 (UTC)

• DONE: I agree, and I think others will as well, since the excessive restriction had been noted before. There is an installed fix, from sandbox version Template:Convert/3/sandbox:
    • {{convert/3 |11|, or|12|up to|19|m}} → {{convert/3|11|, or |12|up to|19|m}}
  As there were no other issues, then I will submitted an edit-protected request to remove the prior restrictions about the separators. -Wikid77 21:31, revised 03:23, 16 March 2011 (UTC)