Inverted units

As discussed at #DPI and dots/cm and micrometres per dot, GliderMaven added some units to Module:Convert/extra that have an "invert" property, and proposed a change to the module's convert routine. I have implemented that change in the sandbox, and have tweaked the extra units (see Module:Convert/sandbox and Module:Convert/extra/sandbox). Please carefully check the changes and let me know if anything has gone wrong.

For units pitch and dpcm I simplified the link from Dots per inch#Proposed metrication to Dots per inch because the latter is adequate, and the former will become obsolete when someone changes the section heading, and the topic is not sufficiently important to warrant an anchor with the rather dated text of "Proposed metrication".

In some of the scales, I changed 9.8066 to 9.80665 because the latter is the value used by other units referring to g, and they may as well be consistent even if the extra precision is meaningless.

I omitted the "invert = 1" fields because they are not needed as the module assumes that value if converting with a unit with "invert = -1" and "iscomplex= true", and "invert = 1" is not needed when converting with other kinds of units. Eventually the new units need to be added to the master list, but that cannot happen until I have updated makeunits to handle these units. I'm thinking that putting "invert" in the "Extra" column will cause makeunits to set "invert = -1" and "iscomplex= true", and that might be the only change needed.

The pitch unit has a default output of dpi, but it also has symbol µm, and that conflicts with the default exception for µm. As a result, pitch has a default output unit of inches.

Following are the converts provided as examples by GliderMaven, using the sandbox modules.

We will need to discuss the unit types again because I still think that converting, say, DPI to furlongs is undesirable. Actually, converting DPI to inches is pretty bizarre. The alternative would be to use a unit type like "dotlength" and provide whitelisted exceptions that allow some units of type length to be converted to/from dotlength. A similar consideration applies to the other new units, although they are much more esoteric, and there may be less argument. Any thoughts on this are welcome, but given the time of year, I'm not sure that it will be possible to sort out all the details so that the new units are incorporated into the master list by the time the modules are upgraded in a week or two. Johnuniq (talk) 11:34, 28 December 2013 (UTC)

The inverted units seem reasonable, as implying the result is "per one (thing)" and so I think it should work ok. Meanwhile, I have created the opposite Template:Convert/per for the direct conversions per inverted unit; see "#Template:Convert/per for inverse units". -Wikid77 14:19, 28 December 2013 (UTC)
You say that: The pitch unit has a default output of dpi, but it also has symbol µm, and that conflicts with the default exception for µm. As a result, pitch has a default output unit of inches. which would seem to be a bug in convert; it should be using the default conversion of the unit you start with not the default of the symbol of the unit.GliderMaven (talk) 20:09, 29 December 2013 (UTC)
At the moment I'm just reporting the facts, and looking for confirmation that the changes I put in the sandbox are correct. The default output business applied before the changes, and I'm just explaining why that currently does not work. The main reason that defaults work the way they do can be seen by browsing the "default exception" link I gave earlier—an SI unit is defined once, and all the variants formed with an SI prefix are handled automatically, but that requires some magic to define exceptions for defaults and links. No doubt a method could be devised to handle the DPI situation, but that has not happened yet. Johnuniq (talk) 22:13, 29 December 2013 (UTC)
I have worked out how to accommodate the fact that the "pitch" unit has the same symbol as micrometer, and have updated the sandbox. The new trick will later be implemented by makeunits when that gets fixed. Before the change, the following convert linked µm to Micrometre, and used inch for the default output.
  • ((convert/sandbox|1|pitch|lk=on)) → 1 μm (25,000 DPI)
Johnuniq (talk) 10:04, 30 December 2013 (UTC)
Many thanks, that looks excellent. I haven't had a chance to check out the other changes in detail, I'll get back to you with my comments.GliderMaven (talk) 15:41, 30 December 2013 (UTC)

I have finally thought about GliderMaven's new units, and after a couple of minutes I came to the view that I could ponder it for a week and still think it was somewhat dubious but also potentially useful. On the principle that if a user wants to convert furlongs to DPI, who am I to stand in their way, I think the best thing is to just adopt GM's units without change. I have updated the sandbox with the units moved from "extra" to "data", and have put the necessary changes in the master list of units, and a couple of changes in makeunits to generate the new data. See the non-sandbox Module:Convert/extra for the original list list, and see the above examples. Some testcases are needed—I guess the examples will do, although I have not checked that the values are correct and am relying on GM for that. Johnuniq (talk) 01:12, 4 January 2014 (UTC)

That's basically how I think about it as well. The conversions data I came up with are a bit sneaky but cover all the likely types of conversions people might want to do. If people end up wanting to do furlongs to dpi, they're a bit mad, but it gets the 'right' answer. It's better to cover even the mad conversions than not covering (say) dpi to mm, which I have seen people do on the web. There was an alternative I spotted where you have "mm" twice, once as a dotlength in addition to the "mm" as a length, but it seems redundant and may require more changes to convert. Anyway, it works as is.
The only thing I've noticed is that the old and less capable and almost completely unused "lb/h.lbf" and "g/s.kN" units in Module:Convert/documentation/conversion_data/doc#Thrust_specific_fuel_consumption are now apparently no longer needed. I checked and found just one use of them in General Electric YJ93, which I switched over to "tsfc" and the end result looked entirely equivalent (although trivially different, for example the h.lbf switched to lbf.h.) So is it OK for me to delete that section?GliderMaven (talk) 02:26, 4 January 2014 (UTC)
Those examples should be reasonable testcases, those were the ones I was using as sanity checks when I was writing the conversion data.GliderMaven (talk) 02:34, 4 January 2014 (UTC)
I guess the old units can be removed. At 4 December 2013, the only article to use those units was General Electric YJ93 which you have updated. A defect of the module is that we have no way of knowing whether the other units are used. When the module is switched to use the sandbox (actually a couple of weeks after, when the pages are finally reformatted), if the old units appear in the unknown units category, we can add aliases (lb/h.lbf = tsfc and g/s.kN = si tsfc) to the extra module. While deleting old units is scary, it would be pretty confusing to keep them and the new units. FYI I have a tab-separated values file with all the units because it is easier for me to make bulk changes to that file. A script translates that file into the wikitext for conversion data, and when someone edits that page, I update my file to match. So, to cut out the middle man I have just removed the section myself. I intend to drop my local master file in due course, but I'm still finding it useful. Johnuniq (talk) 09:15, 4 January 2014 (UTC)

Module version 2

I have uploaded new versions of the sandbox modules for testing and comment. A convenient list of the modules is at the top of the documention seen when viewing Module:Convert/sandbox. Use ((convert/sandbox)) to invoke the sandbox modules to try the new version. Depending on whether any problems are found or enhancements suggested, we could consider moving the main modules to the new version on, say, 6 January 2014.

New features:

I will finish some documentation for the new features in due course. These changes are rather massive, and I'm hoping any modifications needed in the next couple of months will be minor. Interestingly, frac=N is used in a few articles, for example Sebastian Bayer. It's an awkward time of year, but any feedback from testing would be appreciated. Johnuniq (talk) 09:48, 24 December 2013 (UTC)

I probably won't write more hands documentation for a while. Meanwhile, perhaps Justlettersandnumbers and Montanabw could use the above to experiment and see whether whether fixes are needed. Johnuniq (talk) 10:30, 24 December 2013 (UTC)

Thanks, Johnuniq, you seem to have done all that was asked/suggested and more too. I had a very quick look, and all seems to function as expected. One niggle (not confined to this template) is the intrusive space between an integer and a following diagonal-slashed fraction; scientific fractions display correctly (here, but not in ((sfrac))):
  • ((convert/sandbox|155.8|cm|hand|frac=4)) → 155.8 centimetres (15.1+1⁄4 hands) (reads 15.1 1⁄4; should read 15.11⁄4)
  • ((convert/sandbox|155.8|cm|hand|frac=-4)) → 155.8 centimetres (15.1+1/4 hands) (reads correctly)
Many thanks for all your work. Justlettersandnumbers (talk) 21:42, 24 December 2013 (UTC)
I second this accolade. Justlettersandnumbers, is the space-issue you describe for the hand unit only, or for all fractions written wiith "/"? (If general,I think it should be changed through MOS:FRAC, and its supporting template ((frac))). -DePiep (talk) 11:01, 26 December 2013 (UTC)
As DePiep and some others already know, I have started a discussion of this typographic detail at Wikipedia talk:Manual of Style/Dates and numbers#Spacing of mixed numbers, as DePiep suggested. Justlettersandnumbers (talk) 18:29, 27 December 2013 (UTC)
The discussion has delivered a change in the space usage. -DePiep (talk) 05:22, 29 December 2013 (UTC)
Mentioned at VPT, #noref_tagging. -DePiep (talk) 07:25, 27 December 2013 (UTC)
Good, but since writing the above I have implemented a workaround. Module:Convert/sandbox now has some code (at "function message") that removes any strip markers encountered. I still have one weird problem because the message syntax is slightly broken by a wikilink in the input. I have looked at the issue quite hard and it looks like a quirk, and I have decided that the problem can be ignored as it is minor and may never occur. Following are some examples (mouseover the link to see the error text).
The following wikitext is the essence of the problem in the previous line (] is "]").
  • [[Example|<span title="Value bad&#93;&#93; must be a number">invalid</span>]] → invalid
A mouseover of the message in the last line shows "Value bad</a> must be a number". Actually previewing this post shows it is even weirder than I realized. Johnuniq (talk) 09:23, 27 December 2013 (UTC)
  1. ^ xyz1
  2. ^ xyz2
  3. ^ xyz3
Tried to separate by layout topics "hands" from "ref". -DePiep (talk) 21:06, 28 December 2013 (UTC)
Montanabw. I made testcases. Please take a look. I could not get ((Hands/sandbox))working correctly (counting unnamed parameters for Lua?) -DePiep (talk) 05:25, 29 December 2013 (UTC)

Module v2: fractions

I am not complaining, I was happily surpriosed with that speed. It's just that established editor TheDJ only a few hours before had noted that there would be a hack compromise always. So I was glad to see that nullified by EDokter. -DePiep (talk) 11:32, 3 January 2014 (UTC)

I have updated the sandbox for the new fraction style. I decided to make the output exactly the same as that produced by ((frac)) and ((sfrac)) for now. That means that the module now outputs &frasl; instead of the Unicode character which a wikignome had put in the module, and that ((uc: ((convert|...with fractions...)) )) will break (Wikid77 pointed out that the uppercase parser function outputs junk if given certain html entities as input). Special:ExpandTemplates can be used to confirm that the output from the following matches the new style.

Johnuniq (talk) 10:09, 30 December 2013 (UTC)

Module v2: hands

Ouch. You will have thought of other routes. Is it worth me thinking aloud, or are other solutions nigh impossible for now? -DePiep (talk) 02:39, 29 December 2013 (UTC)
I agree that a multitude of units is confusing and ugly, but I could not see any reasonable alternative. A person interested in horses would instantly understand what "handlk" or "hhand" does (after seeing it), and would rarely need to remind themself how it's done. Some options could be added to achieve the same result, but I suspect they would be more confusing, and would make the convert wikitext significantly longer. However, ideas are welcome. Johnuniq (talk) 05:44, 29 December 2013 (UTC)
I will admit that at this point, my mind is thoroughly boggled by the minutae of syntax! ;-) So your test page is a little hard for me to properly review. But I will note:
  1. Keep it simple, horse editors are simple people! LOL!
  2. I don't think {hands} is broke, for what it does, so I presume it doesn't need fixing?
  3. Horse people almost always use the plural, hands, as no equine is 4 inches high. So I kind of favor keeping it that way, though I won't fuss terribly if there is some highly logical reason to use the singular form. But I think almost every use is "hands" and the output needs to default as reading "hands" (save for, obviously, the abbreviations)
  4. {hands} is used widely and is the far more common hands conversion template used on en.wiki; thus, Convert/hand or convert/hands is not needed for simple hands to-inches-and-cm conversions; convert/hand and convert/2 will be used only where {hands} cannot be used, mostly for those articles where the preferred measurement is given in cm first and so needs conversion to hands and inches. There is one active member of WPEQ who has a need for this feature at present, but it's a legitimate need for those times that it matters, i.e. the FEI rules (international competition) largely use metric measurements for horse/pony determination, so yeah, it will pop up from time to time. Given the commonality of a measurement range in the horse breed articles, convert/2 will get a lot of use once it is finished, convert/hands probably less than convert/2, actually
  5. It is helpful on all templates if "hands" is wikilinked to the hand (unit) article by default, or at least an on/off parameter so we can have it linked on first use, even if we suppress it later in the same article (most times, the template will be used only once in the "characteristics" section, though in some of our longer FAs, it may be used more than once, e.g. twice at Appaloosa#Breed_characteristics and 6 times at Thoroughbred.
  6. What is "handlk, hhandlk, hhand"?? Gibberish to me... I'm not a techie...
  7. No opinion on the space before fractions issue, that's general MOS as far as I am concerned, whatever is decreed, we at WPEQ shall follow

Am I making sense? Hope so! All for now! Montanabw(talk) 22:41, 29 December 2013 (UTC)

There are examples at "New units include the following variations on hands" above. To keep all this together, I am repeating those examples here:
Suppose an article converts the hand unit four times—if hand defaults to linking, it would be necessary to do something special three times to avoid overlinking. This was discussed in October, and I offered the suggestion that "handlk" should be used when a link is wanted, and plain "hand" when not.
Everything is gibberish when first encountered, and all we need is for someone to say what is wanted. If "hhand" is too weird, what is preferred? There could be an option with a comma-separated list, so it would be possible to write |hand=link or |hand=hh,link or whatever. Or, unit "hand" could always link except if |lk=off is used. Please write some examples of the wanted syntax for all wanted outputs. If anyone at WP:WPEQ might have an opinion, please notify the project (or, post the examples at the project and link to it from here).
Re plural/singular: Is there a problem? Converting 4 inches to hands would give a singular output, but that will never happen in a horse article, so it should not be a problem? Also, there may be some legitimate need to write an adjectival phrase as in "a 12-hand horse", so the singular is needed. Johnuniq (talk) 00:32, 30 December 2013 (UTC)
In most cases, the {hands} template is already in use (I think about 250+ of the 350+ horse breed articles on wiki). Whichever template is used will generally be used once, to say the breed standard's average or preferred range of heights. Thus:
  1. the default should be output that says "hands" spelled out and linked, yes, unit "hand" should always link except if |lk=off is used.
  2. Inches and hands will usually round to the nearest inch (15.1 h, 61 inches); sometimes they will BOTH need to round to the nearest half inch (15.1-1/2 hands, 61.5 inches) and on extremely rare occasions, round both to a quarter inch (to my knowledge, this was used once on all of wikipedia and then the hands template was all that was needed). No other rounding is really necessary.
  3. I think we want something like this as the default: ((convert/sandbox|137|–|156|cm|hands in)) → 137–156 centimetres (13.2–15.1 hands; 54–61 in) <--except this needs a link to hands, like this: 137–156 centimetres (13.2–15.1 hands; 54–61 in)
  4. After that, some people prefer to keep saying "hands" each time, others will use "h" and fewer still will use "hh", so I think the best solution is to allow the user to just plug in their preferred abbreviation, i.e. saying something like ((convert/sandbox|137|–|156|cm|hands in|abbr=h)) → 137–156 cm (13.2–15.1 h; 54–61 in)
  5. And the abbreviation doesn't have to link, but no cosmic problem if it does if we can just do link=off
  6. The adjectival phrase issue is a red herring; it can be avoided with proper rewording ("Mr Ed was a 15-hand horse" would be better stated, "Mr. Ed. stood 15 hands"), or if a quote from a poem or something, the writer doesn't need to convert, they can just link to the article.

Am I making things clearer? Montanabw(talk) 06:25, 30 December 2013 (UTC)

Re #2: What does "BOTH need to round to the nearest half inch (15.1-1/2 hands, 61.5 inches)" mean exactly? What if the value is 61.4 inches? Are you saying that should be rounded to 61.5? In other words, the inches value should exactly match the value displayed for hands, even if the inches value is slightly incorrect?
Re #3 and #4: Is the following correct:
By default, output "hands" for hands, and "in" for inches.
If |abbr=off is used, output "hands" for hands, and "inches" for inches.
If |abbr=out or |abbr=h is used, output "h" for hands (not linked), and "in" for inches.
If |abbr=hh is used, output "hh" for hands (not linked), and "in" for inches.
Except, if |lk=off is used, no units would be linked.
Except, if |lk=on is used, each unit including inches would be linked.
Re red herrings: a program has to do something when input is presented. If someone converts 4 inches to hands, or if they use |adj=on, the unit name will be "hand" (singular). I guess there is no problem with that, and you are just saying that the user should not be entering these values—a discussion we need not enter. Johnuniq (talk) 10:34, 30 December 2013 (UTC)
Smiles! Basically, I get what you are saying about the fictitious 4-inch My Little Pony standard that might be needed somewhere! So OK. Re #2 yes, we don't need the precision of 61.4 inches (furthermore, inches are usually measured in 8ths, not 10ths anyway), and if your output rounds to 61.5 inches, then you also need to say 15.1-1/2 hands also ( though it would work equally well (if not better) to say 61-1/2 inches if it's too complicated to do both decimals and fractions). My personal view is that {hands} can easily cover the rare cases of the 14.1-3/4 inch horse and therefore the cm-first conversion can just round to the nearest half-inch, as I don't think there exists a breed standard or FEI measurement that is more refined than the centimeter anyway. And, it is primarily a need in the FEI pony rules where the standard allows an in-competition measurement deviation of 2 cm to account for hoof growth(!) Re #3 and 4, yes, I think you've got it; I presume if no abbr parameter is used, then hands, linked, will default, yes? I have no position on "in" versus "inches" and shall defer to whatever standard procedure is around here.
In the testcases I was just testing the options for hands. I raked together various hand's documentation pages. ((hands)) is not broken, but after a conversion it will enjoy the whole {convert} option suite as documented. I will not add to the hands thread here for reasons Johnuniq mentioned (it would be distracting). -DePiep (talk) 11:39, 3 January 2014 (UTC)

Module v2: hands final results

Would Justlettersandnumbers and Montanabw please examine how the module handles hands—I think it's doing what was asked, but I may have overlooked something.

See Help:Convert units#Hands for documentation, and please check that the text and examples achieve what is wanted. One of the examples shows eighths of an inch. I know that is meaningless for a horse, however |frac=8 works with all units, including hands. Outputs from ((convert)) and ((hands)) are very similar; the latter provides some options that are not supported by convert, but those options do not appear to be used.

The following changes have occurred.

Johnuniq (talk) 06:46, 2 January 2014 (UTC)

Many thanks, Johnuniq, for all the time and energy you've put into this. A quick glance shows everything working as expected, and in as simple and accessible a way as could reasonably be expected. Justlettersandnumbers (talk) 10:49, 2 January 2014 (UTC)
I think it all works. Now, can you put the material at the help page above somewhere into the instructions at {Template:Convert/hand} and make that template the stop off for anyone who needs more than exists at {hands}?? I would be so grateful, even if you just pop it onto the talk pages of both templates. Seriously, I will never find it again otherwise... and I just do not get how to do all this stuff, so any help, just one more time, would be appreciated! Montanabw(talk) 21:46, 3 January 2014 (UTC)
You are suggesting that the link Help:Convert units#Hands be added as a "see also" in the documentation shown at Template:Convert/hand? We'll have to wait until the module is updated from the sandbox (in a week or two) so the examples do not include "sandbox". I don't want to put the content of Help:Convert into that page as it would be very much the wrong place—I suppose you and a few others are used to looking there, but that page is part of the old template system and is probably not easy for people to find, unless you have some links to it on horse-related pages. Johnuniq (talk) 02:11, 4 January 2014 (UTC)
Well, not necessarily, I was thinking that SOMEWHERE on the template page -anywhere appropriate - we need directions for how to use the thing. If it isn't supposed to go in the mainspace for the template, can we at least put it on the talk page, then? You cannot imagine how difficult and intimidating this whole area is for those of us who are primarily content creators/researchers and don't know any computer programming. The documentation is often complete gibberish to my eyes (that's not a criticism of you, it's a criticism of me!) And I say this as a wikipedian of seven years' experience - I can still barely format a table, and even then I have to copy someone else's and ask a techie to review it for me. I just want to magically put in {convert/hands} or {hands} and have it all just do its thing. Montanabw(talk) 20:03, 4 January 2014 (UTC)
By "on the template page", do you mean in the documentation shown when viewing Template:Convert? That would be very desirable. However, I recommend that people stop thinking about Template:Convert/hand because that is part of the old system, and is not used by ((convert))—editors should use ((convert)) or ((hands)) but not ((convert/hand)). In addition, something should be added to WP:WikiProject Equine#Other templates. I'll do that if you like, and you or someone can fix it as wanted. Johnuniq (talk) 02:49, 5 January 2014 (UTC)
I guess so. I have no idea about the old or new system, I just need someplace for the parameters to be parked for those few times I use anything but {hands} (which I use constantly) because I always forget how to do it right. If Template:Convert has documentation for everything else, then yes, I suppose both {Hands} and whatever we use instead of {convert/hand)) ( now I'm completely confused, I thought that was the template that was just fixed, but oh well) Yes, placement at the project page would be terrific in addition to being with the convert templates. Just make it logical and easy to find when we say, "oh crud, I need to do a cm to hands and inches conversion, now how does that damn template work, again??" Montanabw(talk) 06:33, 5 January 2014 (UTC)
Let's wait for a week or two until the module is updated from the sandbox. Then I will fix the module documentation to remove mentions of "sandbox", and will put something at the wikiproject page. I'm thinking there should be a very short section with two links (one to the module docs, and one to the ((hands)) docs), and with, say, four examples showing what is done most often. If that's desirable, perhaps you would list suitable examples—not proper syntax, but like "convert hands to inches and cm". Johnuniq (talk) 08:58, 5 January 2014 (UTC)

OK, I think this covers it, but @Justlettersandnumbers: if there is anything else needed:

  1. Convert hands to BOTH inches and centimeters (default use of {hands} template) i.e. ((hands|15)) = 15 hands (60 inches, 152 cm) default linking hands, and spelled out
  2. Convert centimeters to BOTH hands and inches (will probably be most common use of new version of convert/hands template) ((convert/sandbox|156|cm|hand in)) =156 centimetres (15.1 hands; 61 in) (or whatever "sandbox" becomes)
  3. Convert when given a range such as "from 14.1 to 15.1 hands" for all of the above.
  4. Provide parameters for all of the above to allow output in fractions of hands for those horses right at the top of their height class, notably ponies used n FEI competition. This probably will most often be seen with animals standing 14.1-1/2 to 14.1-3/4 hands.
  5. Allow suppression of linking after first use and allow abbreviations h and hh, as desired.
  6. I really don't see a need for conversion only between hands and inches, without metric or between hands and cm, without inches. if the solo conversion is inherently included in the model, OK, but we will be telling people not to do that.

That's all I can think of. Montanabw(talk) 08:33, 7 January 2014 (UTC)

Fraction as input

Please compare:

The bad example makes a calculation out of the input. Outcomes may not always be clear (clearly wrong) to the editor.

I suggest a rule like: when entering a negative number with a fraction, both number parts must have a minus sign or a hyphen. (Exception possible: when the integer is 0). The current example should produce a "wrong number" like error message. -DePiep (talk) 05:38, 29 December 2013 (UTC)

It's not an "equation", its a single number. We are talking {convert} input only. (Any calculation should be done before making it input; (e.g., using ((#expr:))).
Maybe this rule: when negative, both parts must have a minus sign.
-5+1/2 → Red XN
+5-1/2 → Red XN
+5+1/2 → number 5+1⁄2 Green tickY
-5-1/2 → number −5+1⁄2 Green tickY
0-1/2 → number −0+1⁄2 or −1⁄2 Green tickY (zero as the exception); but not −1⁄2 Red XN. I corrected: this is a negative number -DePiep (talk) 09:42, 29 December 2013 (UTC)
Within a fractional number, there can be no sign at all. 5+1⁄2 Green tickY, 5+-1⁄2 Red XN -DePiep (talk) 06:29, 29 December 2013 (UTC)
Yes, it's bizarre, but the module works like the above because I wanted maximum compatibility with the old templates, and that's what they do. The only "proper" fractional input looks like 1+2/3 or -1-2/3 or 2/3 or -2/3. But a program has to do something if weird input is entered, and as the template handled it in a logical manner (very impressively actually), I went to a fair bit of trouble to make the module do likewise. I suppose it could be changed so only the "proper" input is accepted, with others giving an error message. If you think the above is unusual, try this:
  • ((convert/old|1.23e+2+12/24|in|ftin)) →
  • ((convert|1.23e+2+12/24|in|ftin)) → [convert: invalid number]
As you can see, I drew the line at replacing the user input with the correct "123". Johnuniq (talk) 09:14, 29 December 2013 (UTC)
That was the honorable and right thing to do: reproduce the markup template. If I read you well, we could now take the next step of tagging these bad inputs for editing. So please do. Handling the more complicated, unusual input you gave, I'll leave it up to you. -DePiep (talk) 09:50, 29 December 2013 (UTC)
Johnuniq, if you read a condemnation or judgement in my OP, that was not the intention (I just tried to describe the issue precisely). I am just proposing to change the handling of those badly formatted numbers. I suggested to turn them into {convert} errors (with tagging & categorization by {convert}; so they can be checked & edited -- all fine). Also, from your reply I understand that you know the primary issue, and that can it be solved/changed. -DePiep (talk) 11:25, 3 January 2014 (UTC)
No problem—you would have to be a lot more direct (perhaps with some F-bombs) before I read something like the above as a condemnation. However, the code that parses the input number is tricky, and I'm inclined to let well-enough alone for now. It doesn't do anything wrong—it's just a bit bizarre, but it does the best that could be expected given the input, and follows the initial design. I might think about it later, but if the muse does not descend I would hope to defer it for another time. Johnuniq (talk) 02:20, 4 January 2014 (UTC)
Up to you about the change. I do disagree that there is "nothing wrong": the output fractions are numerically and formatted wrong or misleadingly ambiguous. I'm talking the simpler ones here, not the 123e example added. Not mentioned yet, but to ponder: example 5+-1⁄2 has kept the hyphen? Expected 5+−1⁄2. (Hey, I'm using a lot of those fracing words here). -DePiep (talk) 12:09, 4 January 2014 (UTC)
I'm pretty sure that the module always outputs Unicode minus for negative, but a quick test shows that ((frac)) does not. If you would care to remind me about this in a few weeks I'll have a look, but at the moment I'm not in the right frame of mind. I agree that it would be better to output a warning than to accept silly input, and the fix might be quite simple, but I currently don't feel like pondering the corner cases. Johnuniq (talk) 02:37, 5 January 2014 (UTC)
OK, take your time, til one of the muses returns to visit you. Urania would be the Muse of Lua, right? -DePiep (talk) 12:44, 7 January 2014 (UTC)

Plurilzation.

I am likelky just not seeing the right documentation but this particular rendering of: "...used in in the WWI era Wyoming-class battleships,[1] could only throw an 870 pounds (390 kg) shell 24,000 yards (21,946 m)..."(emphasis mine) from 12"/50_caliber_Mark_8_gun is particularly annoying. How do I get it to put pounds in singular? CombatWombat42 (talk) 21:19, 8 January 2014 (UTC)

Try adding adj=on, as in "...could only throw an 870-pound (390 kg) shell". It's not a matter of plurals as much as it's the "adjective" part of speech. - Denimadept (talk) 21:28, 8 January 2014 (UTC)

I must be overlooking something simple

Moved to Wikipedia:Lua requests, as it was intended. -DePiep (talk) 06:53, 29 December 2013 (UTC)
I still dont get this. If this means that the two convert sandboxes (module and template) work fundamentally different from the live versions, that should be changed. -DePiep (talk) 14:43, 9 January 2014 (UTC)

Automatic detection value as range

Now that ((Convert)) is using a real language in its back-end, could the single-value and range-of-values be consolidated? That is, Instead of having to say ((convert|60|-|170|kg|lb)), it seems like the module could recognize that the first parameter of ((convert|60-170|kg|lb)) looks like a range and handle it accordingly. This would make it easier to handle infoboxes that have a numerical field that the infobox then converts, for example, ((chembox)) melting points. Currently, there need to be separate fields for the two ends of the range, and also template logic to decide if ((convert)) should be called in the one-value or range-of-values way. Having it all in a single field take a single value or range is more natural for editors, and having the choice of modes handled in lua is surely no less efficient than in template-language. DMacks (talk) 02:52, 7 January 2014 (UTC)

I have been wondering about that—I'll have a look and hope to report back here within a day or two. I suppose we would want to support {convert|1-2|ft} and {convert|1 to 2|ft} and {convert|1 to(-) 2|ft} and {convert|1 or 2|ft} and {convert|1+/-2|ft} and {convert|1x2|ft}.
I guess that if the user omits the first value they would have to tolerate the strange result: {convert|-170|kg|lb} has a single negative number for the input. Johnuniq (talk) 04:49, 7 January 2014 (UTC)

Urania (mentioned above) must be hard at work because only 20 extra lines were required to do the following.

The last line shows that a negative fraction is still recognized. However, negative fractions cannot be used in a "simplified range" (((convert/sandbox|-1-2/3-4|ft|in)) does nothing useful).

Spaces are ignored, so "1 - 2" is the same as "1-2", and "1to2" is the same as "1 to 2". The range words can also be mixed up in weird ways: |1*2to3*4| and |1*2|to|3*4| do the same thing (I'm reporting what the code does, not making recommendations!).

While Wikid77 makes a valid point, I have thought that ranges should be easier to enter, and while "1-2" is evaluated as an expression by the old template, it is currently an "invalid number" error in the module, so it is already incompatibile.

@DMacks: Please test using {convert/sandbox} and let me know if it does what is needed. The changes will be live in {convert} when the module is updated from the sandbox in about a week. Johnuniq (talk) 03:59, 8 January 2014 (UTC)

Testing for signedness bugs...
Looks great! DMacks (talk) 02:55, 14 January 2014 (UTC)

Module v2 soon

I intend switching the module to use the sandbox version on 17 January 2014.

The changes may take weeks to become apparent as the job queue slowly grinds away (it is now 1,900,000, and an announcement at WP:VPT indicates that it may be particularly slow due to indexing for a new search engine), but please be alert to the fact that the new convert will be in action, and report any problems.

See #Module version 2 above for a list of many enhancements. Also included is the change in the way fractions (12+3⁄4) are formatted, use of "inverse units", new units from Module:Convert/extra, automatic detection of a range (((convert|1-2|ft)) is the same as ((convert|1|-|2|ft))), and various code tweaks. Finally, the most important change is a fix for the bug mentioned above which I have recently found is breaking some tables that use |disp=table with an output combination unit (the module currently puts all of the outputs in a single cell, whereas the fixed sandbox puts each individual output in a separate cell). I had hoped to do more work on the range rounding issue raised by Wikid77; the sandbox convert is doing better in that respect, but there are some corner cases that do not work well, although I have not seen any examples in articles that are a problem. However, that will have to wait for later.

GliderMaven and I are discussing some new units above, and if they stabilize in the next 24 hours I will include them in the main data. Johnuniq (talk) 01:08, 14 January 2014 (UTC)

  • ((convert|105|-|106|F|C))   -   105–106 °F (41–41 °C)
  • ((convert|892|-|893|lb|kg)) -   892–893 pounds (405–405 kg)
  • ((convert|326|-|327|m|mi)) -   326–327 metres (0.203–0.203 mi)
  • ((convert|63|-|64|in|ft)) -   63–64 inches (5.3–5.3 ft)
  • ((convert |77.3 |-|77.4 |lb |kg))   -   77.3–77.4 pounds (35.1–35.1 kg)
  • ((convert/old |77.3|-|77.4|lb|kg)) -   
  • ((convert/old |63|-|64|in|ft)) -   
Although the +1 precision can seem excessive at times, in the rare cases of 1-unit ranges, where needed, it is typically better. Many engineers have always used "+1" output precision, as a simple rule (discussed here years ago), but Convert has been more elegant in trying to retain (+0) the significant digits of the input amounts, unfortunately failing with 3-digit 105 °F as 2-digit result "41 °C". Long-term, the default precision should consider a range difference compared to the size of the conversion factor, but those cases are even more rare. -Wikid77 (talk) 07:03, 14 January 2014 (UTC)

Sievert

A recent edit at List of civilian nuclear accidents added ((convert|1.015|Sv|abbr=on)), but Sv (sievert) is not known to convert. Perhaps SkoreKeep (who added the convert), or GliderMaven (who recently worked on some exotic units), or anyone, would like to recommend how convert should handle this unit. Is it likely to be used more often, and so should be supported? What default output should it have, etc. It looks like Sv works with rem, and nothing else? So a new unit type would be needed ("radiation dose"—becquerel and curie are called "radioactivity")? In case anyone is wondering, issues like this appear in the error tracking categories Category:Convert invalid units and Category:Convert invalid options. Johnuniq (talk) 06:53, 9 January 2014 (UTC)

Well, the underlying unit is energy per unit mass, J/kg.
Looks like you'd want to convert to rem, and possibly banana equivalent dose if you want to get whimsical. 100 Rem = 1 Sievert is easy enough. Looks like that Rem conversion would be a decent default.GliderMaven (talk) 07:32, 9 January 2014 (UTC)
Yes, I agree. While the Roentgen and REM is deprecated, they're still widely used at the engineering, if not the science, level, and a default conversion would be welcome. Also Gray(Gy) <-> Roentgen (1 Gy = 100 R), just to be complete. Sieverts and Grays are rather large units, so milli- and micro- each are often used, while milliREM is as well. REM is an abbreviation for Roentgen Equivalent Man, so it's usually fully capitalized. The underlying unit for all of them is joules/kilogram, as stated above, but no one uses that. While Grays and Sieverts have the same dimensionality, they have different meanings based on what the effects are to a body (called dosage), and vary with the kind of radiation and where it is absorbed, so Grays aren't easily converted to Sieverts, and vice versa.
Bq and Ci are measurements of "amount of radioactivity". Roentgens and Grays are "radiation absorbed dose". Sieverts and REM are "radiation equivalent dose".
For the moment I removed all the Sievert and Gray conversions from the article. Thanks for your help, all. SkoreKeep (talk) 08:25, 9 January 2014 (UTC)
I've made a first cut at Gy, rem, mGy, mrem; rad and mrad and they should now be working.GliderMaven (talk) 16:11, 9 January 2014 (UTC)
Thanks, I was hoping someone would fix it. However, let's simplify and reduce the options. In an earlier discussion I recommended using "dpi" as the dots-per-inch unit code as it is common and easier than "DPI", but that reasoning is not useful for standard units where "Sv" is the only acceptable symbol. I think the user should be required to enter the correct "Sv" or "mSv" or "mrem", and the aliases should be removed.
Am I right in thinking that Gy and Sv should be marked as accepting SI prefixes? Use "prefixes = 1," to allow any of the SI prefixes to be used. Then, it would not be necessary to define mGy or mSv. Johnuniq (talk) 22:00, 9 January 2014 (UTC)
Yes. That apparently works with Sv, but I'm finding that Grays can cause a namespace issue or something, I haven't read the code, but I'm thinking that there's possibly a clash with Gigayears or something; convert currently crashes thusly:
* ((convert|10|Gray)) * 10 Gray[convert: unknown unit]
GliderMaven (talk) 00:29, 10 January 2014 (UTC)
Sorry, I forgot to mention that using "prefixes = 1" requires the special definitions shown in the docs at the top of Module:Convert/extra for the Joule example. That is, put an underscore in front of "symbol" and "name1". That's needed because a unit with an SI prefix does not have a fixed name—instead, it has to be constructed from the SI prefix and the base name (and the same applies to the symbol). Convert crashes when it uses _symbol because that is not defined, and my opinion is that making all those accesses bullet proof would not be worthwhile because the final error message would be likely to be as incomprehensible as "Script error".
That raises an interesting defect in how convert handles SI units because it appears I overlooked the possibility that an SI unit may not have a plural name. Currently, extra defines Gray and rad as using the same name for singular and plural. However, there is no "_name2" so the plural name will either have an "s" appended, or will not have the SI prefix prepended when required. I saw the edit summary that "Gy" conflicts with gigayear, but even if that meant "Gray" should be used as the symbol, the unit should still use "gray" for _name1 (and omit name2) so there could be 1 milligray or 2 milligrays. I think the symbol should be "Gy" and it's just unfortunate that the same symbol has a different meaning in another context. Johnuniq (talk) 01:42, 10 January 2014 (UTC)
OK, I fixed my _symbol and _name issues; that's a bit weird, but it's not disastrous, but few people write new units.GliderMaven (talk)
And the plural, thing, I'm not finding that's a problem for Grays or Sieverts.
The biggest problem is the obscurity of convert from the users point of view. For example if I go ((convert|10|Sv)) I get 10 sieverts (1,000 rem) whereas I could reasonably expect to get: 10 Sv (1,000 rem). I would have expected to get that if I had went: ((convert|10|Sievert)) but that gets: 10 Sievert[convert: unknown unit]! Yes, I can go: ((convert|10|Sv|abbr=on)) 10 Sv (1,000 rem) but that relies on an obscure hard-to-remember flag.GliderMaven (talk) 04:34, 12 January 2014 (UTC)
If possible, it would probably be much, much better if ((convert|10|Sievert)) didn't crunch and automatically turned it to long-form mode, and ((convert|10|Sv)) left it in the short form automatically. There's probably backward compatibility issues, but they're potentially fixable.GliderMaven (talk) 04:34, 12 January 2014 (UTC)

Another approach to preparing new units would be to have a sandbox unit definitions page somewhere, then use makeunits. I have put a demo of that at User:Johnuniq/sandbox2. Using this method, it is necessary to become familiar with the rules for filling in the table to define a unit, but simple cases are very simple. The results can then be copied from User talk:Johnuniq/sandbox2 and pasted into Module:Convert/extra. Later I'll ponder where that page could live, and how it might be documented—the rules mentioned are complex when all details are needed; they are at the top of the master list of units (see link at top of sandbox). Johnuniq (talk) 02:06, 10 January 2014 (UTC)

That works nicely, so I have put a long-term page at Template:Convert/unit sandbox which can be used to prepare unit definitions.
Module:Convert/makeunits has been enhanced—when the input is not the master units page, it outputs the minimum required (just the unit table), and ignores missing sections (sections which are essential when preparing the master units list). I had hoped that the template preview feature would allow experimenting without saving the page, but it does not work in the way I had imagined. Johnuniq (talk) 09:25, 10 January 2014 (UTC)

@GliderMaven: I'm responding down here because it's a bit easier. Re Module:Convert/extra: The link for rem should be Roentgen equivalent man, and the names for Sievert and Gray should be all lowercase (consider "millisievert"). Convert does not recognize Gy as gigayear, therefore Gy could be the unit code for gray, although using "gray" might reduce editor confusion. I don't see why it should be "Gray". OTOH, using mGy as a unitcode might be better than mgray, so perhaps the unit code should be "Gy".

Each of the following new units is defined as working with an SI prefix: Sievert, rem, Gray, rad, A/m, Oersted. I would need to ponder that because while it is convenient that SI prefixes can be used, I'm not sure it is useful to refer, for example, to millioesteds (symbol mOe) or kilorem (symbol krem). Surely SI prefixes should only be enabled on SI units where the symbols are standard? The exceptions (like mrem) probably need to be handled as separate units—that's what is done for µin. Perhaps some enhancement for making an alias with an SI prefix could be considered, if there are many units like that, but so far I'm only aware of microinch.

I have put my interpretations in Template:Convert/unit sandbox (keeping the SI prefixes for now); the results are at Template talk:Convert/unit sandbox.

There is an observation above that it would be more convenient if ((convert|10|Sv)) gave "10 Sv" rather than "10 sieverts"—that is, abbr=on should be the default. I can see the logic of that for the new units, but it would be incompatible with the way that convert has worked for years where, for example ((convert|10|m)) shows "10 metres" by default. The problem is that the new units are almost always used in a scientific context where abbr=on makes more sense. Perhaps some future enhancement could allow a unit to be defined as defaulting to abbr=on, but that would require a fair bit of thought. Johnuniq (talk) 11:18, 12 January 2014 (UTC)

I agree that SI-style prefixes shouldn't be used with imperial units, but these are CGS and SI units, which legitimately do. I found millirem and microsieverts already in articles, also mSv and Sv are in widespread use in the literature. I've also seen MA/m and kA/m and A/m used very widely. The Oersted is an old CGS unit and so I'm pretty sure it legitimately takes the standard prefixes as well.GliderMaven (talk) 12:58, 12 January 2014 (UTC)
I came up with a scheme for moving wikipedia across to defaulting to abbr=on for things like ((convert|1|m)); you run a bot to set the abbr=off for all converts (500,000+) in Wikipedia (where it is not otherwise set), change the default for convert, and go make the bot go through again and remove all the abbr=on (since they are then unnecessary). At that point ((convert|1|metre)) would give 1 metre (3 feet) and ((convert|1|m)) would give 1 m (3 ft) which seems much more intuitive. We could also use a bot later to switch more of the conversions across and remove most of the abbr=offs later.
Whether it's really worth the hassle I'm less sure, it is up to the community and any implementers; but it is certainly possible to do it.GliderMaven (talk) 12:58, 12 January 2014 (UTC)
Some of my comments above assert that some changes were needed, so I put them in Module:Convert/extra, and would appreciate any feedback. I changed "magnetic H-field" to "magnetic field strength" because makeunits has a problem in that it changes the entire unit type to lowercase, and "h-field" looks silly. The unit type only ever appears if a unit mismatch problem occurs, so I don't want to spend time optimising that point. The substantive change was to replace the unit code "Gray" with "Gy"—using the symbol is what is done in the other cases, and it might be best to avoid the need to remember that there is an exception for that unit. In the future, if convert supports gigayears, the unit code "gigayear" can be used.
Re making abbr=on the default: I won't be thinking about anything like that for another couple of months because there are still a number of issues to resolve concerning the deployment. Others of course are welcome to proceed, and I'm just letting you know that I won't be joining any discussion about new stuff at the moment. Johnuniq (talk) 03:09, 13 January 2014 (UTC)
The other changes look very good, but unfortunately it's very wrong to make h-fields the same unit type as magnetic field strengths like Teslas.
The defining equation is where B is the magnetic field in Teslas and mu is a variable (non linear) 'constant' that also varies from material to material. If you make them the same then the user can do a conversion and get completely the wrong answer.
When two units have variable constants of proportionality they almost certainly can't be the same utype.GliderMaven (talk) 13:06, 13 January 2014 (UTC)
Wouldn't "magnetic flux density" do for teslas, if that unit was added to convert? As mentioned, the unit types should never be seen, and flux density seems adequate from my recollection. If really desirable, I could fix the way makeunits changes the type to lowercase, but nothing is simple. The headings (see the ToC in the master list) need the initial capital, but lowercase looks better in a unit mismatch error (hover over the message in 1 mile ([convert: unit mismatch]) or 1 BTU/lb ([convert: unit mismatch])). The only problem is "CO2 per unit volume" which ends up as "co2 per unit volume", but that is better than "cO2 per unit volume". Johnuniq (talk) 21:31, 13 January 2014 (UTC)
OK, I see you changed it to "magnetizing field". Anything that works is fine by me. Johnuniq (talk) 23:44, 13 January 2014 (UTC)
I changed the H-field (Oersted and A/m units) in the 'extra' module to utype "magnetizing field", and have left the Tesla unit at 'magnetic field strength'. They're not interconvertible so that seems to be fine. You'd set them all to 'magnetic field strength' due to your concerns about upper/lowercase but that would have permitted illegal conversions between Oersteds and Teslas;
this should fail and does: ((convert|5|T|Oe)) = 5 teslas ([convert: unit mismatch])
this should work and does: ((convert|5|MA/m|kOe|abbr=on)) = 5 MA/m (63 kOe)
this should work and (now) does: ((convert|5|MA/m)) = 5 megaamperes per metre (63 kOe)
On the gigayear front, as you pointed out convert doesn't support gigayears, so there's no clash with Grays. The errors were just because I'd done the prefix thing wrong. My apologies.GliderMaven (talk) 00:06, 14 January 2014 (UTC)

I had forgotten that gauss and tesla were added three months ago, each as "magnetic field strength". The two related units with a different unit type are: A/m and Oe, each as "magnetizing field". Should we rethink the unit types? The traditional names would be "magnetic flux density" for gauss + tesla, and "magnetic field strength" for A/m and Oe. It is not iimportant because the names are rarely seen, but why not use the traditional names? Johnuniq (talk) 00:59, 14 January 2014 (UTC)

Compliments, Wikid, for that last line. DePiep (talk) 17:47, 17 January 2014 (UTC)

Double disp parameter?

I would like to know whether is possible to combine disp=or and disp=flip in any way, for example:

((convert|24|in|cm|abbr=on|disp=flip|disp=or))
24 in or 61 cm*Red XN

((convert|24|in|cm|abbr=on|disp=or|disp=flip))
61 cm (24 in)*Red XN

Expected result would be:
61 cm or 24 in

Thanks in advance.--Carnby (talk) 20:20, 13 January 2014 (UTC)

The syntax is rather klunky and one day we will try to sort it all out. The workaround in this case is to use "|adj=flip":
  • ((convert|24|in|cm|abbr=on|adj=flip|disp=or)) → 24 in or 61 cm*
Searching Help:Convert for "flip" eventually finds that.
It is not possible for "|disp=flip|disp=or" to work because the underlying software simply accumulates the parameters, and the second occurrence of disp overwrites the first. That happens before Template:Convert is called. Johnuniq (talk) 21:12, 13 January 2014 (UTC)
Thank you very much!--Carnby (talk) 21:27, 13 January 2014 (UTC)
  • ((convert/flip |24|in|cm|near=5|disp=or|abbr=on|x0=~|x3=nearly)) → User:Wikid77/Template:Convert/flip
In the example, "near=5" sets the rounding to the nearest 5-unit increment, while "x0=~" places the tilde before "60". -Wikid77 08:13, 14 January 2014 (UTC)

The solution is to define another parameter (let's call it order) to control flipping (and possibly reordering in general). Using the disp parameter for this never was satisfactory but was the simplest solution at the time due to the difficulty in adding new parameters (a difficulty we can now forget with the third incarnation of ((convert))). Jimp 09:51, 20 January 2014 (UTC)

Human height

Just seeking a wider range of input from informed persons at Template_talk:Height#rfc_97AACED.--Gibson Flying V (talk) 01:14, 23 January 2014 (UTC)

Old bug disp=number for metres

Among the numerous bugs which had to be fixed in {convert/old}, the non-numeric default result for 2 metres (any < 3) when "disp=number" has been a problem, as giving "6 ft 7 in" rather than number "6.6" (feet):

  • {convert/old|3|m|disp=number)) =
  • {convert/old|2|m|disp=number)) =
  • {convert |3 |m |disp=number )) = 9.8
  • {convert |2 |m |disp=number )) = 6 ft 7 in
  • {convert |1 |m |disp=number )) = 3 ft 3 in
  • {convert |1 |m|ft|disp=number)) = 3.3

The fix for {convert/old} is ready as "m/sandbox" unit-code:

  • {convert/old|2|m/sandbox |disp=number)) =

When "disp=number" is needed for converting metres below 3, then the 2nd unit ("ft") has had be specified to get a numeric result. -Wikid77 (talk) 13:30/16:01, 23 January 2014 (UTC)

Deploying updates now 18,000x slower

As many people are now aware, this massive delay in Convert updates is a substantial culture shock, and so I had recommended having an advance release as {convert/+} to indicate "plus new features". As a software developer and proponent of eXtreme Programming, I have planned configuration management strategies for many years, to deploy new features quickly, with minimal regression testing, by keeping smaller "configuration forks" isolated to a subset of the total use-cases. But at least the consolidation done with Lua Convert shows how the former 5-minute updates to various subtemplates had to be lengthened into multi-week reformatting, combined with 3-week release planning, combined with more multi-week reformatting, to extend as perhaps a 63-day update cycle, or 18,000x times slower than a wiki-style update with a 5-minute fix of subtemplates (60/5×24×63 = 18,144). Plus a subtemplate update was quickly reversible if the result was not better. Fortunately, since 2007, we had 6 years to quickly deploy new features for Convert, by adding various combinations of tiny subtemplates, and now we have reached the stage where major, quick advancements can be made with wp:wrapper templates, no longer needing to create hundreds of option-fork subtemplates. However, the underlying Lua Convert still needs some improvements and a few new features, and so the use of a {convert/+} advance-version release will allow for rapid improvements, restricted mainly by the limited regression testing of prior pages which used {convert/+}. The current cascade-protection lock-out, caused by Convert being used in subpages of "Main Page", is another major reason why {convert/+} should be used in cases where new features are needed sooner. Previously, people had come to expect the rapid "miracle" updates to Convert, and it will take a while to get accustomed to talk-page topics being archived weeks before the fix is actually deployed 18,000x times slower, among the 554,000 pages which use Convert. -Wikid77 (talk) 16:37, 22 January 2014 (UTC)

If I remember well, this was discussed quite recently then including a notion of drawbacks. -DePiep (talk) 18:45, 23 January 2014 (UTC)

Question/bug (inconsistent)/feature request for squared/cubic?

I confirmed that the example you give ((convert|60|x|120|m|ft)) provides "60 by 120 metres (200 ft × 390 ft)". Should is say "60 metres by 120 metres (200 ft × 390 ft)"? Or even just "60 metres × 120 metres (200 ft × 390 ft)"? Maybe saying metres twice is considered awkward language but isn't is right scientifically and if not considered important should ft be once for consistency? Is it possible to get the the last version (without two convert templates)? If metres is to long if really should be "m"?

For the three dimensional example, ((convert/3 |2|x|4|x|6|m|ft)) provides "2×4×6 metres (6.6×13×20 ft)" but should give "2 m × 4 m × 6 m (6.6 ft × 13 ft × 20 ft)". Note the space before and after "×" and m not metres.

Is it too late to change and make consistent (in either direction)? For let's say smartphone dimensions what would you do? comp.arch (talk) 15:50, 15 January 2014 (UTC)

there are many options here,
1a ((convert|60|x|120|m|ft)) → 60 by 120 metres (200 ft × 390 ft)
1b ((convert|2|x|4|x|6|m|ft)) → 2 by 4 by 6 metres (6.6 ft × 13.1 ft × 19.7 ft)
2a ((convert|60|x|120|m|ft|abbr=on)) → 60 m × 120 m (200 ft × 390 ft)
2b ((convert|2|x|4|x|6|m|ft|abbr=on)) → 2 m × 4 m × 6 m (6.6 ft × 13.1 ft × 19.7 ft)
3a ((convert|60|*|120|m|ft)) → 60×120 metres (200×390 ft)
3b ((convert|2|*|4|*|6|m|ft)) → 2×4×6 metres (6.6×13.1×19.7 ft)
4a ((convert|60|*|120|m|ft|abbr=on)) → 60×120 m (200×390 ft)
4b ((convert|2|*|4|*|6|m|ft|abbr=on)) → 2×4×6 m (6.6×13.1×19.7 ft)
5a ((convert|60|xx|120|m|ft)) → 60 × 120 metres (200 × 390 ft)
5b ((convert|2|xx|4|xx|6|m|ft)) → 2 × 4 × 6 metres (6.6 × 13.1 × 19.7 ft)
6a ((convert|60|xx|120|m|ft|abbr=on)) → 60 × 120 m (200 × 390 ft)
6b ((convert|2|xx|4|xx|6|m|ft|abbr=on)) → 2 × 4 × 6 m (6.6 × 13.1 × 19.7 ft)
for consistency, I would suggest using ((convert)) instead of ((convert/3)) unless it's some more exotic use-case. however, I do see what you are saying about the differences in presentation between the 2 unit and 3 unit conversions for cases 2a and 2b. Frietjes (talk) 16:06, 15 January 2014 (UTC)
MOSNUM specifies that behavior.
  • multiply sign: 1 m × 3 m × 6 m, not 1 × 3 × 6 m
  • by: 1 by 3 by 6 metres
See Help:Convert#Ranges for the ranges provided by the module that now implements convert. There is no reason to use the old convert/3 unless arbitrary text is wanted; search for "A range can use more than two values" on the help page to see examples (like what Frietjes posted). Johnuniq (talk) 21:00, 15 January 2014 (UTC)
interesting, so per MOSNUM, we need to fix 2b? Frietjes (talk) 21:49, 15 January 2014 (UTC)
Ooops, I seem to have shot myself in the foot. I'm struggling to recall why the module does that. I think my main concern was compatibility with the old templates (convert and convert/3), and I mentioned two months ago that some change in the old template had occurred (here—but the visible text there is now confusing because the wikitext used "convert" to show what the old templates did, but "convert" is now showing the output from the module). The module can handle a large number of range items, and it looks as if I decided to not repeat the unit symbol when there are more than two. I'm not enthusiastic about changing anything until a few weeks after version 2 of the module is released within 24 hours, and I would prefer to be discussing an example of a convert in an article where someone believes there is a problem. Johnuniq (talk) 02:40, 16 January 2014 (UTC)
could just change 6b, which does not require backwards compatibility, although that would sacrifice consistency between 6a and 6b. Frietjes (talk) 15:16, 16 January 2014 (UTC)
I've looked at this a bit more. I have many examples of the output from the old templates (from Special:ExpandTemplates) in local files; most of these were captured several months ago, so they are how the old templates used to be. It seems that convert/3 never repeated the unit, whereas convert did repeat the unit if it was abbreviated. However, the repeat only occurred with "x"—the old template repeated "ft" in ((convert|60|x|120|m|ft)), but not in ((convert|60|xx|120|m|ft)). It appears I used "is_range_x" to indicate a range where the symbol should be repeated, and searching Module:Convert/text shows that only the "x" range has that property. Module:Convert repeats the output symbol if is_range_x is true. My conclusion is that the module works the way it does to be compatible with how the old template used to work (before October 2013, I think). The examples from Frietjes show some inconsistencies, but I don't want to do anything about them at the moment. Let's wait for a few weeks after version 2 of the module is deployed (soon), and let's get a wider discussion preferably based on a convert used in an article. Johnuniq (talk) 03:37, 17 January 2014 (UTC)
no problem with waiting. the only change that is being proposed (by me) would be to make 2a and 2b consistent. this would still make non-repeated units available in the other cases (* and xx). Frietjes (talk) 14:57, 17 January 2014 (UTC)
  • Use Convert/3 with "abbr=mos" to repeat unit symbols: I have changed the wrapper template Template:Convert/3 so the option "abbr=mos" will repeat the unit symbols "m" and "ft" as noted in the wp:MOS, and space around x-range separators unless set to "×". Compare:
  • ((convert/3 |2|x|4|x|6|m|ft ))             -   ((convert/3|2|x|4|x|6|m|ft))
  • ((convert/3 |2|x|4|x|6|m|ft|abbr=mos)) - ((convert/3|2|x|4|x|6|m|ft|abbr=mos))
  • ((convert/3 |2|×|4|×|6|m|ft ))            -   ((convert/3|2|×|4|×|6|m|ft))
FIXED: The option "abbr=mos" was added years ago to match wp:MOS styles, for people working to meet MOS-restrictions for wp:Featured articles, while more people have preferred the default format for ranges. Whatever the current rules in wp:MOS, then "abbr=mos" is reset to that format. -Wikid77 08:59, 16 January 2014 (UTC)

I never was keen on abbr=mos, disp=mos, etc. The MOS isn't expected to flip willy-nilly this way and that and when it does it more of an indication that something is going wrong over there (it happens). I'd prefer we stick with the guidelines, if there weren't meant to be followed, they might as well be deleted. At the very least we should not be defaulting to ignore all rules. If there is a valid reason for the template to disregard to guidelines in this or that particular case, perhaps we can have some way of doing so but the default should be to follow the MOS. MOS suggests repeating the unit with "×" out of respect for what the mathematical symbol actually means. If the MOS has got it wrong, bring it up at WT:MOSNUM; we oughtn't just do as we please without regard to the guideline which was arrived at by consensus. Jimp 09:44, 20 January 2014 (UTC)

I understand it seems the wp:MOS is intended to improve readability, but it often just subsets reality of measurements. In the U.S. a 2×4-inch (5×10 cm) board is called a "2x4" for whatever length, which is usually 2×4×120 inches (5.1×10.2×304.8 cm), even though the board is often more narrow than 2x4 inches. Art galleries typically state "cm" only once, as a painting 10 × 20 cm (3.9 × 7.9 in). For decades in the U.S., sacks of horsefeed have been marked "50#" to denote 50 pounds (22.7 kg). As for "bring it up at WT:MOSNUM" when I tried to explain how the real-world documents do not use dashes as hyphens, 4 of us were taken to wp:ANI to attempt to topic-ban us when 9 people favored normal hyphens to 7 people pushing dashes. One editor, an expert in style guides, was site banned years ago when his recommendations were warped to justify peculiar rules and he protested the false consensus. Plus now, the wp:MOS discussions are trying to push dash-adjectives, such as "Academy Award–winning" with en dash (not hyphen) but unable to handle the 1984 actors who are "1984-Academy-Award-winning actors" among a group of 984 Academy-Award-winning people. The wp:MOS is a set of artificial rules which wp:featured articles must follow, but can horrify many editors with practical backgrounds. Hence, "abbr=mos" supports whatever format whims the MOSquito is biting, but the larger concerns are handled by Convert's default options. -Wikid77 15:22, 22 January 2014 (UTC)
The MOS isn't intended to apply to FAs only but to all articles. The rules may not be a perfect reflexion of what you see in the world but they are decided upon by consensus. Anyone who doesn't like the rules is free to challenge them. You don't get banned and you shouldn't be taken to ANI simply for opposing a rule. Jimp 07:50, 28 January 2014 (UTC)

Where is the quantity time and its conversions?

Where in the list is the quantity time? And the possible conversions from seconds, to minutes, hours, weeks, months, years, like e.g. in https://en.wikipedia.org/wiki/List_of_radioactive_isotopes_by_half-life ? Jgamleus (talk) 14:29, 30 January 2014 (UTC)

The documentation needs fixing, but the current discoverability chain is as follows (I'm mentioning this to make it easier to find next time): The documentation at Template:Convert includes "See Help:Convert for up-to-date information" near the top, and that has a link to Help:Convert units, and that has a link to the full list of units, and eventually you end up at the time units. That shows "century" and "month" and some more that may be of interest.
You have done a great job at getting the tables to work, and I don't think I can offer any ideas that might help with that, but it is also possible to use engineering notation like this:
  • ((convert|1.13|e6year|e12s|abbr=off)) → 1.13 million years (36 trillion seconds)
  • ((convert|1.13|e6year|e12s|abbr=on)) → 1.13×10^6 a (36×10^12 s)
  • ((convert|1.13|e6years|e12s|abbr=on)) → 1.13×10^6 yr (36×10^12 s)
However, that's no use in a table because the convert module includes the multiple and symbol when eng notation is used—I'd have to investigate to remind myself why that happens. Johnuniq (talk) 22:14, 30 January 2014 (UTC)
More