Jump to content

Template talk:Convert/Archive October 2013

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


Errors, tweaks, fixes

from deleted "Template talk:Convert/hand"

Here are some fixes. Frankly, I hope that you don't spend hours on this, because the "two-way" conversion of hands to only inches or cm/m is strongly discouraged per WP:MEASUREMENT and the active members of WikiProject Equine strongly support a "three-way" conversion of hands to both inches and centimeters, per the {{hands}} template. The only thing that is needed here, really, is JLAN's request for a reverse conversion from cm first (or, I suppose, inches, though we've yet to do that one) into hands. His specific concern is that some European horse registries, and the FEI, use metric measurements, while most English speaking nations use hands. This, where the centimeter/meter measurement is "official," he makes an argument that the measurement should first be given in metric measurements, with convert used to give us hands and inches. While I do not agree 100% with his position, it is actually reasonable for him to ask for that flexibility, and so long as the conversion is used, I am willing to support it happening. However, what you have needs some fixes, listed below Montanabw(talk) 21:43, 10 October 2013 (UTC)

  • This template is not needed at all; 14.1 hands (57 inches; 145 cm) → 14.1 hands (57 in; 145 cm) As we have {{hands|14.1}} ( becomes 14.1 hands (57 inches, 145 cm) ) to do exactly the same thing.
  • This nomenclature is never used: 37–162 cm (3.2+1⁄2–16.0 hands) → 37–162 cm (3.26–15.38 hands) Hands are a single digit after the radix point, always: .1, .2, or .3 and if in-between, we write the fraction of an inch, i.e. 1/2 ( See, e.g. Theodore O'Connor for example, who was 14.1-1/2 hands) So you can either just make it round, or we use this version for fractional heights: {{hands|15.1 + 1/2}} becomes 15.1 1⁄2 hands (61.5 inches, 156 cm) .

Rounding 15.38 hands to 16 hands: @Montanabw, I will need to fix the rounding so that above 0.3+1/2 rounds to 1 extra hand. Currently, rounding to 1 decimal works, but 2 should show fractions of hands:

  • {convert|37|–|162|cm|hand|abbr=in}} → 37–162 cm (3.3–16.0 hands)
  • {convert|37|–|162|cm|hand|1|abbr=in}} → 37–162 cm (3.3–16.0 hands)
  • {convert|37|cm|hand|2|abbr=in}} → 37 cm (3.2+1⁄2 hands)
  • {convert|37|cm|hand|abbr=in}} → 37 cm (3.3 hands)

However, I am working to use new Template:Rndhands, which allows rounding to the nearest half-inch, such as {rndhands|12.143} as 12.11⁄2, or {rndhands|3.26} as 3.21⁄2. The rounding is extremely tedious to retrofit into {convert} with format restrictions in Lua, and so that is why it has taken years to address, but I think we are getting close to a solution. -Wikid77 (talk) 00:58/03:13/03:53, 11 October 2013 (UTC)

  • AAAAHHHHKKKK! (**head exploding**) Just don't round! Height measurements are a big deal in horse land, and where a measurement has a top end (such as the horse/pony cutoff in jumping competition) a horse that is 14.1-99/100 is still a legal pony, but if they are 14.2 they are a horse. Am I making sense here? (In practice, people generally don't break it down to more than a quarter-inch, and frankly a good hoof trim can do that, but even a horseshoe will make a cm or 1/2-inch difference.) Montanabw(talk) 20:38, 11 October 2013 (UTC)

Adjectival ranges broken

Currently, using the adj=on function in combination with ranges does not produce the desired result:

{{convert|1|to|2|ft|adj=on}}

should produce (ideally)

1- to 2-foot (.3 to .6 m)

or even (as an alternative)

1 to 2-foot (.3 to .6 m)

but instead actually leaves you with 1-to-2-foot (0.30 to 0.61 m), screwing up the hyphenation involved. I know this thing is kind of a beast, but kindly fix it when you have a minute. — LlywelynII 14:07, 29 September 2013 (UTC)

  • Use Convert/2 with "adj=split" for split range: (edit conflict)The default format for adjectival ranges has been "1-to-2-unit" but use new option "adj=split" with Template:Convert/2 to show format "1- to 2-unit" instead. Examples:
  • {convert/2 |3|to|4|m|ft}}           → 3 to 4 metres (10 to 13 ft)
  • {convert/2 |3|to|4|m|ft|adj=on}} → 3-to-4-metre (10-to-13 ft)
  • {convert/2 |3|to|4|m|ft|adj=split}}    → 3- to 4-metre* (10 to 13 ft)
  • {convert/2 |3|and|4|m|ft|adj=split}} → 3- and 4-metre* (10 and 13 ft)
A survey of Google Search has shown both formats, but the split form might be more common. To reduce complexity, only {convert/2} has been changed to allow "adj=split" so far. The default format has been "1-to-2-unit" for over 5 years (since Template:Convert/to/AoffSon), so the split range is major improvement. -Wikid77 (talk) 20:09, 29 September 2013 (UTC)
  • Note that convert/2 does not always work as well as convert:
    50 to 375 K (−223.2 to 101.9 °C)
    50 to 375 K (−223 to 102 °C)

Hawkeye7 (talk) 20:25, 1 October 2013 (UTC)

FIXED: I have updated the 4 related complex subtemplates. Thanks for noting the display problems of {convert/2} with temperatures. Just so busy. -Wikid77 22:39, 2 October 2013 (UTC)

acre adj=on

If you have a 29-hectare (72-acre) lake, the "acres" should be "acre". —Sladen (talk) 19:31, 29 September 2013 (UTC)

  • TESTING FIX: Thank you, checking it now. I am planning to submit an update so the result would be instead: 29-hectare (72-acre)*. The Lua version of Convert would also show: 29-hectare (72-acre). Hence, the correction is on the way. -Wikid77 (talk) 20:09/22:07, 29 September 2013 (UTC)

Magnetic field strength

Would it be possible to provide a means of converting Tesla - Gauss? I was surprised to that there doesn't currently appear to be a way of doing so. Many thanks. Jamesx12345 17:47, 30 September 2013 (UTC)

  • {convert|1|T|G}} → 1 tesla (10,000 G)
  • {convert|1|G|T}} → 1 gauss (0.00010 T)
  • {convert|1.67|T|G}} → 1.67 teslas (16,700 G)
Sorry for the 11-hour delay, but I was out and when I returned, a hot-water pipe had broken, and I had to replace a pipe connector before the room flooded. The Lua version of Convert was not designed to support teslas, and has required an update to add more units. Currently, the Lua version shows "1 tesla (10,000 G)". -Wikid77 (talk) 05:21, 1 October 2013 (UTC)
I can agree with the priorities you choose ;-). -DePiep (talk) 09:10, 1 October 2013 (UTC)
Tried to introduce this into module:Convert/extra; testcases are in {{convert/testcases/extra}}. This would be the new datatable (for User:Johnuniq/Conversion data). It really needs checks:
"Magnetic field strength" (new utype)
Unit code Symbol US symbol Scale Extra Name Plural name US name US plural name Prefix Default Link
T T 1 tesla SI G Tesla (unit)
G G 0.0001 gauss gauss T Gauss (unit)
-DePiep (talk) 09:10, 1 October 2013 (UTC)
One problem I have noticed with adding the Tesla is that MT is already in use by megatonne but all the other SI prefixes seem fine. -- WOSlinker (talk) 10:05, 1 October 2013 (UTC)
That looks good, although I have just added a note to User:Johnuniq/Conversion data#Name explaining that the plural "teslas" is not required because it consists of "tesla" + "s". However, the plural of "gauss" is required, and that has to be entered as "name2" in Module:Convert/extra. Currently, the plural of gauss is shown as "gausss" (three of "s"):
  • {{convert/sandboxlua|2|T}} → 2 teslas (20,000 G)
  • {{convert/sandboxlua|2|G}} → 2 gauss (0.00020 T)
To see the right syntax, you would need to search Module:Convert/data for something similar ... bit messy.
Running the makeunits program confirms what WOSlinker says: there is only one conflict, and that requires an exception to be entered to declare that "MT" is "metric ton", not "megatesla". I'll add all that in a day or so (I was planning to move the current extra units into the main data soon). Johnuniq (talk) 10:42, 1 October 2013 (UTC)
Did the "MT" conflict cause the prefixes error then? [1] Otherwise, that is a separate issue. -DePiep (talk) 11:12, 1 October 2013 (UTC)
No. The special code which handles SI prefixes needs the unit prepared in a certain way (as done by makeunits), and it will collapse if the unit does not have what is required. WOSlinker has just fixed the extra unit, although name2 is redundant for teslas, but required for gauss. I'll fix it later. There is not really a conflict with MT, but makeunits refuses to produce the output until an exception is added to say explicitly that the override is intentional. Any unit found in the data table will be used (and since MT exists, using code "MT" will use the MT in the table). It's only if a unit is not in the table that the module resorts to tricky stuff like checking whether an SI prefix has been used. Johnuniq (talk) 12:24, 1 October 2013 (UTC)
- So until the source data page (with these two new ones and the MT exception added) is processed by makeunits, input "MT" for megatesla is recognized as metric ton and will produce a mismatch error (or weird other default outcome):
  • {{convert/sandboxlua|1|kT|G}} → 1 kilotesla (10,000,000 G)
  • {{convert/sandboxlua|1|MT|G}} → 1 metric ton ([convert: unit mismatch])
  • {{convert/sandboxlua|1|MT}} → 1 metric ton (0.98 long tons; 1.1 short tons)
No wrong conversion; just an unexpected message/outcome then. -DePiep (talk) 21:20, 1 October 2013 (UTC)
By old template:
  • {{convert|1|kT|G}} → 1 kilotesla (10,000,000 G)
  • {{convert|1|MT|G}} → 1 metric ton ([convert: unit mismatch])
  • {{convert|1|MT}} → 1 metric ton (0.98 long tons; 1.1 short tons)
Hmm. That's a bad one. -DePiep (talk) 21:25, 1 October 2013 (UTC)
Gauss plural: old template does {convert|1.67|G|T}} → 1.67 gauss (0.000167 T)
So I added this for gauss plural. Also rm teslas plural since it is the default as J says. -DePiep (talk) 13:08, 1 October 2013 (UTC)
That was really quick. Many thanks. Jamesx12345 15:32, 1 October 2013 (UTC)
@DePiep: The current template needs to define each SI unit separately (one template for "m", another for "mm", another for "km", and so on). Therefore "kT" won't work unless someone creates that template. Re the module and makeunits: the rule is that if a unit is defined in the data table, that definition is used. It's only if a unit is not so defined that the module looks for an SI prefix. That means "MT" will always mean metric ton, regardless of the fact that it could also be interpreted as megatesla. The module does not use context to sometimes regard MT as mass and sometimes as magnetic field strength. I have just emptied the extra module, after moving the new units to the main data module. Johnuniq (talk) 23:40, 1 October 2013 (UTC)
All fine. I was just checking if I understood it. I saw the module /extra outcomes being as you described. The only "bad" old template is where metric tons into gauss is performed, because it produces a wrong conversion without notice. I'm sorry if this excercise time-pressed you to do the makeunits process. As said, it worked as predicted. -DePiep (talk) 06:29, 2 October 2013 (UTC)

Comment Note that a tesla is a really big unit to begin with. Our article mentions the magnets in the LHC at CERN are 8 T. Lack of support for kT or MT is unlikely to be noticed . —[AlanM1(talk)]— 01:36, 3 October 2013 (UTC)

ton-miles per day

How do I convert compound units, such as "ton-miles per day"? The obvious ST*mi/day does not work.StephenTX (talk) 22:54, 5 October 2013 (UTC)

Rate of rainfall

For Tropical Storm Marco (2008)#Preparations, impact and records 1 inch per hour (25 mm/h). Peter Horn User talk 16:19, 6 October 2013 (UTC)

I've added it in the lua version, (in Module:Convert/extra), {{convert/sandboxlua|1|in/h|mm/h|2}} → 1 inch per hour (25.40 mm/h) . Someone else could look at the current template to add it there. -- WOSlinker (talk) 16:58, 6 October 2013 (UTC)
Please also write a proposal for the basic Module:Convert/documentation/conversion data/doc unit table. -DePiep (talk) 19:45, 6 October 2013 (UTC)
Attention, in the context of rainfall, inches per hour is not "speed", but the rate of accumulation. Peter Horn User talk 18:50, 8 October 2013 (UTC)
Being "mm/sec" in essence it is a speed. Indeed speed is an "accumulation" of distance, always. -DePiep (talk) 00:38, 9 October 2013 (UTC)

Convert/extra edits

Resolved

Currently module:convert/extra code does not correspond with module:convert/extra/doc. So I cannot make testcases/demos. We really need discipline in this. "/extra" is a great way to improve convert, but it should not be treated as a private sandbox. -DePiep (talk) 19:39, 6 October 2013 (UTC)

I don't understand the problem. Perhaps things were different when you posted, but extra looks good to me. Johnuniq (talk) 00:45, 7 October 2013 (UTC)
It was OK after all. The documentation shows illustrations, not the current content (that was the diff I saw). Which is OK. -DePiep (talk) 07:12, 7 October 2013 (UTC)

Hands and centimetres

I've encountered some problems managing hands and centimetres with disp=flip.
For example:

{{convert|16.3|hand|cm}}
16.3 hands (170 cm)

{{convert|16.3|hand|cm|disp=flip}}
170 centimetres (16.3 h)

In other words, the template does not work when the input unit is hands, the output unit is centimetres and there's disp=flip (useful when dealing with non UK-related horse articles).
Best regards and thanks in advance.--Carnby (talk) 08:49, 7 October 2013 (UTC)

In the lua module:
{{convert/sandboxlua|16.3|hand|cm}}
16.3 hands (170 cm)
{{convert/sandboxlua|16.3|hand|cm|disp=flip}}
170 centimetres (16.3 h)
Correct there. -DePiep (talk) 09:44, 7 October 2013 (UTC)
Thanks, it is a temporary solution, isn't it?--Carnby (talk) 13:45, 7 October 2013 (UTC)
temporary is the current template (today in wiki common sense). In weeks or months it will be replaced by the Lua module. Not many editors want to fix this error you point to (an error it is), because the switch to Lua will fix it. Am I clear enough? -DePiep (talk) 20:15, 8 October 2013 (UTC)

There seem to be other problems with hand conversions too. Some people think it necessary to convert metric units to both hands and inches for horse height (I'm not one of those people, btw). If I've understood correctly, we are supposed to use {{convert/show2 }} for this kind of thing, rather than request yet another three-way convert. However, at the moment neither appears to work:

  • {{convert/show2 |165|cm|hand|in}} —> 165 centimetres (16.1 4.0 hands (41 cm); 65 in)
  • {{convert/show2 |1.65|m|hand|in}} —> 1.65 metres (16.10 4.0 hands (41 cm); 65 in)
  • {{convert|165|cm|h in|2|lk=out}} —> an error message

Any advice? Justlettersandnumbers (talk) 18:22, 8 October 2013 (UTC)

  • FIXED Convert/hand: I am currently updating Template:Convert/hand to allow "disp=flip" and to work with {convert/show2}. Meanwhile, perhaps use 2 converts, one with disp=x plus another as {convert|165|cm|in|disp=out}. Example:
  • {convert |165|cm|hand|disp=x| (}}; {convert |165|cm|in|disp=out}}) → 165 centimetres (16.1 hands; 65 in)
The conversions with hand units are extremely complex due to 0.3 hands being 3⁄4 or 15.3 hands rounding to 16 hands rather than 15. The extra changes required me several hours minutes to implement and test.
  • {convert/show2 |165|cm|hand|in}} → 165 centimetres (16.1 hands*; 65 in*)
  • {convert/show2 |1.65|m|hand|in}} → 1.65 metres (16.1 hands*; 65 in*)
The changes were extremely complex, and so it took me some minutes to do. -Wikid77 (talk) 20:19/21:06, 8 October 2013 (UTC)
;-) -DePiep (talk) 21:13, 8 October 2013 (UTC)
Just so you all know, we already have hands. For example {{hands|16}} and {{hands|15.1 + 1/2}} equals 16 hands (64 inches, 163 cm) and 15.1 1⁄2 hands (61.5 inches, 156 cm) . However, 14.1 hands (57 inches; 145 cm) gets us there too. But now we have confusion. Montanabw(talk) 00:08, 9 October 2013 (UTC) Follow up: That said, Wikid77, I AM impressed with your talent. However, you also don't want rounding except to the nearest inch, one never rounds 15.3 to 16h, though sometimes half-inch increments might be rounded (though even that is rare). And, I must be a minor pain in the butt, but rather than the abbreviation "h", which is not known outside the horse world, (and some people prefer "hh" though not universally) please say "hands" with a link to hand (unit). Montanabw(talk) 02:02, 9 October 2013 (UTC)
(edit conflict)Thanks, Wikid77, that's great. If you want to make it perfect, suppress the second "decimal" place of the hands output, as in the metre conversion example above - 16.10 h is not a possible result (yes, it can be hidden with |r2=1, but it should never be shown). Thanks again, Justlettersandnumbers (talk) 08:55, 9 October 2013 (UTC)
Agreed on the second decimal place not being something ever used, I also noted this on the talk page of the template. Wikd, loks like you also did a little bit of work on the hands template, may want to refresh your memory over there as well. I view this one as the thing to use when {{hands}} cannot be tweaked to work, but no sense duplicating effort, either.Montanabw(talk) 22:09, 10 October 2013 (UTC)

Default hands as wikilinked unit name

Because the symbol "h" (for "hands") is rarely used in general writing (often as "h" for "hours"), then Template:Convert/hand has been reset to default the unit as the wikilinked unit name "hands" (plural/singular), for either input or output amounts, rather than "h" as the output unit.

  • {convert|14.1|hand|in cm}} → 14.1 hands (57 inches; 145 cm)
  • {convert|88|in|hand}} → 88 inches (22.0 hands)
  • {convert|13.3|-|14.2|hand|in}} → 13.3–14.2 hands (55–58 inches)
  • {convert/show2 |77|in|hand|cm}} → 77 inches (19.1 hands*; 200 cm*)

Similar settings will be needed in the Lua version, which now shows:

  • {convert/sandboxlua |14.1|hand|in cm}} → 14.1 hands (57 inches; 145 cm)
  • {convert/sandboxlua |88|in|hand}}         → 88 inches (22.0 hands)

For most cases, Template:Hands can be used instead. -Wikid77 05:26, 9 October 2013 (UTC)

While giving the customer what they want is good, I think consistency is important and too much confusion might be caused by having some units which automatically generate a link. Also, how do you turn the link off (lk=off does not seem to work)? An article with several hand conversions should not link each of the occurrences, and if anyone ever wanted to add some convert templates to Hand (unit), they would not want them linked.
Using the module, the linked results can be produced as follows:
  • {{convert/sandboxlua|14.1|hand|in cm|lk=in}} → 14.1 hands (57 inches; 145 cm)
  • {{convert/sandboxlua|88|in|hand|abbr=off|lk=out}} → 88 inches (22.0 hands)
  • {{convert/sandboxlua|13.3|-|14.2|hand|in|lk=in}} → 13.3–14.2 hands (55–58 inches)
  • {{convert/sandboxlua|77|in|hand+cm|lk=out}} → 77 inches (19.1 hands; 200 cm)
The last uses hand+cm for a user-specified combination, but has the defect that cm is linked. Johnuniq (talk) 08:50, 9 October 2013 (UTC)
Use "lk=none" as {convert|14.1|hand|in cm|lk=none}} to show: 14.1 hands (57 inches; 145 cm)*. -Wikid77 14:21, 9 October 2013 (UTC)
Hands link should be the default, it is often used only once in an article. Optional parameter can be added to suppress the link, that's what we do when we use it a lot. Montanabw(talk) 22:09, 10 October 2013 (UTC)
First, apologies if it was I who unintentionally caused Johnuniq's comment to get lost. Second, he's right - the unit, whatever unit, should only link out once per article ; anything more is over-linking. Third, with respect I disagree with Wikid77: {{Hands}} only works from customary units to metric; it is thus only suitable for use in articles whose subject has some strong connection to one of the handful of English-speaking countries where hands are traditionally used. All other articles will, in accordance with WP:UNIT, use metric units as the main unit. So it is kind of very useful to have {{Convert}} working well for this conversion. For which many thanks.
Actually, I can't see the point of {{hands}} at all. What does it do that {{convert}} can not? Justlettersandnumbers (talk) 13:34, 9 October 2013 (UTC)
This issue of "metric first" measurement caused quite the heated discussion two years ago at WikiProject Equine (WPEQ) and we seemed to have it settled then. It is a measurement system specific to horses, and the debate at WT:EQUINE from 2011 went on for quite some time, and anyone who wishes to revisit the debate can look in the archives. The point is that it is settled consensus. Frankly, {{hands}} is FAR simpler, more elegant, easier to use, and is used on hundreds of articles, it was specifically designed at the request of WikiProject Equine members. I am willing to go along with JLAN's personal desire to have conversion templates that put centimeters/meters first, but this is JLAN's personal quirk and no one else at WPEQ does it this way. Likewise, not "all other" articles use metric-first conversions, most articles related at all to the United States use Imperial measurements, then metric. (The principle is akin to that of UK versus US English) Given that all the players at WPEQ are the same people now as then, there is no use in revisiting that particular drama. Montanabw(talk) 22:09, 10 October 2013 (UTC)
Most often {hands} is short for {convert|..|hand|cm in|lk=in}; however, {hands} also has correct support for fractions:
  • {hands|15.3+1/2}} → 15.3 1⁄2 hands (63.5 inches, 161 cm)
  • {convert|15.3+1/2|hand|in}} → 15.3+1⁄2 hands (63.5 inches)
  • {convert/sandboxlua|15.3+1/2|hand}} → 15.3+1⁄2 hands (63.5 inches; 161 cm)
The calculation for 15.3 1⁄2 hands should be 15×4 + 3 + 0.5 inches = 63.5 inches (161 cm), but I had not yet fixed {convert/hand} to correctly handle the fraction part after I fixed it in template {hands}. Now, in the recent updates, I have also fixed {convert} to handle fractions in hands. -Wikid77 (talk) 14:21, 9 October, 07:39, 10 October 2013 (UTC)
I'm quite happy with {hands}. As I am not good at parsing syntax, someone just reassure me that we can still use the things so they look correct in output for standard horse hands measurements. And that the two templates don't contradict each other. Montanabw(talk) 22:09, 10 October 2013 (UTC)

It looks like the WPEQ people are happy with {{hands}}, but as Montanabw says, the templates should not contradict each other, so I fixed the module to interpret fractions of a hand as fractions of an inch. It could be argued that the default rounding from the module is not optimum, but I'm going to pass on tweaking that at the moment.

  • {{hands|14.1+3/4}} → 14.1 3⁄4 hands (57.75 inches, 147 cm)
  • {{convert/sandboxlua|14.1+3/4|hand}} → 14.1+3⁄4 hands (57.75 inches; 147 cm)
  • {{convert/sandboxlua|14.1+3/4|hand|in+cm}} → 14.1+3⁄4 hands (57.75 inches; 147 cm)
  • {{convert/sandboxlua|14.1+3/4|hand|in+cm|lk=in}} → 14.1+3⁄4 hands (57.75 inches; 147 cm)

The above numbers are from the lead of Theodore O'Connor. Johnuniq (talk) 00:32, 11 October 2013 (UTC)

(Bows) You folks who know how to do this template syntax stuff just sort of amaze me. Wow! Montanabw(talk) 20:31, 11 October 2013 (UTC)
  • Some afternotes.
- The reverse is inch-to-hand. Let's see:
{{convert/sandboxlua|57.75|in|hand}} → 57.75 inches (14.2 hands)
Clearly this is not the hand-format, but the number is OK. And since this direction inch-to-hand is not documented (promised) in any template, nothing is in error. Module:convert is not in error.
- If there are any conflicting options between {{convert/sandboxlua}} and current {{hand}} we'd like to know. That could be a named parameter with different effect. Not that {{hand}} code must use the module, but for consistency all {{convert}}/{{hand}} named parameters better be similar in effect. I can add that the convert module has lots of consistent options, and that the allways-link-inch is a bit old. Hand-usrs are invited to agree.
- I agree with Montanabw that the background workings done are great. -DePiep (talk) 21:00, 11 October 2013 (UTC)
  • Rounding to half-inch amounts: For Convert/hand, I went the "extra mile" and added the ability to correctly show half-inch increments for precise numbers:
{convert|57.75|in|hand}} → 57.75 inches (14.2 hands)
{convert|57.26|in|hand}} → 57.26 inches (14.1 hands)
{convert|57.95|in|hand}}             → 57.95 inches (14.2 hands)
{convert/sandboxlua |57.95|in|hand}} → 57.95 inches (14.2 hands)
That avoids the bizarre "14.18 hands" which was just the easy way to shift between 14.1 and 14.2. However, such precisions are extremely rare, and those cases could use {convert/old} to show fractions in output and avoid 2-decimal hand numbers. This rounding, to half-inch amounts, just shows the extreme complexity needed for some types of conversions. -Wikid77 (talk) 19:47, 12 October 2013 (UTC)
Wow Wikid, I did not expect (or intend) that you'd dive into this. Now I have this question. I know you did not like the module, with reasons. All fine. But could you create tests, the meanest tests in mind, to check the new module:convert? If the module fails, you win. -DePiep (talk) 20:03, 12 October 2013 (UTC)
I now officially think you guys are having wayyyyy too much fun dinking round with this! LOL! I've explained in the examples on the template what the problem is. What JLAN wanted was a template form to convert cm or m to hands, which we sort of already had and you folks have improved. What I wanted was for the same setup to convert cm to BOTH hands AND inches, which no one appears to have yet accomplished on the actual template... can it be done? Montanabw(talk) 22:06, 12 October 2013 (UTC)
So you want input=147cm to produce like 14.1 3⁄4 hands (57.75 inches, 147 cm) or so. Any actual example for the need? Well, since it does not work today (by any documentation promise), it won't happen tomorrow with new module. -DePiep (talk) 22:26, 12 October 2013 (UTC)

I've done what's easy, namely added a unit called "handlk" which is the same as hand but which always links to the article.

Later, and as DePiep mentions, if there is an actual need, I could make the hand unit always output to the nearest quarter inch, instead of the 14.2 shown above. Johnuniq (talk) 01:09, 13 October 2013 (UTC)

Best to NOT allow rounding of hands; let people enter the actual measurements. There is never a need to round; any rounding is already done by the WP:RS used to describe the horse. Things like horseshoes and hoof trims can affect height within a half-inch or more, and so there is usually an "official" measurement taken and it needs to be reported exactly per WP:SYNTH. The actual need for half-inch measurement occurs a few times, almost always in regards to classes of pony competition or the horse/pony cutoff (usually 14.2) in certain disciplines (especially jumping). One time we will need fractions is when an official standard is in centimeters, but the hands conversion falls in-between. (Example: 146 cm = 57.5 inches or 14.1-1/2 hands, that's a real common one!) The second time is when a famous horse is juuuuuusssssstttt barely under 14.2, as was the Olympic hopeful Theodore O'Connor. Basically, a 14.1-1/2 horse is a pony, definitely DO NOT want that to round up to 14.2, when the animal is officially a "horse." Montanabw(talk) 03:27, 13 October 2013 (UTC)
I get the point about RS for correct unrounded input. But when coming from cm (a future option), don't we need to round the hands output to say 1⁄32, or should it be unlimited (unrounded)? -DePiep (talk) 15:08, 13 October 2013 (UTC)
LOL! In practical terms, I seldom see measurements that require more than 1/2 inch, though, as in the example of "Teddy", the 3/4 inch increment may pop up, so 1⁄4 would probably do for 90-95% of the circumstances I can think of. But I'd suggest that the template be structured with an option so that it is easy to suppress the rounding function, maybe with really clear instructions (for people like me who suck at syntax and just do what we are told...) for how to suppress it on those rare occasions it is needed. This is one of those situations where most horse people don't care, but those who DO care (particularly the pony enthusiasts) happen to care a great deal. I could see this be a potential issue for the miniature horse, Shetland pony, and Welsh pony (where they have four subsections, all based on height) breeders in particular. Montanabw(talk) 17:13, 13 October 2013 (UTC)
Yes, LOL it is for all of us (in the hair splitting department). My point was, if the input is cm, there sure is an rounding needed. Otherwise we could end up with a 1⁄32 inch measure (roughly a ~1mm precision). Since you say 1⁄4 inch is most detailed you know, we must be able to round the cm input to that inch fraction. Otherwise, there could be an 1⁄128 inch output (please don't ask me for an example; it is about the fact of any rounding yes/no) -DePiep (talk) 20:31, 13 October 2013 (UTC)

@Montanabw: The issue concerns what output is wanted from the following:

Should the output show "h" or "hand"? Should the output show "14.2" or "14.1 3⁄4"? Johnuniq (talk) 04:33, 14 October 2013 (UTC)

  • Rounding to the quarter inch is plenty, a horse's hoof can grow a couple millimeters in a very short time. Generally have output show "hands", plural (no horse will be one hand tall). When there are many measurements in the article, the abbr=on parameter can be set to just h. For a measurement taller than 147 cm, rounding probably would not matter, but in pony land, it matters A LOT (and no measurement would matter more than a horse that is 147 cm, most likely!). So I'd say that if a WP:RS states that the horse/pony is 147cm, then it probably matters for competition purposes, then the template should NOT automatically round to 14.2. Montanabw(talk) 04:43, 14 October 2013 (UTC)


After all this, there is the one thing needed that started this discussion and it's the one thing we don't have: a way to convert three ways with the following results: 137–162 cm (13.2–16 hands; 54 to 64 in.) (option for abbrev on or off, I suppose) Possibly an inches first to hands and cm also useful, though will rarely be used, most likely never. It's the folks who feel it is terribly important to provide horse measurements with cm first that's the concern. {{hands}} takes care of everything else Montanabw(talk) 23:16, 16 October 2013 (UTC)

The module gets close to that. There are minor differences with one significant problem, namely that the cleverness I recently added makes "hand" appear as the default, but using abbr=on changes it to "h". Here's how it looks, none of them what you want:
  • {{convert/sandboxlua|137|-|162|cm|hand+in}} → 137–162 centimetres (13.2–16.0 hands; 54–64 in)
  • {{convert/sandboxlua|137|-|162|cm|hand+in|abbr=on}} → 137–162 cm (13.2–16.0 h; 54–64 in)
  • {{convert/sandboxlua|137|-|162|cm|hand+in|abbr=in}} → 137–162 cm (13.2–16.0 hands; 54–64 inches)
Do you really want an en dash for hands and "to" for inches!?
Johnuniq (talk) 06:57, 17 October 2013 (UTC)
Actually, all three will work find, depending on the circumstances. But (heh) what I **want** is to just use {{hands}} for everything. However, other users consider it important in some cases to put measurements in centimeters first. So I am trying to make a three-way conversion work so that everyone is happy. Montanabw(talk) 23:25, 17 October 2013 (UTC)

List of mountains in Ponce, Puerto Rico

Prior to using the Convert template, THIS table seemed to be sorting fine by height. Now, it is no longer sorting correctly. For example, when sorting by increasing height, since Cerro de Punta is taller than Cerro Maravilla it should appear before Cerro Maravilla in the list, but it doesn't. It seems that the Convert template may be the culprit. Has anyone here experienced this before? Thanks, Mercy11 (talk) 18:49, 8 October 2013 (UTC)

  • Use option "sortable=on" in each conversion: Otherwise, the numbers tend to sort by 1st digit, so use parameter "|sortable=on" to format the numbers in the column as sort-able in numeric order. -Wikid77 (talk) 21:31, 8 October 2013 (UTC)
It worked!!! Thanks! I have built many sortable tables in the past and never had this problem: great to know there was a solution! Thx! Mercy11 (talk) 13:01, 9 October 2013 (UTC)

Production of a commodity per area under cultivation.

For Avocado production in Mexico#Production, how would one convert metric tons or tonnes per hectare (MT/ha or t/ha) into a dual conversion of short tons per acre and long tons per acre (ST/acre and LT/acre) eg {{convert}}? Peter Horn User talk 18:04, 12 October 2013 (UTC)

  • Checking the unit-codes: For the conversion, the unit-codes are: MT/ha, ST/acre, and LT/acre, as follows:
  • {convert |4|t/ha|lb/sqft}} → 4 tonnes per hectare (0.082 lb/sq ft)
  • {convert |4|t/ha|LT ST/acre}} → 4 tonnes per hectare ([convert: unknown unit])
  • {convert |4|MT/ha|lb/sqft}} → 4 metric tons per hectare (0.082 lb/sq ft)
  • {convert |4|MT/ha|LT ST/acre}} → 4 metric tons per hectare ([convert: unknown unit])
That is the status, so far. More later. -Wikid77 (talk) 20:14, 12 October 2013 (UTC)
Please document it. -DePiep (talk) 20:19, 12 October 2013 (UTC)
...and make mean, mean tests for module:convert. -DePiep (talk) 21:24, 12 October 2013 (UTC)
  • Similar t/ha or MT/ha conversions in Lua: Using the same unit-codes as above, the Lua module gives the following results:
  • {convert/sandboxlua |4|t/ha|LT ST/acre}} → 4 tonnes per hectare ([convert: unknown unit])
  • {convert/sandboxlua |4|MT/ha|lb/sqft}} → 4 metric tons per hectare (0.082 lb/sq ft)
  • {convert/sandboxlua |4|MT/ha|LT ST/acre}} → 4 metric tons per hectare ([convert: unknown unit])
The unit-code "MT/ha" was added as new yesterday. -Wikid77 (talk) 10:49, 13 October 2013 (UTC)
Added to old convert and/or added to new module? Please be clear. Formally I ask for documentation. -DePiep (talk) 00:42, 14 October 2013 (UTC)

Pressure confusion

Thanks to Wikid77 for the comparisons in the previous section because when I started looking at adding the "MT/ha" missing unit I found errors in the pressure units defined in the module, and have spent most of the last few hours completely befuddled. I have fixed the problems (I think) so the unit definitions in the module do not produce incorrect outputs, but there are some problems...

First, here are some simple errors which became apparent during testing:

  • {{convert/g/cm2}} unit symbol should be "g/cm2" not "g/m²" (c as in centi is missing)
  • {{convert/oz/sqft}} unit symbol should be "oz/sq ft" not "oz/sq yd" (ft not yd).
  • {{convert|1|g/cm2|abbr=on}} → 1 g/cm2 (2.0 lb/sq ft) [currently shows "1 g/m²"]
  • {{convert/sandboxlua|1|g/cm2|abbr=on}} → 1 g/cm2 (2.0 lb/sq ft)
  • {{convert|1|oz/sqft|abbr=on}} → 1 oz/sq ft (310 g/m2) [currently shows "1 oz/sq yd"]
  • {{convert/sandboxlua|1|oz/sqft|abbr=on}} → 1 oz/sq ft (310 g/m2)

The serious problem concerns confusion between units for pressure and units for mass per unit area (such as "application rate", or paper "weight").

These units (and a few other similar units) have scales that are correct only for "mass per unit area":

These units have scales that are correct only for "pressure":

An example of incorrect output is shown below. The kg/cm2 (pressure) values are correct, while the kg/m2 (mass per unit area) outputs are incorrect by a factor of 9.8 (70e-4 kg/cm2 = 70 kg/m2).

  • {{convert|70e-4|kg/cm2|MPa|abbr=on|sigfig=4}} → 70×10−4 kg/cm2 (6.865×10−4 MPa)
  • {{convert|70e-4|kg/cm2|psi|abbr=on|sigfig=4}} → 70×10−4 kg/cm2 (0.09956 psi)
  • {{convert|70e-4|kg/cm2|MPa psi|abbr=on|sigfig=4}} → 70×10−4 kg/cm2 (6.865×10−4 MPa; 0.09956 psi)
  • {{convert|70|kg/m2|MPa|abbr=on|sigfig=4}} → 70 kg/m2 (0.0006865 MPa) [currently output is equivalent to 0.00007 MPa]
  • {{convert|70|kg/m2|psi|abbr=on|sigfig=4}} → 70 kg/m2 (0.09956 psi)
  • {{convert|70|kg/m2|MPa psi|abbr=on|sigfig=4}} → 70 kg/m2 (0.0006865 MPa; 0.09956 psi)

The module used to have the same error, but I have recently fixed the unit definitions and it's now giving:

  • {{convert/sandboxlua|70e-4|kg/cm2|MPa|abbr=on|sigfig=4}} → 70×10−4 kg/cm2 (6.865×10−4 MPa)
  • {{convert/sandboxlua|70e-4|kg/cm2|psi|abbr=on|sigfig=4}} → 70×10−4 kg/cm2 (0.09956 psi)
  • {{convert/sandboxlua|70e-4|kg/cm2|MPa psi|abbr=on|sigfig=4}} → 70×10−4 kg/cm2 (6.865×10−4 MPa; 0.09956 psi)
  • {{convert/sandboxlua|70|kg/m2|MPa|abbr=on|sigfig=4}} → 70 kg/m2 (0.0006865 MPa)
  • {{convert/sandboxlua|70|kg/m2|psi|abbr=on|sigfig=4}} → 70 kg/m2 (0.09956 psi)
  • {{convert/sandboxlua|70|kg/m2|MPa psi|abbr=on|sigfig=4}} → 70 kg/m2 (0.0006865 MPa; 0.09956 psi)

The module currently defines the following as mass per unit area (and so will not convert these to pressure):

  • {{convert/sandboxlua|1|g/cm2}} → 1 gram per square centimetre (2.0 lb/sq ft)
  • {{convert/sandboxlua|1|g/m2}} → 1 gram per square metre (0.00020 lb/sq ft)
  • {{convert/sandboxlua|1|kg/m2}} → 1 kilogram per square metre (0.20 lb/sq ft)
  • {{convert/sandboxlua|1|lb/1000sqft}} → 1 pound per thousand square feet (4.9 g/m2)
  • {{convert/sandboxlua|1|lb/sqft}} → 1 pound per square foot (4.9 kg/m2)
  • {{convert/sandboxlua|1|lb/sqyd}} → 1 pound per square yard (0.54 kg/m2)
  • {{convert/sandboxlua|1|LT/acre}} → 1 long ton per acre (2.5 t/ha)
  • {{convert/sandboxlua|1|MT/ha}} → 1 metric ton per hectare (0.40 long ton/acre; 0.45 short ton/acre)
  • {{convert/sandboxlua|1|oz/sqft}} → 1 ounce per square foot (310 g/m2)
  • {{convert/sandboxlua|1|oz/sqyd}} → 1 ounce per square yard (34 g/m2)
  • {{convert/sandboxlua|1|ST/acre}} → 1 short ton per acre (2.2 t/ha)
  • {{convert/sandboxlua|1|t/ha|LT/acre ST/acre}} → 1 tonne per hectare (0.40 long ton/acre; 0.45 short ton/acre)
  • {{convert/sandboxlua|1|t/ha|LT ST/acre}} → 1 tonne per hectare ([convert: unknown unit])

Pressure units include:

  • {{convert/sandboxlua|1|kg/cm2|Pa}} → 1 kilogram per square centimetre (98,000 Pa)
  • {{convert/sandboxlua|1|lbf/in2|Pa}} → 1 pound-force per square inch (6,900 Pa)
  • {{convert/sandboxlua|1|psi|Pa}} → 1 pound per square inch (6,900 Pa)

The problem is that my searching finds only a couple of articles using kg/m2 as mass per unit area. By contrast, thousands use it as pressure, mostly via {{aircraft specs}}. My preference would be to educate the world that "kg/m2" really cannot be used for pressure, but it looks like that's not going to be productive. A benefit of making kg/m2 pressure is that it would then be consistent with kg/cm2 which is pressure.

I can't get any further at the moment, so I'm outlining the current situation. It looks like "kg/m2" and perhaps some others will have to be pressure, so new unit codes will be needed for "kg-mass/m2", and eventually a few articles will need editing to use those unit codes. As far as I can tell, only a very small number of incorrect conversions are currently visible in articles—in principle, many conversions are wrong, but in practice the numbers work out to be correct for the particular units actually in use (for example, using the current templates to convert the pressure kg/m2 to lb/sqft works because both are incorrectly defined, but converting kg/m2 to Pa would give an incorrect value).

I could only find one error, and that's in Russian locomotive class Ye which uses:

  • {{convert|70|kg/m2|MPa psi|abbr=on}} → 70 kg/m2 (0.00069 MPa; 0.100 psi)

The following result is correct (70e-4 kg/cm2 = 70 kg/m2):

  • {{convert|70e-4|kg/cm2|MPa psi|abbr=on}} → 70×10−4 kg/cm2 (6.9×10−4 MPa; 0.100 psi)

Perhaps I'll think of a gigantic kludge so kg/m2 can be used for pressure and for mass-per-unit-area, but I'd prefer not to. Johnuniq (talk) 08:42, 15 October 2013 (UTC)

nice job making this actually work, but I don't think we should allow for conversion between mass-per-unit area and force-per-unit-area in the long-term. if someone attempts this sort of thing, have it suggest an alternative (like Pa for kg/m2), and add a tracking category so we can fix them. Frietjes (talk) 15:20, 15 October 2013 (UTC)
There are several places in the above list of conversions where the rendered text, contrary to WP:SUPSCRIPT, includes unicode superscript characters.
—Trappist the monk (talk) 16:00, 15 October 2013 (UTC)

Let us get away from the incorrect usage of "kg/m2", "t/ha", "oz/sq in", "lb/sq ft", etc. to refer to pressure units ("kgf/m2", "tf/ha", "ozf/sq in", "lbf/sq ft", etc.) So, no, the b in {{convert/kg/m2}} should remain as 1 and this shouldn't be used for pressure, it's a mass per unit area, how else would we be able to convert area densities (mass per area production rates, etc.)? So, I say do educate the world that kg/cm2 is not a pressure (let the template give an error message whenever this is attempted). It might not look like it'll be productive but, in the long term, not doing so is going to be hugely problematic. We should insist that kilograms-force, pounds-force, etc. be explicitly stated and thus too weight per area (this is more a MOSNUM issue). Let's get started on fixing the problem; thousands of articles may be misusing kg/m2 but it's not so daunting if it's mostly through another template: fix that and the problem will mostly vanish. Jimp 08:47, 16 October 2013 (UTC)

Excellent! I was despondently resigning myself to not having a satisfactory outcome, but it would be much better to fix the problem to avoid years of confusion. There are 3644 transclusions of {{aircraft specs}}, and that template uses {{convert}} to convert between kg/m2 and lb/sqft (where each is a pressure). For example, Bell Sidewinder shows "Wing loading: 3.25 lb/sq ft (15.9 kg/m2)". I put a proposal to change the template so it works with "kgf" and "lbf" instead of plain "kg" and "lb" at Template talk:Aircraft specs#Symbols for pressure (with a mention at the aviation project). I'm hoping there won't be any opposition, and that Jimp would do the edit required at {{aircraft specs}} to make the change. Let's work towards getting that done, then tackle kg/cm2 and possibly others. Johnuniq (talk) 10:57, 16 October 2013 (UTC)
OMG, I've just had another look at wing loading and perhaps I have this all wrong?? Something I read yesterday made me think kg/m2 was being used as pressure, but perhaps "loaded weight of the aircraft divided by the area of the wing" qualifies as mass-per-unit-area? Of course "weight" is really kgf, but the article confidently asserts that the unit is given as "lb/ft2 or kg/m2, and occasionally in N/m2" (and the "lb" is helpfully linked to "pound (mass)"). Please, would someone less befuddled work out what is going on. Also see disk loading where a similar concept and units apply. Johnuniq (talk) 11:23, 16 October 2013 (UTC)
Perhaps if we take turns sleeping one day per week, we might fix all these problems! -Wikid77 (talk) 14:29, 16 October 2013 (UTC)
I have not had a chance to think about the situation since last posting here, but I have read wing loading and now see that rather than weight/area = force/area, it really is mass/area (a factor in an equation). So, I was wrong to think it was pressure, and {{aircraft specs}} will not need any change, and kg/m2 + lb/sqft will remain as mass-per-unit-area. I'll need a day or two to think about the locomotive articles which are using kg/m2 as pressure. Other changes will be needed if sanity is to be preserved; for example, the pressures kg/cm2 and lb/in2 should probably be changed to kgf/cm2 and lbf/in2. Johnuniq (talk) 10:17, 17 October 2013 (UTC)

Keep in sync with world measurements

We need to keep the units in line with the way the world uses the terminology, and make the template auto-adjust in cross conversions. The core conversion could be:

  • 1.0000 atm = 14.6959488 pounds force per square inch
  • 1.0000 atm = 2,116.21662 pounds force per square foot (as 122×14.7)
  • {convert|1.00000|atm|psi}} → 1.00000 standard atmosphere (14.6959 psi)
  • {convert|1.00000|atm|lbf/sqin}} → 1.00000 standard atmosphere (14.6959 lbf/sq in)
  • {convert|1.00|lbf/sqin|lbf/sqft}} → 1.00 pound-force per square inch (144 lbf/sq ft) [=144!]
  • {convert|1.00000|atm|lbf/sqft}} → 1.00000 standard atmosphere (2,116.2 lbf/sq ft)
  • {convert|1.00000|atm|lb/sqft}} → 1.00000 standard atmosphere (2,116.2 lb/sq ft)

FIXED: I put outer parentheses brackets in factor "b=((45359237/9290304)*9.80665)" inside Template:Convert/lbf/sqft. When all the b factors are correct, then 1.0 lbf/sqin = 144 lbf/sqft = 1.0 psi, and similar. Afterward, the subtemplates should use auto-correction and put a superscript note "[fix unit]" to indicate the problem in archived talk-pages, or older revisions of a page. -Wikid77 (talk) 14:12, 16 October, 14:59, 17 October 2013 (UTC)

Conclusion

Having changed my mind about what to do every day, a response from Redrose64 at the trains project has pushed me towards the "give the customer what they want" path. Wikid77's above suggestion to fiddle the scales has now been implemented so all the converts work. All the units which were "mass per unit area" are now "pressure", and I think all the converts are correct. The only issue is that, for example, "kg/m2" is now a pressure, when "kgf/m2" would be more correct. Examples:

  • {{convert/sandboxlua|1|kg/m2|Pa|5}} → 1 kilogram per square metre (9.80665 Pa)
  • {{convert/sandboxlua|70|kg/m2|Pa+psi|abbr=on|4}} → 70 kg/m2 (686.4655 Pa; 0.0996 psi)
  • {{convert/sandboxlua|0.007|kg/cm2|Pa+psi|abbr=on|4}} → 0.007 kg/cm2 (686.4655 Pa; 0.0996 psi)
  • {{convert/sandboxlua|1|g/cm2|Pa|4}} → 1 gram per square centimetre (98.0665 Pa)
  • {{convert/sandboxlua|1|g/cm2|N/m2|6}} → 1 gram per square centimetre (98.066500 N/m2)
  • {{convert/sandboxlua|1|lbf/in2|lb/sqft|2}} → 1 pound-force per square inch (144.00 lb/sq ft)
  • {{convert/sandboxlua|1|lb/sqft|Pa|2}} → 1 pound per square foot (47.88 Pa)
  • {{convert/sandboxlua|1000|lb/1000sqft|Pa|2}} → 1,000 pounds per thousand square feet (47.88 Pa)

The code changes were amazingly simple (convert diff and makeunits diff), although changing everything to pressue was more messy (conversion data diff). Johnuniq (talk) 06:32, 22 October 2013 (UTC)

Updating temperature ranges for requested changes

I am planning to update the temperature ranges, as Template:Convert/Dual/LoffAoffDxSoffT, to provide the following improvements:

  • fix to show unicode &minus sign in negative temperatures
  • add range word "to(-)" to show &ndash in output range
  • change to round convert of 100+ °F as 1-decimal C degrees

For years, users have asked for the true minus signs in negative temperature ranges, and I found a method to insert them without exceeding the template-expansion depth limit. Example:

  • Expected: {{convert|-10|to|-15|F|C}} → −10 to −15 °F (−23 to −26 °C)
  • Currently: {{convert|-10|to|-15|F|C}} → −10 to −15 °F (−23 to −26 °C)
  • Expected: {{convert|103|to(-)|105|F|C}} → 103–105 °F (39.4–40.6 °C)
  • Currently: {{convert|103|to(-)|105|F|C}} → 103 to 105 °F (39–41 °C)

If there are no other requested changes, then I will update that subtemplate after midnight UTC. -Wikid77 (talk) 18:12, 18 October 2013 (UTC)

10 to 15 K (−263.1 to −258.1 °C; −441.7 to −432.7 °F) Hawkeye7 (talk) 20:16, 18 October 2013 (UTC)
  • DONE. I have fixed the &minus for negative temperatures in ranges, and improved precision for 3-digit numbers. Note with Lua version:
  • Now: {{convert|103|to(-)|105|F|C}}                → 103 to 105 °F (39–41 °C)
  • Lua: {{convert/sandboxlua |103|to(-)|105|F|C}} → 103 to 105 °F (39–41 °C)
The unit "K" now defaults to "°F" in ranges, but {convert/2} can be used to show both "°C °F". -Wikid77 (talk) 04:14, 19 October 2013 (UTC)

Islamic calendar

Any demand for this? Andy Dingley (talk) 15:20, 19 October 2013 (UTC)

try {{#time: xij}}, {{#time: xiF}}, {{#time:xiY}}, {{#time: xmj [[xmF]]}}, {{#time:xmY}}, etc. Frietjes (talk) 16:20, 19 October 2013 (UTC)
Thanks, I'll give it a go. Andy Dingley (talk) 18:13, 19 October 2013 (UTC)
No joy I'm afraid. These are formatting, not conversion (AFAICS) so they take a time data type (which is something UTC-ish, i.e. Gregorian) and then punt it out as hijri. However I have article text from a hijri source that I'm looking to convert to Gregorian. Andy Dingley (talk) 18:27, 19 October 2013 (UTC)
  • Date conversions are an interesting topic: So, I think there might be more interest, beyond our simple date/time conversions. Years ago, I made a simple date conversion for day-of-year, as: {{convert/old|5 Aug|date|day}} → {{convert/old|5 Aug|date|day}}. Plus we have 12/24-hour time: {{convert/old|9:23 pm|time|24}} → {{convert/old|9:23 pm|time|24}}. However, for articles which cross events from the Catholic culture to other calendars, then the date-conversion would be useful, and currently an editor would forced to cite a website which does Gregorian-Julian-Hijri conversions to note the equivalent dates: 28, Azar, 1403. Because the Lua version prevents date conversions, then we would modify the {convert/old} to keep expanding our coverage of dates. Meanwhile, Template:Inflation handles some major currency conversions. -Wikid77 (talk) 20:48, 19 October 2013 (UTC)
Is a hijri year exactly the same length as a Gregorian year? (ie. is there no seasonal creep over time) I know that the month boundaries are somewhat fluid, and this means that an accurate conversion needs a bulky ephemeris table. However most of our need is just for year conversions and they might be very simple: just a couple of conditionals and the relevant offsets. Andy Dingley (talk) 21:53, 19 October 2013 (UTC)
Be aware that the start of months in the Islamic Calendar is based on sightings (by designated officials) of the new moon, so all mathematical conversions are liable to be off by one or two days, no matter how good your ephemeris is. (Also the year is about 11 days shorter than the Gregorian, but this does not cause mathematical difficulties.) Indefatigable (talk) 20:05, 20 October 2013 (UTC)

New compound unit "hand in" to show hands/inches

The new unit-code "hand in" is a special, custom combination to show horse hands and inches as full unit names, rather than the typical abbreviated symbols with output amounts. Examples:

  • {convert|77|cm|hand in}}                → 77 centimetres (7.2 hands; 30 in)
  • {convert/2 |77|to|88|cm|hand in}}    → 77 to 88 centimetres (7.2; 30* to 8.3 h; 35 in*)
  • {convert/2 |77|to|88|cm|hand in|2}} → 77 to 88 centimetres (7.2+1⁄2; 30+1⁄2 to 8.2+1⁄2 h; 34+1⁄2 in)

Due to the complexity of rounding to fractional inches, the range only works in {convert/2} not in {convert}. -Wikid77 (talk) 21:36, 19 October 2013 (UTC)

New unit-code "ftinfrac" to show ft/inches with fraction

The new unit-code "ftinfrac" (like "ftin") converts to feet and fractional inches, with a quarter-inch (1⁄4, 3⁄4) or half-inch fraction. The unit-code is new, and was not in the original Lua version. Examples:

See Template:Convert/ftinfrac for more examples. -Wikid77 (talk) 21:36, 19 October 2013 (UTC)

Ranges

I noticed that the templates do something that is inconsistent but good with a range involving ftin, as shown in this table (which shows " " where a space occurs).

Convert Result Range in output
{{convert|2|by|9|m|ft}} 2 by 9 metres (6.6 by 29.5 ft)  by 
{{convert|2|by|9|m|ftin}} 2 by 9 metres (6 ft 7 in by 29 ft 6 in)  × 
{{convert|2|x|9|m|ft}} 2 by 9 metres (6.6 ft × 29.5 ft)  × 
{{convert|2|x|9|m|ftin}} 2 by 9 metres (6 ft 7 in × 29 ft 6 in)  × 
{{convert|2|to|9|m|ft}} 2 to 9 metres (6.6 to 29.5 ft)  to 
{{convert|2|to|9|m|ftin}} 2 to 9 metres (6 ft 7 in to 29 ft 6 in)  to 

There are two minor issues:

  1. Using "by" results in "by" for most units, but "×" for ftin.
  2. Using "x" gives a space before "×" for most units, but a nonbreaking space for ftin.

Both of these seem desirable and I'm wondering what the module should do.

Re #1: I don't think the way "by" works should magically change if the output happens to be ftin (or other output multiple unit), and I'm thinking there should be a new word to use for those who want "by" for the input and "×" for the output. Simplicity is good so I was thinking of "byx".

Re #2: Perhaps " × " should be used instead of " × " for all units?

Any thoughts? Johnuniq (talk) 03:55, 21 October 2013 (UTC)

Well, because "x" produces by...x, then "xx" is for x...x, and I think an option like "byx" could confuse. The wrapping at "×" should be after as punctuation, as with wrapping after a comma, not before. Thanks for checking the wrapping. More later. -Wikid77 (talk) 17:39, 21 October 2013 (UTC)
Thanks, I've gone nuts and somehow missed that "x" does what my postulated "byx" would do, so I'll forget about byx.
I'm happy with "by" producing by...by always (whereas the current templates give by...x for multiple units like ftin), so the only issue concerns where the nbsp should be. Johnuniq (talk) 22:10, 21 October 2013 (UTC)

koilbbl/d→tonne

This 500 thousand barrels per day ([convert: unit mismatch]) ({{convert|500|koilbbl/d|tonne}}) seems a bit (very) off. Is there a division by 1,000 happening instead of a multiplication? —Sladen (talk) 10:32, 23 October 2013 (UTC)

  • FIXED or use "500,000|oilbbl" for now: Definitely a problem, but this might take a while to debug, so meanwhile use:
The conversion with "koilbbl/d" seems was off by 80,000 or such. The correction in conversion factor b should be accurate to 16 digits now. -Wikid77 (talk) 15:26/15:49/16:18, 23 October, 14:15, 25 October 2013 (UTC)
How can you convert barrels per day to tonnes? Shouldn't it be tonnes per day? -- WOSlinker (talk) 19:09, 23 October 2013 (UTC)
It's essentially the same, as an ellipsis. -Wikid77 14:52, 24 October 2013 (UTC)
Also {{convert|1|koilbbl/d|m3/d}} → 1 thousand barrels per day (160 m3/d) doesn't produce the correct figures. -- WOSlinker (talk) 19:14, 23 October 2013 (UTC)
Fixed to also handle unit-code as "m3/d". -Wikid77 14:15, 25 October 2013 (UTC)
right, Barrel (unit) is volume, so oilbbl/d would be a volumetric flow rate. Frietjes (talk) 19:42, 23 October 2013 (UTC)
So, we need to re-define the units with a new base unit, for b=1, where all the cross-conversions will match. This is similar to "atm" pressure: 1 standard atmosphere (15 lbf/sq in), same as psi. -Wikid77 (talk) 14:52, 24 October 2013 (UTC)
You can't really convert a barrel to a mass without specifying whet the contents are. See Barrel (volume)#Oil_barrel, specifically "Since different varieties of petroleum have different densities, however, there isn't a single conversion between mass and volume. For example, one tonne of heavy distillates might occupy a volume 256 US gallons (6.1 bbl). In contrast, one tonne of crude oil might occupy 272 gallons (6.5 bbl) and one tonne of gasoline will require 333 gallons (7.9 bbl)." -- WOSlinker (talk) 15:12, 24 October 2013 (UTC)
In those cases, we can omit the conversions, which were over-zealous for the topics. -Wikid77 (talk) 15:21, 24 October 2013 (UTC)

Delinking Na subtemplates

I have finally simplified most non-abbreviated unit-codes to omit the hundreds of "-Na" subtemplates, such as for acre, furlong, and dram, which do not use internal parameter {{{u}}}. This reduction has been ongoing for 2 years, where formerly over 51,400 pages had used Template:Convert/LoffAoffDbSoffNa and related "-Na" subtemplates. The affected unit-codes include more than 40:

dunam, board foot (board feet), Lcwt, Scwt, t_Scwt, kg_Scwt,
winecase, tonTNT, ktTNT, TtTNT, MtTNT, MtonTNT, GtonTNT, TtonTNT,
LT, ST, LT_ST, ST_LT, LT_t, ST_t, t_LT, t_ST, STf, LTf,
acre, chain, furlong, mil, troy_pound, dram, rood,
arpent, sq_arp, verst, sqverst, dönüm, Cypriot dönüm,
pyeong, tsubo, tsubo_sqft, sun, thou, etc.

Because there are so many unit-codes which omit {{{u}}}, the reduction has taken years to implement, while changing the underlying Convert subtemplates to detect a null {u}. There might still be some cases which show an undefined "{{{u}}}" and those subtemplates can be corrected to display values of parameters {n}, {l}, or {h}. -Wikid77 (talk) 15:21, 24 October 2013 (UTC)

Convert/text3 - simply free-form conversions

The "next generation" of conversions includes the use of free-form text, rather than the prior constrained pairs or ranges of numbers. Now, Template:Convert/text3 allows the insertion of free-form descriptive text which is omitted in the results portion. Example:

  • {{convert/text3 |6|across by|2|deep at the base and|4|m|ft|high at the top}}

    → 6 metres across by 2 m deep at the base and 4 m high at the top (20 × 6.6 × 13 ft)

Note how all the input text is omitted, from the output portion, which defaults to simply show "×" separators. However, new output parameters "out=" or "out2=" or "out3=" allow specifying the alternate text to show between the result amounts.

  • {{convert/text3 |6|across by|2|deep at the base and|4|m|ft|high at the top|out=across,|out2=ft deep,|out3=high}}

    → 6 metres across by 2 m deep at the base and 4 m high at the top (20 across, 6.6 ft deep, 13 ft high)

Before the advent of {convert/text3}, and {convert/text2}, a conversion of a set of numbers (a range) would repeat the input separator-text between the output units, but now {convert/text3} allows a free-form mode which can insert extra description, while omitted in the results, or allows totally unique wording to be inserted among the output amounts. Beyond the major parameters, new options x0-x14 allow custom text to also be inserted between any numbers/units anywhere. These free-form conversions are designed to also work with the Lua-based Convert. The overall goal is to allow more flexibility in wording, as users have requested for tiresome conversions, beyond the monotonous prior forms of: amount (converted), amount (converted), amount (converted), etc. More later. -Wikid77 15:16, 25 October 2013 (UTC)

A snag

For SR USA class: {{convert|41|ST|9|Scwt|lk=on}} 41 short tons 9 hundredweight (37.6 t). Can some one fix this? Peter Horn User talk 21:00, 27 October 2013 (UTC) Peter Horn User talk 21:02, 27 October 2013 (UTC)

fixed. Frietjes (talk) 17:21, 28 October 2013 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_October_2013&oldid=1138527574"