Jump to content

Template talk:Convert/Archive August 2013

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


template loop when trying to do convert dimensions with fractions

At DECtape#DECtape II I'm trying to convert 2 3/8" × 3 3/16" × 1/2" into mm. As far as I can make out the syntax should be:

{{convert|2+3/8|x|3+3/16|x|1/2|in|mm}}

But that gives an error of: "Template loop detected: Template:Convert/x". It would seem odd that nobody has needed to do this before, so I'm guessing I'm wrong somewhere? Thryduulf (talk) 19:20, 19 July 2013 (UTC)

the problem isn't just with fractions, you will see the same thing if you try decimals. for now, use {{convert/3|2+3/8|x|3+3/16|x|1/2|in|mm}} Frietjes (talk) 20:03, 19 July 2013 (UTC)
Thank you. Thryduulf (talk) 22:32, 19 July 2013 (UTC)
The problem is with 3D. The template can't handle 3D (yet). This is one thing we should aim at including in any new version (i.e. Lua probably). It would be nice to add it before the new version. It might not be too hard but it might just be easier to use {{convert/3}} (as Frietjes suggests) in the meantime. Jimp 05:19, 22 July 2013 (UTC)

I've finished fixing ranges, so the following now work:

  • {{convert/sandboxlua|2+3/8|x|3+3/16|x|1/2|in|mm}} → 2+3⁄8 by 3+3⁄16 by 1⁄2 inch (60 mm × 81 mm × 13 mm)
  • {{convert/sandboxlua|2+3/8|xx|3+3/16|xx|1/2|in|mm}} → 2+3⁄8 × 3+3⁄16 × 1⁄2 inch (60 × 81 × 13 mm)
  • {{convert/sandboxlua|2+3/8|*|3+3/16|*|1/2|in|mm}} → 2+3⁄8×3+3⁄16×1⁄2 inch (60×81×13 mm)

I wanted consistency with {{convert|1|x|2|m}}, so x gives "by" when not abbreviated, and xx gives " × ", and * gives "×" without spacing. Only certain text like "or" and "," is allowed between numbers, but you can go crazy with the quantity:

  • {{convert/sandboxlua|1|*|2|*|3|to|4|*|5|*|6|in|mm}} → 1×2×3 to 4×5×6 inches (25×51×76 to 102×127×152 mm)

Johnuniq (talk) 05:10, 6 August 2013 (UTC)

Unprotect Convert/out2

There is an old (protected) subtemplate, Template:Convert/out2, which should be unprotected and rewritten as the 2-unit form of {convert/dual}. Then, the new Template:Convert/out3 would be used for the 3-unit form of mixing any three output units as an instant combination, extending {convert/dual} to 3 units at once. -Wikid77 (talk) 20:10, 1 August 2013 (UTC)

New Convert/dual customizes any 2-unit output

The new Template:Convert/dual allows mix-and-match of any 2 units as the result of a conversion, but also allows the custom-formatting options of {{Convert/f}}. Previously, a special subtemplate had to be created for each combination of dual outputs, but {convert/dual} instantly allows mixing any 2 output units:

  • {{convert/dual |99|km|mi|cm}}       → {{convert/dual |99|km|mi|cm}}
  • {{convert/dual |99|km|mi|in|sep= or}} → {{convert/dual |99|km|mi|in|sep= or}}

So, {convert/dual} will simplify unit combinations in flow problems, plus allow rounding to "near=50" or inserting 2 tildes "~" by "|x3=~|x6=~" such as:

  • {{convert/dual |30|USgal/min|impgal/min|L/hr |abbr=on}} → {{convert/dual |30|USgal/min|impgal/min|L/hr |abbr=on}}
  • {{convert/dual |30|USgal/min|impgal/min|L/min|abbr=on}} → {{convert/dual |30|USgal/min|impgal/min|L/min|abbr=on}}
  • {{convert/dual |30|USgal/min|impgal/min|L/min|abbr=on|near=50}} → {{convert/dual |30|USgal/min|impgal/min|L/min|abbr=on|near=50}}
  • {{convert/dual |30|USgal/min|impgal/min|L/min|x3=~|x6=~|near=50}} → {{convert/dual |30|USgal/min|impgal/min|L/min|x3=~|x6=~|near=50}}

Previously, a set of 7 related units would have required 1,440 subtemplates to be created to handle any combination of 2 of those 7 units (formula: 2×(n-1)! combinations). See: Template:Convert/dual for more options and use of the other pre/post-text parameters x1-x8. -Wikid77 13:33, 1 August 2013 (UTC)

Could you add 6.5 imperial pints (3.7 L; 7.8 US pt) for Welbike#Development? For now only 6.5 imperial pints (3.7 L) works. Peter Horn User talk 18:31, 8 August 2013 (UTC)

Angstroms

What is wrong with this?

1.1 to 1.8 ångströms (4.3×10−9 to 7.1×10−9 in)

Hawkeye7 (talk) 03:39, 8 August 2013 (UTC)

"to" is not a unit of length. Try something like
{{convert|1.1|m|Å}}, which yields
1.1 metres (1.1×1010 Å)
to convert 1.1 meters into Angstroms.
My name is Mercy11, and I approve this message. 03:51, 8 August 2013 (UTC)
Mercy11 (talk) 06:42, 8 August 2013 (UTC)
This doesn't explain why 1.1 to 1.8 inches (28 to 46 mm) works? Plastikspork ―Œ(talk) 04:20, 8 August 2013 (UTC)
Also strange that 0.00000000011 to 0.00000000018 metres (4.3×10−9 in to 7.1×10−9 in) works but 0.00000011 to 0.00000018 centimetres (4.3×10−8 to 7.1×10−8 in) doesn't currently work. Plastikspork ―Œ(talk) 04:35, 8 August 2013 (UTC)

I wonder if the issue is related to #Formatting fractions above. Jimp recently changed the way fractions are formatted, and that involved tweaking span elements, so something might have gone wrong. For the record, here are the results from Module:Convert (under development):

  • {{convert/sandboxlua|1.1|to|1.8|Å}} → 1.1 to 1.8 ångströms (4.3×10−9 to 7.1×10−9 in)
  • {{convert/sandboxlua|0.00000000011|to|0.00000000018|m}} → 0.00000000011 to 0.00000000018 metres (4.3×10−9 in to 7.1×10−9 in)
  • {{convert/sandboxlua|0.00000011|to|0.00000018|cm}} → 0.00000011 to 0.00000018 centimetres (4.3×10−8 to 7.1×10−8 in)

Johnuniq (talk) 04:56, 8 August 2013 (UTC)

Good grief, how did I think this was related to fractions? My mind was distracted because I know that the scientific notation in the output uses spans. It's a bit more than scientific notation:
  • {{convert|1,123,000|to|1,345,000|Å}} → 1,123,000 to 1,345,000 ångströms (0.00442 to 0.00530 in)
  • {{convert/sandboxlua|1,123,000|to|1,345,000|Å}} → 1,123,000 to 1,345,000 ångströms (0.00442 to 0.00530 in)
Johnuniq (talk) 05:04, 8 August 2013 (UTC)
until it is fixed, I would suggest using {{convert/2|1.1|to|1.8|Å}}. 64.134.62.81 (talk) 14:20, 8 August 2013 (UTC)
Will do! Thanks very much for your help folks. Hawkeye7 (talk) 23:52, 8 August 2013 (UTC)

Please convert inconsistent formatting: Convert/dam2

Please change the display formatting of {{Convert/dam2}} from dam² to dam<sup>2</sup> to match the other units like km2, mm2 etc.: consistency and WP:MOS#Units of measurement demand this. Being protected, I cannot make this simple change myself. — Quondum 03:12, 23 July 2013 (UTC)

Er... this request seems to have escaped attention. — Quondum 16:41, 10 August 2013 (UTC)
@Quondum: did you try 1 dam2 (1,100 square feet)? checking the html source, it already uses sup markup. perhaps you are thinking of another template? Frietjes (talk) 16:50, 10 August 2013 (UTC)
My apologies: I see what you're saying. I see Jimp implemented my request – my choice of font hides the distinction. — Quondum 16:59, 10 August 2013 (UTC)

Another dual

For Wildland fire tender 300 US gal/min (250 imp gal/min; 19 L/s) instead of 300 US gal/min (19 L/s). Peter Horn User talk 21:41, 25 July 2013 (UTC)

Or/and 300 US gal/min (250 imp gal/min; 1.1 m3/min) instead of 300 US gal/min (1.1 m3/min) Peter Horn User talk 21:45, 25 July 2013 (UTC)
As well as for User:Peter Horn/Sandbox.4#Fire Engine Peter Horn User talk 00:35, 28 July 2013 (UTC)
Thanks a million. Peter Horn User talk 20:36, 28 July 2013 (UTC)
  • Combine 2 conversions with disp=x and disp=out: In general, just mix-and-match any combinations of output amounts, using disp=x then disp=out:
  • {convert|300|USgal/min|impgal/min|abbr=on|disp=x| (|; }}{
    convert|300|USgal/min|L/s|disp=out }}) → 300 US gal/min (250 imp gal/min; 19 L/s)
That allows unlimited combinations of output units. -Wikid77 (talk) 11:53, 31 July 2013 (UTC)
Could you add 6.5 imperial pints (3.7 L; 7.8 US pt) for Welbike#Development? For now only 6.5 imperial pints (3.7 L) works. Peter Horn User talk 20:44, 8 August 2013 (UTC)
Thanks, and for SkyTran, 200 miles per gallon, say 200 miles per US gallon to miles per imperial gallon and L/100 km. Peter Horn User talk 20:16, 9 August 2013 (UTC)
That unit exists: {{convert|200|mpgus|mpgimp L/100 km}} → 200 miles per US gallon (240 mpg‑imp; 1.2 L/100 km) Johnuniq (talk) 01:13, 10 August 2013 (UTC)

Costs per unit distance

For SkyTran, how would one convert US$ per mile to US$/km? Peter Horn User talk 20:28, 9 August 2013 (UTC)

I believe the only related units are for cost per unit area and cost per unit mass ($/acre, $/kg etc.), so converts for cost per unit length would need to be created. The convert templates (I think) do not attempt to specify "US$"—the options are purely "$" and "£". As I'm wanting to introduce the module, I added $/mi and $/km in this edit which gives these examples:
  • {{convert/sandboxlua|12|$/mi}} → $12 per mile ($7.5/km)
  • {{convert/sandboxlua|12|$/km}} → $12 per kilometre ($19/mi)
  • {{convert/sandboxlua|12.00|$/km|abbr=off|sp=us|lk=on|disp=flip|2}} → $19.31 per mile ($12.00 per kilometer)
The last example is just to show that defining a unit can be quite simple (although it looks like magic in this "per" case), yet the standard options should work. Johnuniq (talk) 01:03, 10 August 2013 (UTC)
{{convert|100,000,000|$/mi}} → $100,000,000 per mile ($62,000,000/km)
{{convert/sandboxlua|100,000,000|$/mi}} → $100,000,000 per mile ($62,000,000/km)
for SkyTran, you probably want to convert million US$ per mile to million US$/km. a better solution would be to have a generic /km and /mi conversion with the ability to add more free form units for the numerator. Frietjes (talk) 16:17, 10 August 2013 (UTC)
{{convert|100|e6$/mi}} → $100 million per mile ($62,000,000/km)
{{convert|100|e6$/mi|abbr=none}} → $100 million per mile ($62,000,000 per kilometre)
{{convert|100|e6$/mi|abbr=on}} → $100×10^6/mi ($62,000,000/km)
Frietjes (talk) 16:27, 10 August 2013 (UTC)

Abbreviation markup

This template should use abbreviation markup. For instance, where the output is:

186 centimetres (73 in) high

then the markup should include:

(73 <abbr title="inches">in</abbr>)

Can we do this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 6 August 2013 (UTC)

  • {{convert|186|cm|in|abbr=off}} gives 186 centimetres (73 inches), default case
  • {{convert|186|cm|in|abbr=on}} gives 186 cm (73 in)
  • {{convert|186|cm|in|abbr=in}} gives 186 cm (73 inches)
  • {{convert|186|cm|in|abbr=out}} gives 186 centimetres (73 in)  Stepho  talk  22:11, 6 August 2013 (UTC)
Indeed - but that has nothing to do with my question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:21, 6 August 2013 (UTC)
Could you rephrase you question please - it's not very clear what you want.  Stepho  talk  22:37, 6 August 2013 (UTC)

Here is what that would look like (I created "ina" for the experimental Module:Convert as a quick experiment):

  • {{subst:convert/sandboxlua|186|cm|ina}} → 186 centimetres (73 in)

It's nice, but a bit much to do it for every unit IMHO. I suppose there could be an option to generate the extra markup, although the syntax is already sufficiently complex. Johnuniq (talk) 22:50, 6 August 2013 (UTC)

I should have mentioned that the standard method convert offers to explain what something like "in" means is to link it:
  • {{convert|186|cm|in|lk=on}} → 186 centimetres (73 in)
  • {{convert|186|cm|in|lk=out}} → 186 centimetres (73 in)
Johnuniq (talk) 23:25, 6 August 2013 (UTC)
That also includes a link, which is often not wanted; and even linked abbreviations should be marked up as such, per HTML standards and WCAG. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:07, 7 August 2013 (UTC)
Why would it be "a bit much"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:07, 7 August 2013 (UTC)
I don't feel strongly about the issue, but there are lots of articles where many conversions are used, and IMHO it would be distracting for every mention of an abbreviated unit to be underlined. It's like the old date linking wars—some liked the links and some didn't. Also, while having "inches" popup when hovering the mouse over "in" would be occasionally useful, there are lots of other units (a nearly complete list is here) where showing the unit name when hovering may not help—if a reader does not know what "BTU" is, would showing the name really help when the link provides useful content? Are you proposing that every abbreviated unit (symbol) would always have the abbreviation markup? My "bit much" about that is just a feeling regarding clutter. I might wait for others to comment. Johnuniq (talk) 00:24, 8 August 2013 (UTC)
Frankly, as a screen reader user (for whom the abbr tag can be useful, I don't think adding it to this template would be helpful at all. For common units (in, ft, m), screen reader users (like all people) would commonly encounter the abbreviation, and the objections to using it on more obscure units have already been covered above. Graham87 06:46, 8 August 2013 (UTC)
Not all of you readers are like you (and me), with a Commonwealth culture and understanding of "in" and "ft". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 8 August 2013 (UTC)
Underling can be avoided with judicious use of CSS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 8 August 2013 (UTC)

I have inserted subst: into the above convert that uses "ina" to freeze the result as it was at the time of this comment. It was just a temporary experiment (which can be seen in this permalink), and I will remove it soon. Johnuniq (talk) 04:56, 14 August 2013 (UTC)

missing templates

There is are missing templates (Template:Convert/LoffAoutDflipSmid and Template:Convert/LoffAinDflipSmid) when using a mid adjective, flipped display and have the abbr parameter set to "in" or "out":

  • {{convert|0.13|mm|in|adj=mid|-thick|abbr=out|disp=flip}} → 0.0051-inch-thick (0.13 mm)
  • {{convert|0.13|mm|in|adj=mid|-thick|abbr=in|disp=flip}} → 0.0051 in-thick (0.13-millimetre)

Thryduulf (talk) 21:21, 15 August 2013 (UTC)

  • {{convert|0.13|mm|in|abbr=out|disp=flip}} → 0.0051 inches (0.13 mm)
  • {{convert|0.13|mm|in|abbr=in|disp=flip}} → 0.0051 in (0.13 millimetres)
  • {{convert|0.13|mm|in|abbr=out|adj=mid|-thick}} → 0.13-millimetre-thick (0.0051 in)
  • {{convert|0.13|mm|in|abbr=in|adj=mid|-thick}} → 0.13 mm-thick (0.0051-inch)
should work now, but you should double check. for consistency, I added some variations above. Frietjes (talk) 22:48, 15 August 2013 (UTC)
  • {{convert|0.13|mm|in|adj=mid|-thick|abbr=on|disp=flip}} → 0.0051 in-thick (0.13 mm)
  • {{convert|0.13|mm|in|adj=mid|-thick|abbr=on}} → 0.13 mm-thick (0.0051 in)
for some reason, we don't currently have the additional hyphen for abbr=on? Frietjes (talk) 22:52, 15 August 2013 (UTC)
Thank you. Thryduulf (talk) 07:51, 16 August 2013 (UTC)

abbr=in, adj=mid and disp=flip removing space before conversion

Compare the conversions below:

  • first {{convert|0.13|mm|in|adj=mid|-thick|abbr=in}} → first 0.13 mm-thick (0.0051-inch)
  • second {{convert|0.13|mm|in|adj=mid|-thick|abbr=in|disp=flip}} → second 0.0051 in-thick (0.13-millimetre)

I've seen this only when all of mid adjectives, abbreviations and disp=flip are specified, but that might just be my limited testing. Thryduulf (talk) 10:48, 16 August 2013 (UTC)

fixed, there was a typo in the templates I created in response to your previous request. the missing space was actually due to a hidden error message indicating bad rounding parameters, but this fixed it. thank you. Frietjes (talk) 15:33, 16 August 2013 (UTC)

New Convert/flip with comma/near/midtext

For years, we have discussed some type of upgrade to display flipped results, but also allow "disp=or" without needing "disp=flip" plus enable comma formatting, rounding to nearest 25 units, inserting mid-text between any numbers and units, and rounding either the input or the output amount. New Template:Convert/flip finally provides all those capabilities, as an extension of Template:Convert/f, which already handled comma=out, near=25 or "x1=exact" to insert word "exact" after the amount. Examples:

Now, the amount can be flipped while also using any other options. Previously, there had been too many various options, with people asking for many more new features, and "disp=flip" was requiring hundreds of subtemplates to handle all the combinations of prior options. Instead, by using {convert/flip} for rare options, then the "disp=flip" format can be reduced to only the simplest of options. Now, we can continue to provide new features for {Convert}, every week, without the overhead of creating over 750 Convert subtemplates for every new option. Currently, the non-abbreviated units, such as "acre" have caused non-plural results, but I will check for them:

Otherwise, we would need to tell people to use a {convert/flipNa} when the plural for a unit name shows "acre" for acres. The "-Na" suffix did not stop the problem in other templates with acres, it just hid the trouble of needing to check for undefined "{{{u}}}". -Wikid77 (talk) 21:31, 23 June, 09:42, 25 June 2013 (UTC)

  • Expanding Convert/flip for spell: The next step, to allow more options, would be to expand Template:Convert/flip to spell amounts, although the usage would be very rare. Some combinations of options are almost never used, such as a rare 3-amount conversion never spelled in words because 3 numerals would be easier to read than three numeric phrases. Possibly, the option "fmt=spell" could be added. -Wikid77 09:00, 8 July, 23:54, 18 July 2013 (UTC)
  • Using Convert/flip with disp=tablecen: Now, {convert/flip} also allows the options for "disp=table" or "disp=tablecen":
That allows option x3=~ to show a tilde with the original amount. -Wikid77 06:36, 20 August 2013 (UTC)

@Wikid77: Fixing problems that arise in the templates is very helpful, but you seem to be planning significant enhancements. Are you sure that the module is not suitable for a drop-in replacement, so working on the templates may not be warranted? Most issues raised on this page in the last couple of months already worked in the module. I have recently added spelling to the module (I've been working on it for a week, but only uploaded it a few hours ago). I have changed Module:ConvertNumeric (which implements {{spellnum}}) to spell fractions, and enhanced Module:Convert to call ConvertNumeric for spelling. I decided to not bother with tricky spelling features that are not currently used in articles, so the module only supports spelling the input, although it works with disp=flip (but not when the flipped output is a multiple such as ftin). I decided to use a syntax that is simple to decode, namely spell=in or spell=In (uppercase I makes the first letter of the spelled words uppercase). Examples:

  • {{convert/sandboxlua|1/2|in|mm|spell=in}} → one-half inch (13 mm)
  • {{convert/sandboxlua|2+1/2|in|mm|spell=in}} → two and a half inches (64 mm)
  • {{convert/sandboxlua|2|yd|1|ft|3|in|mm|spell=In}} → Two yards one foot three inches (2,210 mm)
  • {{convert/sandboxlua|13|mi|km|disp=flip|spell=In}} → Twenty-one kilometres (13 mi)

A general solution would be very difficult ("one half mile" vs. "a half mile", and lots more), and I do not know whether simple fractions should be hyphenated as done by {{convert/spell}}. See the spelling testcases for some differences between the template and the module.

I'm not proposing that the module be used to replace the templates at the moment because I'm still working on stuff, and it would not be desirable for me to continue major refactoring on a live module. Apart from fiddling, I'm planning a couple of things to make use of the module at other Wikipedias easier. The module works at the Bengali Wikipedia: see bn:User:Johnuniq/convert tests which uses English digits for input, and here for the same, but with Bengali digits. I have to update the unit definitions so, for example, "কিলোমিটার" is displayed rather than "kilometre", but that should be reasonably straight forward. The module handles non-English decimal marks and group separators. That is controlled with some options in the template invoking the module so I would have to make another template to demonstrate. I might do that later, but meanwhile here is a demo of comma=gaps which uses the span technique of {{gaps}}:

  • {{convert/sandboxlua|123,456,789.1|mm|m|comma=gaps}} → 123456789.1 millimetres (123456.7891 m)

Some help investigating testcase differences would be appreciated—see the list at Template:Convert/testcases. Fixing the templates to consistently handle all the complex features would be a major undertaking. For example, there are several problems in the options tests: here and here, and some other issues I've noticed are here. Johnuniq (talk) 04:43, 19 July 2013 (UTC)

"cuerda" conversion

Could someone expand this template to include the Spanish unit of area measurement "cuerda", where 1 cuerda = 0.97122191 acre (See HERE). This unit (also known as "the Spanish acre") is used extensively in Puerto Rico (See HERE). It is used exclusively as the standard unit of area measurement to measure the area of properties (such as land surveying, etc), in legal transactions and real estate sales (See HERE), and in official government filings for property titles in the U.S. Commonwealth of Puerto Rico (See HERE). Thanks, My name is Mercy11, and I approve this message. 02:20, 8 August 2013 (UTC) Mercy11 (talk) 06:42, 8 August 2013 (UTC)

The Russ Rowlett reference you gave lists 3.5 different meanings for cuerda: area ≈ 3930 square meters in Puerto Rico; length ≈ 21 meters in Guatemala; area = square of that length; volume ≈ 2.87 cubic meters in Cuba. Metrication in Guatemala lists other variations. It's not clear what would be the best way to handle a traditional unit like that. Searching articles for area cuerda shows several hits where the convert template could be used, but I do not know if there is a "standard" cuerda that should be chosen. Is the 0.97122191 value somehow official? Johnuniq (talk) 10:53, 8 August 2013 (UTC)
Here are my comments to your notes above:
(1)"lists 3.5 different meanings for cuerda"... >>>> There are perhaps two ways to handle this:
(a)Just define it for Puerto Rico for now and leave the lesser-used Guatemalan and Cuban meanings for later (as time permits), since 17 of 54 (i.e., one-third) Wiki articles HERE refer to the Puerto Rican cuerda, with only 1 referring to the Guatemala cuerda and the rest referring to non-measurement uses of "cuerda" such as Cuerda as a surname and to cuerdas ("cords") as in musical instruments)
(b)Define all three now, along the following lines (note: the Template formats below are for reference/identification/illustration purposes only and are not intended to depict actual Convert template nomenclatures! ):
{{Template:Convert [Cuerda (Puerto Rico)|Puerto Rican Cuerda] to acres}} (1 cuerda = 0.97122191 acre)
Yielding a code format similar to {{convert|x|PUEc|acre}}
{{Template:Convert [Cuerda (Guatemala)|Guatemalan Cuerda] to meters}} (1 cuerda = 21 meters)
Yielding a code format similar to {{convert|x|GUAc|meter}}
{{Template:Covert [Cuerda (Cuba)|Cuban Cuerda] to cubic meters}} (1 cuerda = 2.87 cubic meters)
Yielding a code format similar to {{convert|x|CUBc|m3}}
(2)"I do not know if there is a "standard" cuerda that should be chosen" >>>>> If by "standard" you mean "official", then there appear to be the 3 (PR, GUATEMALA, CUBA). If by standard you mean "the most widely used", then it seems that woul be Puerto Rico.
(3)"Is the 0.97122191 value somehow official?" >>>> THIS document from the Puerto Rico Planning Board (the state wide government regulatory agency in these matters) defines an acre in terms of cuerdas ([Page 4, #18] "Acre - Medida de terreno equivalente a 1.0296 cuerdas..." [English: "Acre - A unit of land measurement equivalent to 1.0296 cuerdas..."])
Do we need to research more? If so, what? Mercy11 (talk) 14:31, 8 August 2013 (UTC)

As for "official", THIS document from the U.S. Federal Government, under "1815", shows the ratio of cuerdas to acres as 200-to-198, or 100-to-99, which is consistent with the ratio 1-to-0.97 that you inquired about. Regards, Mercy11 (talk) 13:34, 14 August 2013 (UTC)

Does the US provides official conversions for measurements in Spain, Puerto Rico, Guatemalan and Cuba? Also, the conversion factor is just a passing reference rather than a true definition.  Stepho  talk  22:07, 14 August 2013 (UTC)
I did not mean to imply that the "passing" reference above was "official" or that it was an "official definition". My apologies for the poorly drafted comment which may have led to misunderstanding. My intention was to show that the 1-to-0.97 ratio is used (1)in an official manner by (2)official entities. Above, for example, it is being used in an official manner (i.e., stating that the Spanish Crown -officially- gave 200 cuerdas to settlers of Puerto Rico, and stating -officially- that 200 cuerdas equates to 198 acres) and by an official entity (i.e., the Forest Service of the United States Department of Agriculture). While this may not be the official definition that we all would like to see, my point is that the 1-to-0.97 is the conventional, standard and universally agreed-upon conversion ratio used by everyone involved in the sale or purchase of land or real estate in Puerto Rico - from the Commonwealth/Federal Courts, the Commonwealth/Federal Government, and the Legislature and the US Congress (see, for example, HERE) to the residents and citizens, the realtors, the attorneys, and the title companies, etc. Regards, Mercy11 (talk) 01:43, 15 August 2013 (UTC)

Request for Inclusion of "Cuerda"

Here is the official definition of the Puerto Rican cuerda. According to [Puerto Rico] Act 135, section 4 (page 100), 1913–14, as amended by Act No. 3, 1913–14: a cuerda (Abbreviation, "cda"), "[i]n land measurements and records[, is] the measurement...customarily used in Porto [sic] Rico...equivalent to 3,930.395625 square meters... [i.e.,] a unit of land area, approximately 3,930 square meters (approximately 0.971 acres)."(From: HERE) Note that according to the site this definition was submitted by the Government of Puerto Rico to the United Nations "in the 1950s" (which is consistent with the time when Puerto Rico became a Commonwealth.)

For reference, (from Wikipedia's Convert function) we know that the following two are equivalent: 1.0 acre (4,046.856422 m2)

Since 1 cuerda = 3,930.395625 m2, and since 1 acre = 4,046.856422 m2, it then follows that 1 cda = (3,930.395625 m2) x (1.0 acre/4,046.856422 m2) = 0.971222 acres, which is the same as the conversion ratio previously proposed above.

Thanks, Mercy11 (talk) 00:26, 16 August 2013 (UTC)

The request was fulfilled by User:Wikid77 - and it works great!!! See it working at Toro Negro State Forest.
Thanks Wikid77! Mercy11 (talk) 22:43, 20 August 2013 (UTC)

disp=table5

It would be really ideal for me if the options disp=5 and disp=flip5 could be extended out to cover tables in something like disp=tableflip5 as i am currently trying to rework a list article that needs to convert from km/h to mph but display km/h first.Jason Rees (talk) 03:19, 15 August 2013 (UTC)

  • Using Convert/flip with disp=tablecen: Now, {convert/flip} also allows the options for "disp=table" or "disp=tablecen":
That allows option x3=~ to show a tilde with the original amount. -Wikid77 06:36, 20 August 2013 (UTC)
What would really be ideal is if disp=5 and disp=flip were abolished altogether in favour of something like near=5 as a rounding option and something like order=flip leaving disp to handle true display options like tables, or, etc. and allowing combos like this to be created easily by the user. Jimp 04:18, 15 August 2013 (UTC)
I made this edit to the module to try those suggestions. Since the options were already defined, it was an easy edit. For anyone interested, the first line inserted in the diff is ["near"] = "near"—that allows translation for use at another wiki (the LHS is the text in the local language as would be used in a template, and the RHS is the word used in the module). Similarly, in the ["flip"] = "opt_flip" line, the LHS is in the local language, and the RHS is the word used in the module. Here is a demo:
  • {{convert/sandboxlua|123|mph|km/h}} → 123 miles per hour (198 km/h)
  • {{convert/sandboxlua|123|mph|km/h|near=5}} → 123 miles per hour (198 km/h)*
  • {{convert/sandboxlua|123|mph|km/h|order=flip}} → 198 kilometres per hour (123 mph)
  • {{convert/sandboxlua|123|mph|km/h|order=flip|near=5}} → 198 kilometres per hour (123 mph)*
Convert Speed
km/h mph
{{convert/sandboxlua|199|mph|km/h|order=flip|near=5|disp=tablecen}} 320 199*
{{convert/sandboxlua|123|mph|km/h|order=flip|near=5|disp=tablecen}} 198 123*
{{convert/sandboxlua|89|mph|km/h|order=flip|near=5|disp=tablecen}} 143 89*
Johnuniq (talk) 08:01, 15 August 2013 (UTC)
Great. To do it with the current subtemplate structure would have been prohibitively time consuming. Jimp 09:45, 15 August 2013 (UTC)
Can we get this added to the convert template or at least make the coding smaller than {{convert/sandboxlua|89|mph|km/h|order=flip|near=5|disp=tablecen}}.Jason Rees (talk) 14:50, 17 August 2013 (UTC)
There are over 2800 templates in the convert family, so adding anything is not easy. In general, a rethink of the options would be very desirable, but it's tricky. In the module, it would be trivial to add, for example, disp=tcf5 to mean "table centered, flipped, round to nearest 5", but that would encourage other similar contractions, and would make wikitext impossible to read. Nevertheless, if tcf5 was used in hundreds of articles, such a contraction may be worthwhile. It would also be possible to make a template so articles could have, for example, {{cvt tcf5|89|mph|km/h}}, and that template would pass the required parameters. However, that again would only be useful if the wikitext is needed in lots of places. Johnuniq (talk) 11:22, 19 August 2013 (UTC)

I doubt that tcf5 would be used frequently enough to warrant making such a thing. Moreover, my opinion of the matter is that we'd be better off moving away from the current situation wherein there is no clear sense of what the parameters actually control. For example, disp originally controlled only how the conversion was displayed (not rounding nor order) and adj controlled whether the phrase was in noun or adjective form (it didn't add text). The template evolved like this because of its internal structure but now that we've go the opportunity to restructure why not return to the clear-cut style of specific parameters for specific functions? Jimp 04:13, 20 August 2013 (UTC)

We still need to limit complex interactions between parameters, or we will depend on an enormous Luasaurus gigantus not unlike the "giant switch" forms of Convert which would reformat all "million" pages for any small change. At some point, people need to write their own specialized helper templates used in 2 or 3 articles. Currently, we have a system where about 45 templates can provide minimal Convert in any other-language Wikipedia, and they could add another template for each new unit-code. Then, Template:Convert/dual would allow any 2 output units for a related input unit. -Wikid77 06:36, 20 August 2013 (UTC)
  • Using Convert/flip with disp=tablecen: Again, note how {convert/flip} also allows the options for "disp=table" or "disp=tablecen":
That allows option x3=~ to show a tilde with the initial amount. -Wikid77 06:36, 20 August 2013 (UTC)
I agree with Jimp's comment above. However, working out a clean syntax that is also helpful is not easy. Anything which adds readability to the wikitext may reduce its usability by making the text too long. A good summary of all the options is seen in the table following the first occurrence of "en_option_value" at Module:Convert/text, and if I ever have a clear mind I'll think about some alternatives. Ideas welcome! And, if there are any options which need to be supported for compatibility, it would be good if they could be identified because one defect of the module is that there is no way to find an unimplemented option—if the module replaced the templates, we would just have to wait for reports of problems. I'm getting on a bit of a sidetrack, but now I've mentioned that I should say that there is a global option to issue warnings for unknown or invalid options. I have a feeling that if that were ever turned on, it would rapidly fill Category:Convert invalid option (by the way, the category names are defined in Module:Convert/text).
Wikid77's comment about specialized helper templates is a good idea, and is the kind of thing I had in mind with a "cvt tcf5" template. Re translations: the module should be very helpful for that. See bn:User:Johnuniq/Translation#Translation results for some baffling results. We haven't tried to translate the input options yet, but that should be reasonably straightforward, involving edits to bn:Module:Convert/text, where you can see that digit and SI prefix translations have been implemented. Johnuniq (talk) 07:41, 20 August 2013 (UTC)

It may be possible to track down and remove the invalid options (or at least most of them) by bot before the switch to a module version. Jimp 09:11, 20 August 2013 (UTC)

Controlling line breaks

Hi, FYI, the "disp=br" parameter does not work in the following case (I know that the docs say "Parameters still under construction. May not work in all situations"; not sure if you know about this one)

360–362 m
1,181–1,188 ft

Also, assuming it works at all, is there any way to force the line break but still preserve the brackets? For example, have {{convert|360|m|abbr=on|disp=br}} display as:

360 m
(1,180 ft)

86.160.217.67 (talk) 20:58, 18 August 2013 (UTC)

  • FIXED. Option "disp=br" works, but use "disp=x|<br>(|)" to retain the curved brackets:
  • {convert|360|-|362|m|abbr=on|disp=br} → 360–362 m
    1,181–1,188 ft
  • {convert|360|-|362|m|ft|abbr=on|disp=x|<br>(|)} → 360–362 m
    (1,181–1,188 ft)
Note with "disp=x" then 2nd unit "ft" is needed. -Wikid77 11:29, 20 August 2013 (UTC)
The template could be fixed, but meanwhile here is how it could be done in the module under development.
  • {{convert/sandboxlua|360|-|362|m|abbr=on|disp=br}} → 360–362 m
    1,181–1,188 ft
  • {{convert/sandboxlua|360|m|ft|abbr=on|disp=x|<br/>(|)}} → 360 m
    (1,180 ft)
  • {{convert/sandboxlua|360|-|362|m|ft|abbr=on|disp=x|<br/>(|)}} → 360–362 m
    (1,181–1,188 ft)
When using the tricky disp=x it is necessary to specify the output unit otherwise the module interprets the extra parameters as a unit. I haven't quite been able to bring myself to have the module interpret "0" as "use the default output unit" which some templates do. Johnuniq (talk) 23:41, 18 August 2013 (UTC)
By the way, it's only the first of the above that currently has a problem in the templates; the others work fine:
  • {{convert|360|-|362|m|abbr=on|disp=br}} → 360–362 m
    1,181–1,188 ft
  • {{convert|360|m|ft|abbr=on|disp=x|<br/>(|)}} → 360 m
    (1,180 ft)
  • {{convert|360|-|362|m|ft|abbr=on|disp=x|<br/>(|)}} → 360–362 m
    (1,181–1,188 ft)
Johnuniq (talk) 11:01, 19 August 2013 (UTC)

Too many digits

Does anybody see the dozen of so extra digits arising from the Convert template in this article Fernando de Noronha or elsewhere? Abductive (reasoning) 23:11, 20 August 2013 (UTC)

no, can you point to a particular section? Frietjes (talk) 23:16, 20 August 2013 (UTC)
Strange problem! It was due to the following (which is invalid because "2.2", the output value, is where the output unit should be):
  • {{convert|3.5|km|2.2|mi}} → 3.5 kilometres (2.2 mi)*
I fixed it with this edit.
The module gives the following with the invalid parameters:
  • {{convert/sandboxlua|3.5|km|2.2|mi}} → 3.5 kilometres (2.2 mi)*
I suppose an ugly message is better than possibly incorrect output, but a case could be made that the template gave the best result under the circumstances. Johnuniq (talk) 23:47, 20 August 2013 (UTC)
  • Each Convert subtemplate determines parameter format: Another reason the Template:Convert is very versatile is due to the lack of "error messages" which would prohibit smarter conversions. So by avoiding extra restrictions, Convert can transform dates into day-number, by Template:Convert/date, or musical notes into pitch level measured in hertz:
By comparison, the Lua module fails the date and music conversions:
Instead, each subtemplate of Convert checks for separate parameter restrictions, and Template:Convert/km could changed to reject "2.2" as being an invalid 3rd parameter, if considered a major problem. -Wikid77 (talk) 05:14, 21 August 2013 (UTC)
Yes, the templates have the benefit of being very versatile. However, extreme flexibility inevitably leads to maintenance difficulties and consistency problems (some examples). The module can be extended to handle complex units, for example, I implemented your {{convert/Mach}} technique with the following result (where 240000 is the altitude in feet):
  • {{convert/sandboxlua|12|Mach|240000}} → Mach 12 (12,600 km/h; 7,830 mph)
I decided to not worry about some special units (like date and note) because they do not appear to be used. If they were needed, the module could be expanded.
Re the "2.2" problem: I don't think it is a big deal, and above I said that the template does the best that can be done. However, tweaking one of the templates would not help because the issue applies to all of them:
  • {{convert|3.5|kg|2.2|lb}} → 3.5 kilograms (7.7 lb)*
Johnuniq (talk) 09:35, 21 August 2013 (UTC)
  • Convert was formerly one consistent template which reformatted zillion pages: Now that Convert has been split into many small, efficient, flexible subtemplates, there have been some consistency problems, but those can be handled via the 80/20 Rule, of fixing the top 10% of subtemplates used in 90% of pages. We really do not need 100% consistency, but instead need more conversions with new unit-codes and ever more new options, such as r2=5 or r3=5 or r4=5 to round the various output amounts during multi, dual or 1-to-3 conversions. Historically, changing the one Convert template has been very dangerous to many thousands of articles using some options, as well as burdening WP with the massive, multi-day wp:job_queue task of reformatting over 552,000 pages, many of them huge, time-consuming articles. Hint: "Don't put all your eggs in one basket". The impending future gargantuan task, to reformat one million pages, has been avoided so far by not using Convert in half of articles, such as pages with only one conversion. However, the extensive usage of {convert} is growing quickly (for bridges, roads, dams, etc.) as users have confirmed how hand-coded conversions are often wrong, and even one {convert} in a page can avoid trouble after an updated measurement. Because numerous changes to Convert have been kept limited to many small subtemplates, there have been few mega-disasters with Convert (despite years of trying!), while adding dozens of new units. Hence, we do not have an wp:RfC of over 472 users demanding "Opt-in only" to limit Convert. Meanwhile, there are still future months to fix problems in various Convert subtemplates. The Lua Module:Convert has been a valuable wake-up call to the extreme dangers of frequent updates to a massive conversion routine, to cause a million pages to reformat all year long. -Wikid77 07:26, 23 August 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_August_2013&oldid=1147402749"