Template talk:Convert/Archive January 2014

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.

• {{convert/sandbox|10|dpi}} → 10 DPI (2,500 μm)
• {{convert/sandbox|100|dpi|pitch}} → 100 DPI (250 μm)
• {{convert/sandbox|100|dpi|dpcm}} → 100 DPI (39 dot/cm)
• {{convert/sandbox|100|dpi|m}} → 100 DPI (0.00025 m)
• {{convert/sandbox|100|dpi|mm}} → 100 DPI (0.25 mm)
• {{convert/sandbox|100|dpi|thou}} → 100 DPI (10 thou)
• {{convert/sandbox|100|pitch}} → 100 μm (250 DPI)
• {{convert/sandbox|350|isp}} → 350 seconds (3.4 km/s)
• {{convert/sandbox|1.2|tsfc|isp}} → 1.2 lb/(lbf⋅h) (3,000 s)
• {{convert/sandbox|0.71|tsfc|isp}} → 0.71 lb/(lbf⋅h) (5,100 s)
• {{convert/sandbox|450|isp|ft/s}} → 450 seconds (14,000 ft/s)
• {{convert/sandbox|33|tsfc|km/s}} → 33 lb/(lbf⋅h) (1.1 km/s)
• {{convert/sandbox|33|km/s|tsfc}} → 33 kilometres per second (1.1 lb/(lbf⋅h))

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:

• By default, error tracking categories are added to articles only (not articles and templates).
• Error messages escape user input so any markup will not break the displayed wikitext.
• Engineering notation can be used in units in a combination with "+" to separate units.
  • {{convert/sandbox|12.3|e3km|e3mi+e6yd|abbr=off}} → 12.3 thousand kilometres (7.6 thousand miles; 13.5 million yards)
• Output multiples can be used in a combination.
  • {{convert/sandbox|80|kg|lb stlb}} → 80 kilograms (180 lb; 12 st 8 lb)
• Option frac=N specifies that fractions should be used for output values. Specifying frac=N overrides other precision specifications such as |2 or |sigfig=3 or |disp=5.
  • {{convert/sandbox|123|mm|in|frac=8}} → 123 millimetres (4+7⁄8 in)
  • A fraction is applied to the output unit (if there is only one), or to non-SI units (if using a combination), except that if a precision is also specified, the fraction only applies to the hand unit.
  • {{convert/sandbox|18.45|in|m|frac=2}} → 18.45 inches (1⁄2 m)
  • {{convert/sandbox|18.45|in|ft in hand m|frac=2}} → 18.45 inches (1+1⁄2 ft; 18+1⁄2 in; 4.2+1⁄2 hands; 0.469 m)
  • {{convert/sandbox|18.45|in|ft in hand m|frac=2|1}} → 18.45 inches (1.5 ft; 18.5 in; 4.2+1⁄2 hands; 0.5 m)
• Option adj=ri0 specifies that the input value should be rounded to the nearest integer.
  • {{convert/sandbox|12.345|mi|km|disp=flip|adj=ri0|0}} → 20 kilometres (12 mi)
• Option round=5 rounds to the nearest multiple of 5 (same as disp=5), and round=25 rounds to the nearest multiple of 25.
  • {{convert/sandbox|12.8|to|57|m|ft}} → 12.8 to 57 metres (42 to 187 ft)
  • {{convert/sandbox|12.8|to|57|m|ft|round=5}} → 12.8 to 57 metres (40 to 185 ft)
  • {{convert/sandbox|12.8|to|57|m|ft|round=25}} → 12.8 to 57 metres (50 to 175 ft)
• When using a default precision, each output in a range uses the same default (the maximum required). Except, using round=each causes each conversion to use its own default precision. Sometimes round=each (which is how the previous version behaved) is needed to avoid excess precision for some values, but usually the new default is better.
  • {{convert/sandbox|12.3|to|1400|mi|km}} → 12.3 to 1,400 miles (19.8 to 2,253.1 km)
  • {{convert/sandbox|12.3|to|1400|mi|km|round=each}} → 12.3 to 1,400 miles (19.8 to 2,300 km)
  • {{convert/sandbox|5000|–|5000.4|lb|kg}} → 5,000–5,000.4 pounds (2,268.0–2,268.1 kg)
  • {{convert/sandbox|5000|–|5000.4|lb|kg|round=each}} → 5,000–5,000.4 pounds (2,300–2,268.1 kg)
• Converting to hands: default is abbr=off; the hands value has at most one digit after the decimal mark, and has an optional fraction; specifying a precision of 2 or more causes the output to use frac=2 (half an inch).
  • {{convert/sandbox|27.749|in|hand}} → 27.749 inches (7.0 hands)
  • {{convert/sandbox|27.749|in|hand|0}} → 27.749 inches (7 hands)
  • {{convert/sandbox|27.749|in|hand|1}} → 27.749 inches (7.0 hands)
  • {{convert/sandbox|27.749|in|hand|2}} → 27.749 inches (6.3+1⁄2 hands)
  • {{convert/sandbox|27.749|in|hand|frac=4}} → 27.749 inches (6.3+3⁄4 hands)
  • {{convert/sandbox|156|cm|hand in|1|frac=2}} → 156 centimetres (15.1+1⁄2 hands; 61+1⁄2 in)
• New units include the following variations on hands.
  • {{convert/sandbox|137|–|156|cm|handlk in|abbr=on|1}} → 137–156 cm ()
  • {{convert/sandbox|137|–|156|cm|hhand in|abbr=on|1}} → 137–156 cm ()
  • {{convert/sandbox|137|–|156|cm|hhandlk in|abbr=on|1}} → 137–156 cm ()
• Using disp=table or disp=tablecen works with an output combination, and each output is placed in a new table cell.
  • For example, {{convert/sandbox|300|PS|hp kW|0|disp=tablecen}} gives wikitext:

  align="center"|300

  |align="center"|296

  |align="center"|221

• In a range, "×" is an alias for "x".
  • {{convert/sandbox|10|×|25|m}} → 10 by 25 metres (33 ft × 82 ft)
  • {{convert/sandbox|10|×|25|m|abbr=on}} → 10 m × 25 m (33 ft × 82 ft)
• Unit "lb" uses extra precision when the input is an integer; the recent experimental unit "LB" has been removed.
• Some minor unit fixes have occurred, and some "extra" units have been defined in the master data list, and moved to the main data module. The special processing required by the recently added DPI and related units has not yet been considered, and the units are in Module:Convert/extra/sandbox, and are near the top of my todo list.

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)

• About the inline tags (warnings and errors). I propose spelling them uncapitalised, in accordance with other inline maintenance tags (Category:Inline templates). So X^{[Convert: Invalid number]} would be spelled X^{[convert: invalid number]}. -DePiep (talk) 11:29, 26 December 2013 (UTC)

  That looks like a good idea, and I was updating the sandbox, so I did that. An easy way to compare new/old messages is to look at the testcases which currently shows 105 test cases as failed due to the different messages and the fact that the default precision has been tweaked in ranges.

• I'm having trouble with references in messages (sometime users enter a number with a reference in an infobox, and the whole text gets passed to convert). Look at the mouseover text in the following:

  • {{convert|1<ref>xyz1</ref>|m}} → 1 metre (3 ft 3 in)
  • {{convert/sandbox|1<ref>xyz2</ref>|m}} → 1 metre (3 ft 3 in)

  I'll add a reflist below to show that the references are active. The wikitext passed to convert does not include the ref stuff—it is converted to a weird "strip marker" and some playing around has failed to find a way to remove it. Johnuniq (talk) 21:50, 26 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).

• {{convert/sandbox|123<ref>xyz3</ref>|m}} → 123 metres (404 ft)
• {{convert/sandbox|123<math>xyz4</math>|m}} →
• {{convert/sandbox|123[[File:Help-browser.svg]]}} →

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)

• • • About the strip markers - it's probably best not to touch them. If the strip marker is generated by <nowiki>...</nowiki> tags, or a few others, then it's possible to remove them. But if you try and remove strip markers generated by <ref>...</ref> tags, then you will end up with phantom references. The problem is that at the stage of processing that Lua is run, MediaWiki has already processed the tags once, so it is impossible to control the results of that first processing from Lua. In the case of ref tags, MediaWiki is going to stick the references wherever the next <references /> tag is whether you like it or not. :) The strip markers that Lua is passed in this case only control the superscript links to the references. So you can remove the superscript links, but you can't remove the references. And while most strip markers control fairly simple things like nowiki, gallery and ref tags, sometimes they might be pointing to much more complex things. (You'd have to ask a MediaWiki developer for more details on that last point.) So it's probably best not to try and mess with that at all. I would say that the best solution in this case is just to output an error message and a tracking category so that someone can fix the page and/or reconfigure whatever template passed the ref tags to {{convert}}. — Mr. Stradivarius ^{♪ talk ♪} 11:10, 27 December 2013 (UTC)
      • I think we are saying the same thing. If someone passes "123<ref>xyz3</ref>" as an input to convert, there has to be an error message saying that the input is an invalid number. The sandbox code quotes the user input, but truncates everything from the first char(127) (rubout), which is the first byte of a strip marker. The sandbox code then appends suitably escaped text, and produces an error message saying that "123<ref>...</ref>" is invalid (with three dots instead of whatever reference text was used). The alternative would be to simply say that the input is invalid without quoting it, and that is essentially the same as quoting some of it while omitting the strip marker. Johnuniq (talk) 00:37, 28 December 2013 (UTC)

• About hand (unit). Looks like you've got it as far as the needs of the equine articles. Can you update the convert/hands template? I would, but I totally suck at this stuff and would screw it up. Montanabw^(talk) 07:05, 27 December 2013 (UTC)
  • I'll pass on that, but someone with more template clues may want to investigate, when the current testing in the module sandbox is completed and implemented in the main module. Johnuniq (talk) 09:23, 27 December 2013 (UTC)

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

• About fraction spacing. EDokter has changed the spacing in {{frac}} and {{sfrac}} ([1], [2]). Quite bold, shortcutting a long discussion. If I remember correct, you have hardcoded fraction formatting in the module. So this could invite a change. I don't know how stable the EDokter change is, but the next one or two weeks will show. -DePiep (talk) 02:28, 29 December 2013 (UTC)

  Is fixing a problem at MOS without first arguing for three months allowed? I'll wait before implementing the fix, but it looks excellent, and is a simple change in the module that I will put in the sandbox in a day or two, after seeing any responses to the edit. Johnuniq (talk) 05:44, 29 December 2013 (UTC)

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.

• {{convert/sandbox|5/8|m|m|frac=8|abbr=on}} → 5⁄8 m (5⁄8 m)
• {{convert/sandbox|12+5/8|m|m|frac=8|abbr=on}} → 12+5⁄8 m (12+5⁄8 m)
• {{convert/sandbox|5//8|m|m|frac=-8|abbr=on}} → 5/8 m (5/8 m)
• {{convert/sandbox|12+5//8|m|m|frac=-8|abbr=on}} → 12+5/8 m (12+5/8 m)

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

Module v2: hands

• About new "units" handlk, hhandlk, hhand for hand

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:

• {{convert/sandbox|137|–|156|cm|handlk in|abbr=on|1}} → 137–156 cm ()
• {{convert/sandbox|137|–|156|cm|hhand in|abbr=on|1}} → 137–156 cm ()
• {{convert/sandbox|137|–|156|cm|hhandlk in|abbr=on|1}} → 137–156 cm ()

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.

• The experimental units (handlk, hhand, hhandlk) have been removed.
• The default output unit when converting from hands has been changed from "cm" to "in cm" to match {{hands}}.
• By default, the name "hands" is linked.
• Using |abbr=h shows "h" for hands; |abbr=hh is similar but shows "hh".
• The unit is not linked if use |lk=off or |abbr=on or |abbr=h or |abbr=hh.
• A precision of 2 (|2) rounds a hands value to the nearest 1⁄2 inch, and a precision of 3 (|3) rounds to the nearest 1⁄4 inch.
• When hands are converted to inches, the output defaults to "inches" (not "in"), and the value shown is equivalent to the hands value.
• When the output unit is "hand in", the inches value is equivalent to the hands value. If the hands value displays a fraction, the inches value will also display a fraction. For example, if the inches value is 61.4 and a fraction is used, the value will appear as 61+1⁄2; if 61.5 were used, there would be an incorrect implication that the value is not 61.4.

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:

• {convert|5|in|cm|3}} → 5 inches (12.700 cm) -- to compare
• {convert|5+1/2|in|cm|3}} → 5+1⁄2 inches (13.970 cm) -- Y
• {convert|-5-1/2|in|cm|3}} → −5+1⁄2 inches (−13.970 cm) -- Y
• {convert|-5+1/2|in|cm|3}} → −5+1⁄2 inches (−13.970 cm) -- Y
• {convert|5 1/2|in|cm|3}} → -- Y
• {convert/sandbox|5 1/2|in|cm|3}} → -- Y
• {convert|5-1/2|in|cm|3}} → -- N
• {convert|-5+1/2|in|cm|3}} → -- N
• {convert/sandbox|5-1/2|in|cm|3}} → -- N

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)

• Hrmm... So all of the N's should produce ^{[convert: invalid number]} messages? I guess I could agree with that... How to detect what is an improper equation though? It's way too late now for me to contemplate an answer to that. Technical 13 (talk) 05:49, 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 → N

+5-1/2 → N

+5+1/2 → number 5+1⁄2 Y

-5-1/2 → number −5+1⁄2 Y

0-1/2 → number −0+1⁄2 or −1⁄2 Y (zero as the exception); but not −1⁄2 N. 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 Y, 5+-1⁄2 N -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}} →

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)

• Create wrapper {convert/range} to limit Lua fork: It is important, during this time of transition to Lua, to limit the extent of forking with non-compatible features not supported by the {convert/old} template. Previously, "60-170" would be treated as subtraction, with 60-170=-110 as typical in most contexts; hence, {{convert/old|60-170|ft|0}} gives: . The overloaded meaning of "60-170" as a range could be handled by a wp:wrapper template named {convert/range} to be called by {{chembox}} or others. In general, the parsing of a phrase, such as "60-170" or "60 to 170" is far more complex than using positional parameters "60|-|170" and would greatly complicate the Lua Convert, because each new feature entails error-reporting or error-correction logic, to explain "60-170-190*3 or 4" as invalid or not. It is better to separate that complexity into another template {convert/range}, which could be modified separately without triggering reformat of all 554,000 pages (ran 17 days) to update Lua Convert. -Wikid77 (talk) 12:07, 7 January 2014 (UTC)

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

• {{convert/sandbox|1-2|ft|in}} → 1–2 feet (12–24 in)
• {{convert/sandbox|1 to 2|ft|in}} → 1 to 2 feet (12 to 24 in)
• {{convert/sandbox|1 to(-) 2|ft|in}} → 1 to 2 feet (12–24 in)
• {{convert/sandbox|1 or 2|ft|in}} → 1 or 2 feet (12 or 24 in)
• {{convert/sandbox|1 +/- 2|ft|in}} → 1 ± 2 feet (12 ± 24 in)
• {{convert/sandbox|1 by 2|ft|in}} → 1 by 2 feet (12 by 24 in)
• {{convert/sandbox|1 x 2|ft|in}} → 1 by 2 feet (12 in × 24 in)
• {{convert/sandbox|1 xx 2|ft|in}} → 1 × 2 feet (12 × 24 in)
• {{convert/sandbox|1*2|ft|in}} → 1×2 feet (12×24 in)
• {{convert/sandbox|1*2 to 3*4|ft|in}} → 1×2 to 3×4 feet (12×24 to 36×48 in)
• {{convert/sandbox|-1-2/3|ft|in}} → −1+2⁄3 feet (−20 in)

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...

• {{convert/sandbox|8|°C|°F}} → 8 °C (46 °F)
• {{convert/sandbox|-8|°C|°F}} → −8 °C (18 °F)
• {{convert/sandbox|8-10|°C|°F}} → 8–10 °C (46–50 °F)
• {{convert/sandbox|-8-10|°C|°F}} → −8–10 °C (18–50 °F)
• {{convert/sandbox|10--8|°C|°F}} → 10 – −8 °C (50–18 °F)
• {{convert/sandbox|-8--6|°C|°F}} → −8 – −6 °C (18–21 °F)
• {{convert/sandbox|-6--8|°C|°F}} → −6 – −8 °C (21–18 °F)

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.

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • same content
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

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)

• Ranges of 1-unit separation could increase precision +1: A possible easy fix for nonsense ranges producing unchanged results is to bump the default precision of both numbers as +1 higher for ranges differing by 1 unit or less. Examples:

• {{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

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! 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 $B=\mu H,$ 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 () or 1 BTU/lb ()). 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 ()

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)

• Template:Cvt is the abbr=on version: For over 3 years, the less-known abbreviated version, as Template:Cvt (to imply "abbr=on") has been available for use in wikitables where abbreviation is common, and the table would be filled with many "{{cvt|..}}" rather than "{{convert|..|abbr=on}}". Per wp:MOS, the first usage of a unit is to have full unit name, and so {cvt} should only be used after the unit name is shown beforehand. We had slowly introduced {cvt} into about 80 articles, but they were all rabidly changed to use full "{{convert|..|abbr=on}}" and so the historical pattern of usage has been lost. Template:Cvt has been updated to use the Lua version, but could be further optimized later. -Wikid77 (talk) 07:41, 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 cmN

{{convert|24|in|cm|abbr=on|disp=or|disp=flip}}
61 cm (24 in)N

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)

• Also consider {convert/flip}: As a wp:wrapper template, Template:Convert/flip allows the other use for "disp=or" but also allows custom-text parameters, such as "x3=nearly" to modify the results:

• {{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)

• FIXED {convert/old}: I have installed the fix for {convert/m}, from /sandbox, as there were only 73 transclusions, and no reason to delay a 5-minute fix any longer. -Wikid77 16:28, 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)

• In most cases, wp:MOSNUM can be ignored, as the mere guideline it is, and not a logically derived nor scientifically proven preference; however, because wp:Featured articles have been chained to wp:MOS styles, I had added option "abbr=mos" to force a conversion to show the latest whims of wp:MOS style. That option, abbr=mos, had allowed Convert to meanwhile offer real-world formats, or scientifically better results for many articles, but also help featured-article people to bypass reality and follow whatever MOS-format being imposed to pass FA-restriction levels. In practice, we typically quote from wp:MOS to resolve a style debate which would delay improvements; however, I have a yet to see a "clinical trial" which would prove a MOS-style caused a 200% improvement in readability, as opposed to just claiming '1×6×48-inch boards' would "warp our little minds" (from South Park). Bear in mind, Albert Einstein scrawled text on a chalkboard and did not lament a style problem in communication. I suggest we return to using "abbr=mos" to force whatever peculiar rules the FA people need to pass FA-format restrictions, but allow Convert to support, as default, what normal people have written in real-world documents. Typically, many people (and art experts) really dislike repetitious monotony, of "cm" repeated, and so 90% of the time, paintings are described with each unit shown once: 12 × 24 cm (4.7 × 9.4 in), and not repeat "cm" laboriously for each side of a painting or other artwork. Search for: "cm" painting gallery, and notice how the world actually writes measurements. -Wikid77 (talk) 01:29, 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://wiki.riteme.site/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^⁶ a (36×10^¹² s)
• {{convert|1.13|e6years|e12s|abbr=on}} → 1.13×10^⁶ yr (36×10^¹² 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)