Jump to content

Template talk:Convert/Archive December 2013

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


Pressure (at least) doesn't seem to allow conversion to 2 output units

I don't know if this is an error, an undocumented feature which sometimes works and sometimes doesn't, or a known feature which doesn't work for all units.

For what it's worth: in the documentation the following example is given, and works:
{{convert|641|acre|ha sqmi|2|lk=on}} ==> 641 acres (259.40 ha; 1.00 sq mi)

But this doesn't:
{{convert|895|hPa|mmHg inHg|abbr=on|2}} 895 hPa (671.31 mmHg; 26.43 inHg) [shows as "895 hPa (Template:Convert/mmHg inHg)" 16:30, 9 Nov 13]

The abbreviations used are correct:
{{convert|895|hPa|mmHg|abbr=on|2}} 895 hPa (671.31 mmHg)
{{convert|895|hPa|inHg|abbr=on|2}} 895 hPa (26.43 inHg)

It seems to me that showing pressure, in particular, in several units can be useful, as there are several in common use, particularly for atmospheric pressure. Pol098 (talk) 16:33, 9 November 2013 (UTC)

fixed. Frietjes (talk) 17:06, 9 November 2013 (UTC)
Quick! Pol098 (talk) 19:19, 9 November 2013 (UTC)

Is this something that needs the template to be modified unit by unit? I've tried this both ways round; as of now the form that was failing above, {{convert|895|hPa|mmHg inHg|abbr=on|2}}, has indeed been corrected, but the form with the units swapped so inHg precedes mmHg fails.

{{convert|895|hPa|inHg mmHg|abbr=on|1|lk=on}} 895 hPa (26.4 inHg; 671.3 mmHg) [wasn't working as of 19:30, 9 Nov 13, but since corrected]
{{convert|895|hPa|mmHg inHg|abbr=on|1|lk=on}} 895 hPa (671.3 mmHg; 26.4 inHg) [works]

This isn't a request from me for this to be corrected; my attitude is simply that I report issues in case it's thought they should be rectified. If for example it has to be done case by case, I shouldn't think it's worthwhile. Congratulations on the ultra-speedy correction of the first issue. Best wishes, Pol098 (talk) 19:49, 9 November 2013 (UTC)

I added the swapped version for you. Yes, there is a separate template for every combination currently in use :( Hopefully this will be fixed in the Lua module :) 895 hPa (671.3 mmHg; 26.4 inHg) and 895 hPa (26.4 inHg; 671.3 mmHg) Thanks! Plastikspork ―Œ(talk) 23:01, 9 November 2013 (UTC)
For me? Thanks, but I really didn't want to put you to the trouble, just thought it seemed wrong. If I'd known it was case-by-case I'd not have said anything. Until and unless this works in general, might it not be better to remove the "acre|ha sqmi" example from documentation? Or maybe say that for some (a few? most? hardly any?) units this notation works? It would have stopped me from wasting your time. This is a comment, no need to answer.

Note to anybody reading this: in Plastikspork's comment immediately above, after the ":)" there are two examples of the Lua sandbox version; today it displays error messages, when it is working it will display the result with two parenthesised alternative units. Best wishes, Pol098 (talk) 00:11, 10 November 2013 (UTC)
@Pol098:Real-life issues have meant I haven't had the energy to finish some details to release Module:Convert, but it will be soon...
Lots of combination units like "ha sqmi" are defined, but as noted above, each such combination has to be individually defined. The module allows combinations to be created by joining standard unit codes with "+" signs, as in these examples:
  • {{convert/sandboxlua|895|hPa|mmHg+inHg|abbr=on|1|lk=on}} → 895 hPa (671.3 mmHg; 26.4 inHg)
  • {{convert/sandboxlua|895|hPa|inHg+mmHg|abbr=on|1|lk=on}} → 895 hPa (26.4 inHg; 671.3 mmHg)
One benefit from sticking to the defined combinations is that they encourage uniformity across articles, but there are far too many possible combinations to define them all. Johnuniq (talk) 01:05, 10 November 2013 (UTC)
would it be possible to simply enumerate all the single-unit outputs with a space (e.g., Irish acre) in the lua module, then assume that the rest are multiple-unit outputs? or would this be too complicated? seems like this could reduce the need for explicitly handling combinations like 'ha acre'. Frietjes (talk) 18:19, 10 November 2013 (UTC)

Convert/show2 and Convert/show3 show any outputs

Among the new wp:wrapper templates, {convert/show2} and {convert/show3} can be used to show any combination of output units. Examples:

  • {{convert/show2|895|hPa|mmHg|inHg|abbr=on|1|lk=on}} → {{User:Wikid77/Template:Convert/show2|895|hPa|mmHg|inHg|abbr=on|1|lk=on}}
  • {{convert/show2|895|hPa|psi|inHg|abbr=on|1|lk=on}} → {{User:Wikid77/Template:Convert/show2|895|hPa|psi|inHg|abbr=on|1|lk=on}}
  • {{convert/show3|895|hPa|psi|inHg|lbf/sqin|abbr=on|1|lk=on}} → User:Wikid77/Template:Convert/show3

Those wrapper templates are intended to reduce the need for other special subtemplates of Convert. -Wikid77 (talk) 16:45, 10 November 2013 (UTC)

I'd suggest at least a brief mention in the documentation (I may have missed it, but don't think so). I would do it, but am not familiar with what's happening and what's recommended. Best wishes Pol098 (talk) 16:35, 15 November 2013 (UTC)
Perhaps Convert/show2 and /show3 should be listed in the See-also section. -Wikid77 (talk) 15:15, 1 December 2013 (UTC)

Proposal for output combination units

There are 66 units that include a space in the unit code. Please see here (permalink) for a list of those units and a proposal to have the module accept user-defined output combinations, based on the suggestion by Frietjes above.

The proposal would allow combinations like "m3 impgal usgal" (any codes which do not contain spaces), but would require "+" when combining codes that contain spaces, like "m3+board feet". That would be easy to achieve and easy for users to understand. The module could get more adventurous and try to interpret "m3 board feet" but the effort does not seem worthwhile. Any thoughts? Johnuniq (talk) 08:45, 11 November 2013 (UTC)

Without having any particular experience in this topic, mandatory use of a "+" seems a good compromise. Alternatives: my background in general (rather than wiki) computing would suggest the underscore character "_", routinely used to indicate a space without being interpreted as a separator. Another computing practice that might work is the use of "double quotes", so long as they don't get interpreted as part of the unit (inches and seconds, often indicated with the double quote character, come to mind). Pol098 (talk) 12:44, 11 November 2013 (UTC)
The underscore would be a good character to use, but for compatibility reasons the module translates each underscore to a space early in the conversion (because, for example, Template:Convert/board_feet works with or without an underscore).
At any rate I have implemented my proposal so Plastikspork's above examples work, as do the following:
  • {{convert/sandboxlua|12|km2|acre sqyd ha}} → 12 square kilometres (3,000 acres; 14,000,000 sq yd; 1,200 ha)
  • {{convert/sandboxlua|123|cuyd|m3+board feet}} → 123 cubic yards (94 m3; 40,000 board feet)
  • {{convert/sandboxlua|895|hPa|psi inHg lbf/in2|abbr=on|1|lk=on}} → 895 hPa (13.0 psi; 26.4 inHg; 13.0 lbf/in2)
Johnuniq (talk) 10:40, 12 November 2013 (UTC)

possible problem with fractions?

1⁄4 mile (0.40 km) should, if I'm not mistaken, have "mile" singular and only round km to one significant figure. --NE2 00:00, 13 November 2013 (UTC)

this has been debated before, but I don't recall the exact conclusion. I believe that the conclusion was '0.25 miles', and '1/4 of a mile', but I don't recall what the conclusion was for '1/4 mile(s)'. Frietjes (talk) 00:44, 13 November 2013 (UTC)
@NE2: note that you can use {{convert|1/4|mi|adj=1}} to force it to not use the plural. and {{convert|1/4|mi|adj=1|sigfig=1}} for one sigfig. Frietjes (talk) 00:47, 13 November 2013 (UTC)
  • Fixed 30-Nov-2013 and 4-Sep-2011: The display of singular fractions, "1⁄2 unit" had been resolved, over 2 years ago, and User:Jimp created Template:Convert/plural (4 September 2011) to show singular fractions when "disp=or" and for "abbr=out". I added similar logic, on 30 November 2013, to show "1⁄2 foot" as the default format, or with "abbr=in" as matching the results of {convert/plural} from 2011. Even years ago, the general consensus was to show singular fractions below 1.0, but a search of common text in Google seemed to prefer plural decimals under one, such as "0.5 inches" in many cases, as the typical style for decimals, contrary to singular fractions. The default precision, as 2-decimal "1⁄2 foot(0.40 km)" reflects the 2-digits of 0.25 as being one-fourth unit, but precision increases to 3-decimal level for "1⁄100". -Wikid77 (talk) 04:03, 3 December 2013 (UTC)

kW/tonne and hp/tonne

For Sprinter (Victorian train)#Technical {{convert|9.2|kW/tonne|hp/tonne|abbr=on|disp=or}} 9.2 kW/tonne or 12.3 hp/tonne instead of 9.2 kW/tonne or 12.4 hp/tonne. But what about {{convert|9.2|kW|hp|abbr=on}}/tonne 9.2 kW (12.3 hp)/tonne? Peter Horn User talk 03:16, 17 November 2013 (UTC)

Make that {{convert|9.2|kW|hp|abbr=on|disp=or}}/tonne 9.2 kW or 12.3 hp/tonne Peter Horn User talk 03:18, 17 November 2013 (UTC)
  • Try Convert/f with x2=/tonne: In cases where the per-unit will be the same for both amounts, then just insert "/tonne" into the conversion, using Template:Convert/f as follows:
{convert/f |9.2|kW|hp|abbr=on|disp=or|x2=/tonne}} → 9.2 kW/tonne or 12.3 hp*
Then just append the extra "x5=/tonne" at the end. Recall options x0-x5:
             12,340 kilometres (7,670 miles)
             |     |          | |    |     |
             x0    x1         x2 x3   x4   x5
While parameters x0 and x1 insert text before or after the first amount, x2 follows the input unit, x3 puts text before the output amount, x4 follows the output, and x5 follows the output unit name.
Convert/f is intended to continue the same format with the Lua version of Convert, while allowing any "/xx" such as per week "/week" or "/year" or "/century" etc. This is the next generation of Convert, along with Template:Convert/text3 for free-form conversions. -Wikid77 (talk) 07:03, 17 November 2013 (UTC)
Thanks, I need to study this carefully. Peter Horn User talk 21:31, 17 November 2013 (UTC)
"9.2 kW (12.3 hp)/tonne" doesn't seem very clear to me. I'd prefer either "9.2 kW/t (12.3 hp/t)" or "9.2 kW (12.3 hp) per tonne". However horsepower per tonne is a bit of an odd unit, it seems to me, being a hybrid of imperial/US and metric. Why not convert to horsepower per long and/or short ton? Jimp 08:09, 5 December 2013 (UTC)
  • A unit-code "hp/t" seems good, but we were trying to avoid new units with the pending Lua transition which has hindered many improvements this year. However, the Lua version might already have support for hp/t soon: {{convert/q|9.2|kW/t|hp/t}} as {{convert/q|9.2|kW/t|hp/t}}, or {{convert/old|9.2|kW/t|hp/ST}} as . -Wikid77 00:16, 10 December 2013 (UTC)

Add CSS hooks

td .convert       > .en {display: none;}
td .convert:hover > .en {display: inline;}

<span class="convert">
  <span class="si origin">1 m</span> 
  <span class="en target">(39 in)</span>
</span>

This template is used a lot in spec tables, which makes them hard to read. I’d like to hide English units, at least in tables, by means of my user stylesheet, but as far as I can see the output of this template is not wrapped in elements to facilitate that. Could someone please add this? I actually wouldn’t mind if the English value was still accessible within a tooltip. — Christoph Päper 21:54, 17 November 2013 (UTC)

  • Perhaps have a Convert/css wrapper template: We could develop a special, customized wp:wrapper template to control the placement of span-tags with the named CSS classes, as a Template:Convert/css. There would be at least 3 CSS classes, to display the input amount, the output amount, and the separator text "(__)". Then, a user could set the input and separator text to "display:none;" so only the output amounts would appear in a large table of conversions. In general, Convert has been designed to display a special format for every combination of options, and so hundreds of Convert subtemplates would need to be changed to show CSS span-tags in every case and avoid expression errors of span-tags in raw numbers shown by "disp=number". However, having {Convert/css}, to use special CSS span-tags, would provide a simple means for hiding parts of the conversions. To hide only the Imperial units, or US customary units, would require complex code to set the CSS classes depending on the unit-code chosen, where "m" would be an SI unit, but "ft" would set the span-tag CSS class for US Customary units. -Wikid77 (talk) 05:32, 19 November 2013 (UTC)
Next time, please document it yourself. These 2800 subtemplates are messy enough already. -DePiep (talk) 16:41, 27 November 2013 (UTC)

Something new

In Electric heating#Industrial immersion heaters, what would be the metric equivalent and conversion for 40 w/in² & 60 w/in² (or 40 W/in² & 60 W/in² ?) ? Peter Horn User talk 15:40, 19 November 2013 (UTC)

  • Let's use /sqin and /cm2 as new unit-codes: The typical conversion of watts to horsepower has been questioned as misleading, so just convert the per-square-inch to per-square-cm. Note:
{convert|40|or|60|/sqin|/cm2}} → 40 or 60 per square inch (6.2 or 9.3/cm2)
40 or 60 W/in{sup|2} ({convert|40|or|60|/sqin|/cm2|disp=out}}) → 40 or 60 W/in2 (6.2 or 9.3/cm2)
In many subjects, the reader tends to learn the units, with little need for extra conversions. -Wikid77 (talk) 17:36, 19 November 2013 (UTC)
Thanks. Peter Horn User talk 20:19, 19 November 2013 (UTC)
I'd suggest it's clearer and more correct to keep the "W" in the conversion. That is add W/sqin and W/cm2 such that
{{convert|40|or|60|W/sqin|W/cm2}} → 40 or 60 W/in2 (6.2 or 9.3 W/cm2)
Jimp 08:17, 5 December 2013 (UTC)

Request to switch to Module:Convert

As noted at WP:ANRFC, Trappist the monk (talk · contribs) implemented a change here (edit summary: "Upgrade to Lua module") in response to this edit request. Cunard (talk) 01:41, 10 January 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC

Alternative: "#Propose hybrid Convert 10% Lua". -Wikid77 09:30, 8 December 2013 (UTC)

I propose we should migrate convert to use the module Module:Convert now, as it seems it's ready for prime time now. I understand this is a big switch, so please decide wisely :) →AzaToth 21:49, 19 November 2013 (UTC)

Would you like to try it on Commons first? The version there is not used as much as on Wikipedia, but it's somewhat old and has bugs. ghouston (talk) 22:59, 19 November 2013 (UTC)
Note see Template:convert/testcases for some comparisons. Frietjes (talk) 00:29, 20 November 2013 (UTC)
Here is what Johnuniq has to say about it Module_talk:Convert#Status. -DePiep (talk) 07:52, 20 November 2013 (UTC)
I'd rather have him around when the tide comes in. -DePiep (talk) 08:18, 20 November 2013 (UTC)
In general, we need to develop a transition plan, such as a 1-week trial period (or longer depending on 3-day reformatting of all pages using Convert), along with a plan to log any detected bugs, then revert back to markup-based Convert until enough mismatches are adjusted for a new "go-live" date. Part of the transition plan could be a "readiness checklist" to ensure each major type of conversion has minimal mismatches, and when ready, then switch to Lua-based Convert. Remember, we will lose the tracking subtemplates, and no longer have Special:WhatLinksHere/Template:Convert/fathom and such, to track usage of unit-codes. Plus, we need to add the new unit-codes into the Lua module, before the first stage of transition. Unlike other Lua modules, there is little benefit to using the Lua Convert, perhaps less than a fifth-second gain, because markup-based Convert is quite fast and used just a few times in most pages. The transition to Lua Convert is mainly a nightmare of potential conversion problems, precision mismatches, and massive slow reformatting of 600,000 pages. -Wikid77 (talk) 09:44, 20 November 2013 (UTC)
I have tried getting editors involved in checking the testcases, but it's tedious. Would anyone who does some checking please review this note I wrote two months ago. Losing "what links here" and the tracking templates is a problem which I have pondered. To at least have a snapshot, I captured "what links here" for each tracking template in the last couple of days, and a list of articles that transclude each unit known to the module a month ago. I understand that's not very helpful, particularly as they are files on a local computer, but it's better than nothing. I have some blue-sky plans for a weekly snapshot, but that may never happen. Johnuniq (talk) 10:27, 20 November 2013 (UTC)
(edit conflict) re Wikid77.
"... allow updates with reformatting" - or without?
Is there a need, a priori, to revert to wikicode after one week? Imagine this scheme. Some 24h after going live, a new version is put live that has some major bugs fixed. So then the whole cache is emptied again, the next three days are for the queue. But not adding up to six days! You can throw a page from the cache only once. That would support early versions (not compromising code quality of course). Maybe at day 3 or 5 another version is ready & needed. OK. Then, we can wait longer when the bug are smaller. The revert-to-wikicode option is an emergency button only.
We should make the agreement that, starting 24h before the Switchover, all old wikicode template code is frozen. That prevents that, when it were needed in a reverse, new differences are introduced from the backup. (This should also prevent doing edits in the old one that were long due, an can be "squeezed in nicely" when it is offline: don't go there). Mirrored, new units in Lua all should go in /extra first weeks, until Lua is stable Or better: do not accept any new unit features during switchover weeks. I propose two-sided feature freeze during switchover weeks. -DePiep (talk) 10:30, 20 November 2013 (UTC)
Well perhaps we should add new unit-codes, at the same time, to both the Lua-based Convert and Template:Convert/old, to allow progress to continue without using Lua as an excuse to halt improvements. -Wikid77 (talk) 15:39, 20 November 2013 (UTC)
Strong advise not to do that. Adding units require "unit tests" (as in: software-units), which are details. Switching over, on the other hand, is a system test. Once doing a system test/rollout, no sane person wants to be surprised by bugs/issues from such newly introduced details.
Also think of what Johnuniq has to face during these switchover days. Trying to get a grip on the new system bugs (the easy ones are caught already, so these are the dirtier, meanly hidden beasts!), he would also have to cope with not-essential details. Trying to cater two running trains is nigh impossible. There better be one leading train at any one time. Time for the wikicode template to pause as leader.
And there is this simple question, Wikid77: why not save these new unit proposals in a fridge for a few weeks, and when the module is stable, put them in /extra. Right when Johnuniq has time to discuss any issue. -DePiep (talk) 17:06, 20 November 2013 (UTC)
Johnuniq, are you gonna request a development freeze of the old template? If so, how long before The Edit (to catch up its latest changes)? Or do you have an other process proposal in this. -DePiep (talk) 04:51, 21 November 2013 (UTC)
I'm thinking that the module should not be changed unless there is compelling reason to do so (that is, to fix a bug), and I do not plan to add features or tweak the code at this stage as fiddling often leads to problems. I see no reason that the convert templates should be changed, but standard procedure is for everyone to do what they want, so I'm not going to object. There are plenty of things in the convert templates that could be addressed (some are here), but working on fixing template bugs seems like a waste of time to me. I have no plans to modify the module to keep it in step with any changes that are made to the templates—any new features can be added later (after a fair bit of planning). Johnuniq (talk) 08:39, 21 November 2013 (UTC)
The markup-based Convert will continue to be used, for years, even with Lua, as with Template:Citation/core being "replaced" by Module:Citation/CS1 in March 2013, but still in use. Hence, we should keep updating both versions of Convert. And there is no benefit to rushing the transition. -Wikid77 (talk) 11:11, 21 November 2013 (UTC)
All fine. But are you going to cooperate to keep them synchronised? When there is an emergency rollback after one week, can we trust that the old template be the same? And, indeed, no need for "hurrying" (who said so?). OTOH, there is a reasonable need to synchronising the process. -DePiep (talk) 11:41, 21 November 2013 (UTC)
So Wikid77 is not providing the stable backup during rollover (since there is no confirmation). That means once the module is live, the old template (the backup) can become different from module, uncoordinated, and behave unexpected when backup reversal would be needed. Whether this will really occur is not important, the point is that we can not depend on it.
Consequences: The backup might be made broken before the module is stable. We can not depend on it to be a safe fallback. Module development, Johnuniq: you're on your own now. From this reason, it is now advisable to roll out the module asap, because any delay will give the backup more time to introduce issues/differences. (The module better be stable within one week from now than three weeks, so that less backup changes are occurring). Also it might be needed to block all module:convert/extra changes until module is stable.
My opinion: Breaking a backup, because no agreement or promise was made. Within all reason, that can be called uncooperative and disruptive. I find this irresponsible behavior by Wikid77, and I would not tolerate that in a professional environment. -DePiep (talk) 08:01, 23 November 2013 (UTC)
See below: "#Postpone transition another month". -Wikid77 12:18, 23 November 2013 (UTC)
  • Comment: Just a comment to let everybody know that simple.wikipedia switched over to using the module back in September, and it's working great. Of course that project has only a tiny fraction of the number of transclusions here, but we had no real issues to speak of after changing over. And it makes upkeep for us a heck of a lot easier. The full log of corrections we had to make after switching over can be found at simple:User talk:Osiris/work/templates/4. It mostly just caught uses that were already wrong. Osiris (talk) 05:17, 23 November 2013 (UTC)
Lua Convert broke 3-unit conversions: The Lua Convert might seem to be "working great" on Simple Wikipedia, but it broke 3-unit conversions for the past 3 months, which indicates a lack of testing. Try:
  • {{convert/3 |40|or|50|up to|52|ft|m}} → {{convert/3|40|or|50|up to|52|ft|m}}
The result on Simple Wikipedia has been:
Quite obviously, the Lua version of Convert cannot be used on English Wikipedia without further development. -Wikid77 (talk) 12:18, 23 November 2013 (UTC)
that's {{convert/3}}, not {{convert}}. Frietjes (talk) 15:57, 23 November 2013 (UTC)
Convert/3 uses Convert to calculate the values. -Wikid77 22:24, 27 November 2013 (UTC)
We don't switch {convert/3} to module:Convert for now, so existing {convert/3} will keep using the markupcode subtemplates as before. In other words: {Convert/3} will not notice the primary switchover. So from this issue, there is no argument at all to discharge the module. -DePiep (talk) 22:34, 27 November 2013 (UTC)
I fixed the only instance where convert/3 is used in an article at Simple (diff) nearly two days ago. Johnuniq (talk) 03:36, 24 November 2013 (UTC)
I see no real positives, and only incompatible glitches. We have {convert|3:45 pm|time|24}} as "[convert: invalid number]" but the Lua module shows "[convert: invalid number]". -Wikid77 (talk) 22:24, 27 November 2013 (UTC)
  • Strong oppose: All the incompatibilities and glitches are being ignored, such as:
The value "8.26 hands" is nonsense and should be fixed before Lua is used. There are no significant reasons to switch to Lua until the glitches have been fixed first; otherwise fixing each glitch in Lua will trigger reformatting 552,000 articles for each Lua edit. -Wikid77 (talk) 22:24, 27 November 2013 (UTC)
  • Support, things seem to be working quite well, all things considered. Sure there might be a few bumps during the initial rollout, but it is not realistic to expect perfection straight out of the gate. Gods know the existing template system has suffered more than its share of glitches over the years. It pains me to say this, but I'm highly disappointed by Wikid's apparent unwillingness to help with the rollout. I applaud his and others efforts to maintain the current system, but the Module is definitely the more robust (and easier to manage) way forward. — Huntster (t @ c) 00:28, 28 November 2013 (UTC)
I have assisted in testing the Lua version, for months, but I just cannot "Support" a system-wide rollout of a complex Lua module which I (or most admins) cannot understand how to update to fix problems for users, where formerly, many of us could fix almost any request within a few minutes or perhaps 2 hours, by tracing through the 10 short subtemplates used and looking for the related code. With Module:Convert, there are "3,334 lines" of Lua script, plus over 9,000 lines of data settings, and if a user asked for a new unit which defaulted to show fractional results as "xx/100", then I would be unable to help within days, or most likely weeks, except to quickly add the new unit to {convert/old}, probably within a few hours, then submit a request for the Lua module to be expanded in coming months to process another complex unit. Also, I think Module:Convert should be split into parts, such as one for distances, another for weights (etc.), where changing the default precision of troy ounces would not trigger reformat of all 554,000 pages using Convert. Fortunately, we can retain Template:Convert/old to handle quick requests, but I would rather wait a few months, to have Lua-Convert how-to guides which explained setting precision of results or showing custom output (fractions), rather than typical decimals. This rollout is too wide, too soon. -Wikid77 (talk) 13:21, 29 November 2013 (UTC)
Sue, can you elaborate on what is confusing? — Huntster (t @ c) 22:23, 1 December 2013 (UTC)
That is a very good question, Hunter, so I decided to look into it and see for myself. While this roll-out is a big one, close inspection has shown me that it is actually pretty straightforward. "Big" doesn't necessarily mean "Confusing". I have decided to reverse my opinion. I encourage others not to make the same assumption that I did. Thank you. --Sue Rangell ✍ ✉ 22:46, 1 December 2013 (UTC)
Thank you, Sue, for your reply and reconsideration. — Huntster (t @ c) 03:29, 2 December 2013 (UTC)
Try system-wide roll-out after the maintenance documentation has been written, major bugs fixed, after a smaller roll-out has been run and analyzed (such as inside Template:Height), and after a transition plan has been written to explain handling of incompatible features. BTW: Known bumps in the roll-out are being ignored "expeditiously" and certainly not resolved.
See below: "#Propose hybrid Convert 10% Lua". -Wikid77 17:18, 3 December, 09:30, 8 December 2013 (UTC)
  • Support Neutral at this time as I need to spend some time with the test cases first. It would seem from the discussion above that this is mostly ready. I would like to see it working as a replacement module for those sub-templates such as {{Convert/3}} etc before deployment, and will play with the sandbox/testcases to see if I can figure out why there is difficulty with this. Other than that, it is looking like this will be a support from me in the near future. Technical 13 (talk) 17:40, 9 December 2013 (UTC)
The Lua version has limited support for 3-number conversions, but the problem is overloaded use of parameter 2 for general text phrases, plus unit-codes, so the 19 wp:wrapper templates (Convert/3, Convert/flip3, Convert/text3, Convert/f, Height) were tested to provide long-term additional options, layered atop whichever Convert version is installed. -Wikid77 20:47, 9 December 2013 (UTC)
re Tech 13: {{Convert/3}} is considered a wrapper. That means it is or can be called without invoking the parent {{convert}} (be that in markup or lua code). For this reason each wrapper can be switched into Lua module later on, controlled (by replacing, then, template {{convert/3}} with {{convert}} in articles). So there is no requirement to make these failproof before this convert switchover. -DePiep (talk) 21:09, 9 December 2013 (UTC)
DePiep, I do believe there is a communication gap here. I understand that all of those templates are wrapper templates. What I'm saying is that whatever is put in to {{#invoke:Convert|convert}} should come out the same on the other end as if it was put in to {{Convert}} and if that is the case, then all of the wrappers (while not needing to be converted to Lua themselves) would work the same as they do now. I hope that isn't more confusing than clarifying. xD Technical 13 (talk) 01:03, 10 December 2013 (UTC)
Yes I understand. I am saying that it is not necessary to have these covered & tested OK in the first live version of convert module. -DePiep (talk) 01:11, 10 December 2013 (UTC)
Thank you, so I had to test Template:Convinfobox using {convert} in 157,513 pages (aka nightmare). -Wikid77 04:03, 10 December 2013 (UTC)
  • Not sure why you chose to put that here, or what relevance it has to this conversation, but I thank you and have looked at it. It hasn't swayed me however, and can just be added to the list of other things that may need a few tweaks once the conversion is complete. Technical 13 (talk) 04:31, 10 December 2013 (UTC)
As Tech 13 says; have fun with the testcases I'd say. I can add for wikid77: you did exactly not "have to" test {Covinfobox}, because it is outside of lua conversion for now. (It is also one of your "10%" postponed templates - why do you still not get that?). Wrappers will be converted later and give us relaxed time to test. Absense of time-pressure is very good for testing and makes nice working. -DePiep (talk) 09:27, 10 December 2013 (UTC)

Convert/x

In response to the points raised by Technical 13 above, I have spent many hours pondering what I call "convert/x", meaning templates like {{convert/2}}, {{convert/3}} (and quite a few more). The major problem is that each of these has inconsistencies with the current convert, and they have odd properties that only a couple of editors would expect.

DePiep has correctly pointed out that the wrapper templates could be updated if necessary so they work after the module is deployed, but it is my intention to replace all occurrences in articles within a couple of weeks. It would be much better to reduce the number of things editors need to know to use convert.

I put a static list of all convert/x that were in articles at 4 November 2013 at User:Johnuniq/Convertx—the wikitext is exactly what is produced by the templates as at a couple of hours ago. Generally, the following rules allow a convert/x to be converted to convert using the module (I'll do this eventually): 

Omit "/2" to change "convert/2" to "convert"; same for "/3" etc.

Replace all occurrences of LHS with RHS:
  |x|             →  |*|
  | x |           →  |*|
  |×|             →  |xx|
  |&nbsp;x&nbsp;| →  |xx|
  |&times;|       →  |xx|

For "convert/flip3", need to insert "disp=flip".

Other issues:

  • Some convert/x templates have a different default output unit from convert, so the displayed results will change in a few cases.
  • In one case ({{convert/3|35|x|75|x|17}} in Castle of Pombal), the input unit was omitted, and it defaulted to m. That has been fixed now.

There are more examples of convert problems currently in articles which need fixing at User:Johnuniq/Convert problems. They will be easier to find after deployment because the two error categories (listed in the docs at Module:Convert) will show problems after a delay of hours or days. Johnuniq (talk) 03:17, 10 December 2013 (UTC)

One issue could be introduced. When a {convert/x} is used yesterday through {convert} (markup), tomorrow we won't see that usage distinguished (because all would go through {convert} (lua)). These usages won't show up in a simple what-links-here list any more; we can not convert to them later. (This is different from calls directly through {convert/x}).
I have listed these {convert/x} templates and their usages in mainspace: User:DePiep/convert wrappers. All their pages are listed. A cleanup (preventing Lua error messages) could consist of preview-ing a lua working per page, or prevent usage of such a {convert/x} at all.
Three "wrapper" templates (wrapper by feature that is) have usages of 10k+ pages, too much to handle. But they are stand-alones, like {{Convinfobox}} (with 150k transc's), not subpages like {convert/x}. They would only cause a problem when {convert} markup would call them (i.e., {convert} in markup calls a standalone template?!). -DePiep (talk) 16:51, 10 December 2013 (UTC)
Good. I've put some notes on User:DePiep/convert wrappers. Johnuniq (talk) 02:02, 11 December 2013 (UTC)

Propose hybrid Convert 10% Lua

Alternative proposal: Due to the massive impact of reformatting all 554,000 affected pages for any changes to the Lua script Module:Convert, I propose instead a partial system-wide rollout of Lua Convert to affect only 60,000 pages, as an initial 10% introduction. This initial form would redirect {convert} to a hybrid, combined Template:Convert/hybrid, which only used Lua for a few unit-codes, such as "cm" or "in" (plus: g, ml, m/s, to) but not "m" or "ft" or "km" until later. Now, the initial rollout would still trigger the 8-day(?) reformatting of all 554,000 pages which use {convert}, but most of those pages would remain unchanged, as using the markup-based Convert subtemplates, while 10% of pages would begin using the Lua module. The advantage comes with the 2nd edit to the Lua Module:Convert, which would only trigger the reformatting of 60,000 pages (not 554,000), and hence allow 9 more various Lua updates, over the coming weeks, during the same time period originally intended to reformat all 554,000 pages after only one Lua update to Module:Convert. That 10x faster turn-around could also collect reformat-duration data, to clock how many days were needed to install a new feature in the Lua Convert to appear among all the linked pages. The hope is that a new feature could be added to Lua Convert, and appear system-wide within only 2 days, rather than 2 weeks to reformat all the Lua-based pages in a wp:job_queue. After some weeks of the partial system-wide testing, then the Lua unit-codes could be expanded to include "km" and "mi" (miles), as broadening the coverage to +180,000 pages (~250,000) to reformat for each edit to Module:Convert. This hybrid release would allow both the Lua and markup versions of Convert to continue in operation side-by-side, mixed in any pages, with no fear of losing features of either version during the transition period. Support/oppose or comment below. -Wikid77 09:30, 8 December 2013 (UTC)

  • Often an article with convert uses it for a variety of units, so using the module for some units now, and some other units later, with more units after that, might mean that pages are reformatted three times rather than once. If Wikipedia grinds to a halt when the module is switched on, we can have a discussion (including with the developers who would want to know that their system is broken), and if necessary turn the module off. There are regular changes to the CS1 module, used on over two million pages, and things appear to be running smoothly (see notice of next update). The citation module has to deal with frequently broken free-form text used as parameters. By contrast, converts are much more structured, and there should be no need for even weekly updates after a month or two. The module found 500 broken articles so there is reason to believe the module will benefit the encyclopedia. Johnuniq (talk) 02:22, 9 December 2013 (UTC)
  • Note that a link to here with another tirelessly long message has been repeatedly posted on VPT today. Matma Rex talk 18:09, 9 December 2013 (UTC)

Opinions of hybrid Convert

  • Support as nom, for 10x faster Lua updates. -Wikid77 09:30, 8 December 2013 (UTC)
  • Strong Oppose breaking it down into tiny sections as this is tedious and counter productive. Just as a user gets familiar with the idiosyncrasies of one revision, more gets converted and they have to start the learning curve all over again. Let's just make sure the code is all correct and do it in one shot so that it can be done with and our editors don't have to go through a painful cycle of 10%, 20%, 25%, 30%, 33%, ... 100% and having to relearn/re-adapt at every stage. Technical 13 (talk) 17:37, 9 December 2013 (UTC)
There are only the 2 versions, Lua or markup-based, and users have to learn the Lua idiosyncrasies eventually, but Convert/hybrid limits the impact of the Lua features until more users have time to adjust. Wikid77 (talk) 20:22, 9 December 2013 (UTC)

Postpone transition another month

Refactored for {convert/old}. -Wikid77 06:55, 11 December 2013 (UTC)

Due to all the problems in the Lua version of Convert, here and on Simple Wikipedia and on Wikimedia Commons, I suggest to wait another month, to allow time for further adjustments of the Lua Module:Convert, and resume discussion on 24 December 2013. Meanwhile, we should address the following issues of precision and options:

  • {{convert/old |105|-|106|F|C}}            →
  • {{convert/sandboxlua |105|-|106|F|C}} → 105–106 °F (41–41 °C)
Is not resolved in old-style template: {convert|43|-|45|lb|kg}} → (from below). So a full solution is not a pre-requirement for module. -DePiep (talk) 19:41, 23 November 2013 (UTC)

Spelling parameter "sp=" empty:

  • {{convert/old |7|m|ft|sp= }}            →
  • {{convert/sandboxlua2|7|m|ft|sp=}} → 7 m (23 ft)
A empty spelling parameter isn't defined in the documentation as valid, so I don't think it's a issue.→AzaToth 17:03, 23 November 2013 (UTC)

Option "abbr=def" as default:

  • {{convert/old |3|km|mi|abbr=def}}             →
  • {{convert/sandboxlua2 |3|km|mi|abbr=def}} → 3 km (1.9 mi)
abbr=def is an undocumented internal feature, and shouldn't be exposed outside. →AzaToth 17:03, 23 November 2013 (UTC)

The unit-code as "/sqin" for per-square-inch, with "/cm2":

  • {{convert/old |45|/sqin|/cm2}}    →
  • {{convert/sandboxlua |45|/sqin|/cm2}} → 45 per square inch (7.0/cm2)
New addition to the convert templates, isn't the modules fault. →AzaToth 17:03, 23 November 2013 (UTC)

Ranges with no difference in results:

  • {{convert/old |43|-|45|lb|kg}}            →
  • {{convert/sandboxlua |43|-|45|lb|kg}} → 43–45 pounds (20–20 kg)
I don't see any difference here, please explain. →AzaToth 17:03, 23 November 2013 (UTC)
Same topic as example 1 (105 F), but here does the wikicode not refine it either. So a feature request for both. A solution is not a requirement for module. -DePiep (talk)

After resolving those types of issues, then a transition plan, to install Lua Convert, can be finalized. -Wikid77 (talk) 12:18, 23 November 2013 (UTC)

and Template:Convert//cm2 was just created less than a week ago, yet another reason for a feature freeze. Frietjes (talk) 15:57, 23 November 2013 (UTC)
All x[Convert:...] message pages (mainspace) appear in a maintenance category, ready for a cleanup. These massages do not disrupt a page; they're just inline tags, we use often. A lot of these can be cleaned by editing the page. Then the remaining issues can be dealt with by module maintenance. At worst there could be a disruption on a page for two days. No blocker.
And now the bigger picture. The last months, with module:convert nearly ready, there have been drip-drip additions to the old template, often undocumented. The old template keeps throwing changes, expecting the module to catch them somehow. Even if the module would keep up with these, there shall never be a final moment for switchover. Simple because the template won't let go the initiative. Not an uncommon situation in software development — just a task to break the ban. (And why would there be a better moment after December 24? What is different then? You could have a point, Wikid77, if that involved a freeze & document promise from your side. Something that is way late now).
So the minor issues end up in the category, and the major issues: a. "we" can edited in module code within days, or b. when they appear to be devastating, we switch back to wikicode template (this backup option I discussed earlier). Safe enough.
Already Johnuniq declared a one-sided feature freeze for the module on November 21 (or earlier). All old-template changes since are read as requests for the new one. Good and fine, we can deal with these later on (we'll just read the documentation changes). I propose to give it a go. Important element of the proposal is to proceed independent of old-template development, for all the process reasons given. -DePiep (talk) 19:21, 23 November 2013 (UTC)
Wikid77, already on November 1 you approved the module [1], and through the backdoor you put it live in mainspace. That contradicts your post here. -DePiep (talk) 05:57, 24 November 2013 (UTC)
I suggest to explicitly limit the first introduction to {{convert}}, and not to wrapper & side templates like {{convert/3}} (we could use a complete list). -DePiep (talk) 09:20, 24 November 2013 (UTC)
Started categorizing those wrapper templates: .../wrapper templates. This is a technical list to give template development an overview. For the article editors with "which converts are there for me to use", there is the sanitised cat:Convert templates. You are invited to look out for more of those wrapper templates, and add them to the cat. -DePiep (talk) 07:32, 25 November 2013 (UTC)
Message to Johnuniq. About the {convert/...} wrapper subtemplates (those are called directly from mainspace, circumventing {convert} central office). I repeat: best explicitly limit the first introduction to {{convert}}, not any other {convert/...} template. Adding those to the switchover, would unnecessary enlarge the fist wave of issues (unnecessary because you can prevent it). Also there is this: the list of such wrapper subtemplates is incomplete and unknown. You might see someone switchover an obscure {convert/AnotherNiceFeature} adding to all the issues.
In practice you can declare all such sideway switchovers "controversial" beforehand, what would make such a switchover illegal without discussion its merits. -DePiep (talk) 07:47, 25 November 2013 (UTC)
More on the wrapper templates. "Wrapper templates" use convert but not through the {convert} main entrance, but e.g. by calling a /sub directly from mainspace. They are collected in cat:wrapper templates (~20 P, incomplete, some not arrived yet). They include {{convert/3}}, {convert} {{Height}} (100k transc's), {{Convinfobox}} (150k transc's). Exactly all these can be postponed easily (by not converting these templates), while converting {{Convert}} first. I'd love to hear Johnuniq say what the process in this will be. -DePiep (talk) 22:03, 26 November 2013 (UTC)
The wp:wrapper templates almost always use Convert through the {convert} main entrance, such as Template:Height which calls "{convert|..}". Hence, I had to test to ensure the wrappers would work without Lua Convert completely derailing their operation. -Wikid77 (talk) 18:39, 3 December 2013 (UTC)
Reply to Wikid77 regarding the "fork" remarks. (These remarks were made three days ago somewhere else, I just found that this 'fork' issue needed a response). Wikid states that it is the *module* the creates a "Lua Convert fork", writing: the Lua version has diverged as a fork with different features, incompatible with the markup-based Convert. The easiest reply is: which {convert} version is forked? In markup code there exist dozens of {Convert} forks. Many of these were added by Wikid77, often without documentation or any useful presentation/listing at all. So the question is better asked: which {convert} behaviour, documentated preferably, should be the standard to test Lua against? But alas, lets not lean on a "you were first" calling.
I can not see where the module is actually forking, i.e., having different behaviour or producing something different. So far, all module features produce one single behaviour. It already is covering some ten {convert} forks like {convert/2}. So the module is actually unforking current templates.
As for markup-features not (yet) covered, Wikid77 better point to a mirror: unwillingness to feature freeze and to reach agreements causes this diversion, but as one should know by now they are intended to be added after module:Convert is introduced and stable. (Next time I have to explain this, I might be using stronger or louder language).
Maybe Wikid77 is confusing "forking" with "different outcome". Yes, the module has changes superimposed on existing documentation/behaviour of markup {Convert}. All of these are motivated, for example in language, numerical, or formatting reasons. They are undisputed improvements to the older workings. I can see no problem in this, and no claimed "incompatability". So I conclude: module:Convert is unifying the existing forks, and diversions are either feature-freezes or reasoned improvements. -DePiep (talk) 17:20, 27 November 2013 (UTC)

There is no reason to delay deployment:

  • Frietjes has defined /sqin and /cm2 so the convert using them works with the module.
  • Warnings for things like empty "sp=" and undefined "abbr=def" will not occur because warnings will not be enabled when the module is deployed (because there are too many broken converts which will need to be fixed before worrying about invalid options that are ignored). Later, when warnings are enabled, the fix I mentioned at #Changes to module means warnings will not occur for these items anyway.
  • The tricky ranges which give the same "from" and "to" output values would be very rare, and can be worked around by manually specifying a suitable precision. For example:
    • {{convert/sandboxlua|105|-|106|F|C}} → 105–106 °F (41–41 °C)
    • {{convert/sandboxlua|43|-|45|lb|kg}} → 43–45 pounds (20–20 kg)
    • {{convert/sandboxlua|105|-|106|F|C|1}} → 105–106 °F (40.6–41.1 °C)
    • {{convert/sandboxlua|43|-|45|lb|kg|1}} → 43–45 pounds (19.5–20.4 kg)

Any problems introduced by the modules should be weighed against the fact that the modules would fix a lot of problems—see these examples of bugs in the current templates. Johnuniq (talk) 09:49, 24 November 2013 (UTC)

I fixed most of the listed bugs within 5 days, because markup-based Convert is relatively easy to update for changes, for users who have the wp:template-editor right, and hours to test changes. -Wikid77 19:02, 3 December 2013 (UTC)

Suggestion re in-line error messages: Deploy them in the same way that they have been deployed for CS1 citation error messages. That is, have them default to hidden, but allow interested editors to display them through a modification to their personal CSS file. Interested editors could look at the error categories, pick articles to fix, see the in-line error messages in those articles, and fix the problems. Once the number of errors is down to a reasonable level and key module bugs are fixed, change the module to display errors for all editors. – Jonesey95 (talk) 23:33, 24 November 2013 (UTC)

Possibly, but editors (particularly the person who just added an invalid convert) need to see the problem without getting help to do scary CSS modifications. The citation templates were displaying large numbers of messages because the refs have accumulated lots of gunk, and many of the messages are technical in nature (they don't affect what is displayed, and they often cannot be readily fixed by average editors). By comparison, converts have almost no extraneous text, and a problem needs to be reported plainly. The messages are pretty harmless, for example:
Sampling many articles suggests there won't be a major amount of breakage. Johnuniq (talk) 01:16, 25 November 2013 (UTC)
Warning: WP:FORUMSHOPPING around [2]. I find it strange that Wikid77 replies somewhere else re his {{convert/g}} manipulation mentioned above. And I find it appalling that the linked post tries to introduce that Lua is forking, written by the very person who does not want to commit to feature freeze.
For this inconsistency, I declare all edits by Wikid77 in this Lua module controversial, including live switches to this module (like the {convert/q} example). This implies that Wikid77 should discuss a proposed edit on the right page into agreement, before performing it. -DePiep (talk) 08:14, 25 November 2013 (UTC)
@DePiep, the Lua version is a fork of the markup-based Convert, which has existed since December 2006, and I have been editing hundreds of unit subtemplates of Convert for 5 years, but now you want me to stop and get permission for every edit. Plus you insist on a "feature freeze" for both the Lua and markup versions of Convert, when they both need to be improved, not frozen to lock the current bugs in place. You are trying to circumvent WP policies and impose "barking no-edit orders" against other users. Please observe wp:Consensus and seek voluntary agreements with others, not force people to obey your commandments. -Wikid77 (talk) 19:26, 3 December 2013 (UTC)
Wikid77@ Show the diff or withdraw your remark. -DePiep (talk) 19:45, 3 December 2013 (UTC)
reply to Wikid77. Many weeks ago I reasoned why it would be useful to agree on a feature freeze during switchover. You declined by elusion (no diffs needed now given your still diff-less post above). I then argued that module introduction should proceed, and proceeding independent of the markup code template, simply because there was no coordination sought, wanted, or possible with markupcode development. Not ideal for the whole, but at least preventing that module development would be taken hostage by lack of cooperation. This implied that you could go ahead with your edits (!!!). This explains why there are no diffs for your accusation. After that, I repeatedly advised not to do some edits, with reasons. If you found my reasons so convincing there read like forbidding: good for me, thanks. Apart from this, you embarked on indirect covert replies on separate pages. You also started contradicting your own statements. Sort of funny: putting 550k pages in the queue was so bad the module should be blocked, and a day later you did it yourself. Also: stating that the module was forking, while creating dozens of forks and counting. Way to go. One more thing. Next time, Wikid77@, you accuse you provide the diffs right away. For this one, I expect you excuse and strike your remark. -DePiep (talk) 19:18, 4 December 2013 (UTC)

Changes to module

I have made a small change to the module in my local files, and I will upload it to Simple because they are using warnings=on in the template to catch problems with template usage (there were around 30 issues like "link=on" instead of "lk=on", and they are probably all fixed now). The effects of the change are as follows.

  • The option abbr=def is ignored (the "def" means "use the default abbreviation", and that is what will happen).
  • Using warnings=on or warnings=1 in Template:Convert is regarded as "want serious warnings only".
  • Using warnings=2 in Template:Convert is regarded as "want all warnings".
  • An invalid option (such as sigfig=junk) gives a message when warnings is 1 or 2 or "on".
  • An empty option (such as sigfig=) only gives a message when warnings=2.

The above is useful because as Wikid77 says, there are some wrapper templates which have the provision to call {{convert}} using, for example, a sigfig parameter, and it is difficult for such a wrapper to omit the sigfig entirely if the field is not required. Instead, it's straightforward to generate sigfig= and expect that convert will ignore the missing option.

This change is not needed here as we will not be enabling warnings until other problems have been addressed, and these changes only affect what happens when warnings are enabled. I might put the changes in the sandbox (better get used to doing that), but the live modules don't need the change so continuing the freeze might be best (I'm happy to either include them or not). Johnuniq (talk) 03:58, 24 November 2013 (UTC)

I have put the changes in the sandbox modules. For anyone interested, the following can be used to show the diffs.

To demonstrate, consider the following: 

*<code>{{convert/sandbox|12|m|ft|abbr=def}}</code> → {{convert/sandbox|12|m|ft|abbr=def}}
*<code>{{convert/sandbox|12|m|ft|sp=|sigfig=}}</code> → {{convert/sandbox|12|m|ft|sp=|sigfig=}}
*<code>{{convert/sandbox|12|m|ft|sigfig=junk}}</code> → {{convert/sandbox|12|m|ft|sigfig=junk}}
*<code>{{convert/sandbox2|12|m|ft|abbr=def}}</code> → {{convert/sandbox2|12|m|ft|abbr=def}}
*<code>{{convert/sandbox2|12|m|ft|sp=|sigfig=}}</code> → {{convert/sandbox2|12|m|ft|sp=|sigfig=}}
*<code>{{convert/sandbox2|12|m|ft|sigfig=junk}}</code> → {{convert/sandbox2|12|m|ft|sigfig=junk}}
  • {{convert/sandbox}} invokes the sandboxed modules with warnings=on (only important warnings are shown).
    {{convert/sandbox2}} invokes the sandboxed modules with warnings=2 (all warnings are shown).

Johnuniq (talk) 10:12, 24 November 2013 (UTC)

Thanks. Just curious, will coming development be done in these sandboxes, or will you use other venues? -DePiep (talk) 15:38, 27 November 2013 (UTC)
I develop on a local computer using a few test scripts to roughly emulate bits of mw. I use that to fully test code (with an IDE for debugging problems). After that, I would work in the sandbox and do a few tests on wiki, before updating the actual modules. Johnuniq (talk) 21:00, 27 November 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Module handling abbr=def

Separated issue into section -DePiep (talk) 11:46, 21 November 2013 (UTC)
  • Trouble with abbr=def in Lua version on Commons: I tried to use abbr=def, as the typical default setting:
  • {{convert|9|m|ft|abbr=def}}               → 9 metres (30 ft)
  • {{convert/sandboxlua |9|m|ft|abbr=def}} → 9 metres (30 ft)
I thought the Lua version would have already handled "abbr=def". -Wikid77 (talk) 11:11, 21 November 2013 (UTC)
At Commons, I put warnings=on in commons:Template:Convert because they only have a small number of converts, and the problems may as well be fixed. The issue with abbr=def can be seen here using "sandboxlua2" which also has warnings=on:
  • {{convert/sandboxlua2|9|m|ft|abbr=def}} → 9 m (30 ft)
I have never seen abbr=def used in an article, and I have not seen any documentation for it. I have noticed it in a convert subtemplate, but I never worked out what it was doing. What is wanted? Is it necessary if it is not being used? Johnuniq (talk) 22:50, 21 November 2013 (UTC)
Eh, what is the documentation, what should it do? Looks like {convert|9|m|ft} is not altered by |abbr=def:
{convert|9|m|ft} → 9 metres (30 ft)
{convert|9|m|ft|abbr=def} → 9 metres (30 ft)
{convert|9|m|ft|abbr=on} → 9 m (30 ft)
{convert|9|m|ft|abbr=off} → 9 metres (30 feet) -DePiep (talk) 05:54, 23 November 2013 (UTC)
  • Option abbr=def is the default setting: The result with "abbr=def" is the same as "abbr=out" where formerly the default setting was called "abbr=off" which later became the same as "abbr=none" in a system-wide purge to reduce options (and have fewer subtemplates). Originally, there were only 2 settings: abbr=on and abbr=off (same as "abbr=out"), but users wanted an option with none of the units abbreviated (which became "abbr=none" renamed "abbr=off"), and meanwhile "abbr=in" was added for completeness as opposite of "abbr=out". Option "abbr=values" was requested to abbreviate the unit names totally, as only the values. Showing the referent symbol which refers to the input unit, as "abbr=~" is a recent option. Also, "abbr=comma" was added, per a user request, to abbreviate the commas. The option "abbr=def" is needed to allow specifying the option "abbr=" but have the default value "def" when passed by a wp:wrapper template. So, originally, all the values had been documented for users, where "abbr=off" was the default, but when "abbr=none" was renamed to "abbr=off" then "abbr=def" became an arcane internal code, undocumented and unknown to users and not discussed for consensus. That is the history behind "abbr=def" as a hidden option. -Wikid77 (talk) 11:17, 23 November 2013 (UTC)
Clear then. Next question: what is the issue to be handled by the module, if you can't point it? -DePiep (talk) 17:28, 27 November 2013 (UTC)
The results for "abbr=def" should be same as "abbr=out" and using "abbr=def" should never generate a warning message, but always be considered a valid option in Lua Convert. -Wikid77 19:47, 27 November 2013 (UTC)
never generate a warning message Warning suppression for what? Is that different for "abbr=out"? In general: why should the module support an input option that is not considered an option today, that has a published alternative, and that is hidden?
I propose: consider "abbr=def" an unsupported input option. Adds warning tag, lists in maintenance category. Edit articles to get rid of this one. -DePiep (talk) 20:31, 27 November 2013 (UTC)

Excessive rounding in ranges

Refactored for {convert/old}. -Wikid77 15:17, 11 December 2013 (UTC)

The default precision of conversions is still causing bizarre results, such as for a range of similar weights:

  • {convert/old|43|-|45|lb|kg}}    –    <--fixed
  • {convert/old|141|-|142|lb|kg}} – <--fixed
  • {convert/sandboxlua|141|-|142|lb|kg}} – 141–142 pounds (64–64 kg)

Clearly, a 3-digit amount should produce a 3-digit precision, but even the 2-digit weights should be sensible. There had been similar problems with temperatures, but they have been fixed:

  • {convert/old |105|-|106|F|C}}            →
  • {convert/sandboxlua|105|-|106|F|C}} → 105–106 °F (41–41 °C)

As several users have noted, the rounding tends to be over-rounding, which causes similar amounts to convert to the exact same output number. -Wikid77 (talk) 10:51, 20 November 2013 (UTC)

Wikid77, will you keep this in the fridge during switchover process? Or do you have an other process proposal? -DePiep (talk) 04:32, 21 November 2013 (UTC)
The alternative Template:Convert/hybrid would allow partial use of Lua Convert, but use markup-based Convert for most units and retain the fixed precision in ranges. -Wikid77 15:17, 11 December 2013 (UTC)

Range x has changed

Following the discussion above, Template:Convert at Commons has been switched to using the module. I have just downloaded the 1300 converts that are used at Commons to check that the module is handling their requirements (and to find any broken converts). I captured the output from each {{convert}} in Special:ExpandTemplates at enwiki, then compared it with the output from the module.

Everything is good (the module matches the templates in use here), except for converts like the following:

  • {{convert|9|x|12|in|cm|abbr=on}} → 9 in × 12 in (23 cm × 30 cm)
  • {{convert/sandboxlua|9|x|12|in|cm|abbr=on}} → 9 in × 12 in (23 cm × 30 cm)

Note that the module duplicates the symbol (only when abbreviated—it does not duplicate unit names). The templates used to do that! The current discrepancy must be due to a change in the templates since August (I have many "x" converts that I captured in August, and they matched the module).

Is this due to changes at Template:Convert/x/AonSoff and/or others? Was there a discussion? What is wanted? Johnuniq (talk) 03:19, 21 November 2013 (UTC)

I'd say, the module is right, because an area must be expressed in "in × in" (or equal "in2". The old tempate suggests it is a length ("in"), which is wrong. Thisa way the non-abbreviated units should be areal too, but that could be postponed till after switchover (because it does replicate the old template "correctly").
As for this change in general, I'd say the module is not required to catch up late changes. The old template should be feature freezed shortly before switchover. Then the module can catch up completely, and can promise equalness. There is no use in keep adding minor incremental changes to the old template, once the module has the lead. As noted above wrt the changeover process. -DePiep (talk) 04:29, 21 November 2013 (UTC)
Here is a case where the module fixes an error introduced somewhere along the track. The multiplication sign is a mathematical symbol and its mathematical meaning aught to be respected. The MOS acknowledges this.
  • Dimensions may be given using the multiplication sign or "by".
    • When dimensions are given using the multiplication sign each number should be followed by a unit name, abbreviation or symbol (e.g. write 1 m × 3 m × 6 m, not 1 × 3 × 6 m or 1 × 3 × 6 m3).
    • When dimensions are given using "by" only the last number need be followed by the unit name, abbreviation or symbol (1 by 3 by 6 metres is acceptable).
This, as noted above, was the original way the template treated dimensions. Jimp 08:50, 5 December 2013 (UTC)

Dual convert/spell

For Goblin shark, between {{convert/spell|3|and|4|m|ft|1|sp=us}} three and four meters (9.8 and 13.1 ft) instead of between three and four meters (10–13 ft) or even between {{convert|3|and|4|m|ft|1|sp=us}} 3 and 4 meters (9.8 and 13.1 ft). Peter Horn User talk 21:04, 24 November 2013 (UTC)

In the module, spelling is done like this (although only the input values can be written in words):
  • {{convert/sandboxlua|3|and|4|m|ft|0|sp=us|spell=in}} → three and four meters (10 and 13 ft)
Johnuniq (talk) 22:18, 24 November 2013 (UTC)

New feature: ftinfrac

  • New feature in old template: {{Convert/ftinfrac}}. Created October 19, another example of unhelpful feature dripping. Treat as late feature change, so post-introduction for the module. -DePiep (talk) 22:24, 26 November 2013 (UTC)
    • Yes, it's an interesting option. Using fractions in the output was discussed recently in relation to the "hand" length unit used for horses, and I thought about having something like |frac=4 to make the output display the nearest quarter rather than decimals. I think that would be quite easy, and it would apply to all units, and would allow other choices like |frac=16. However, as discussed, feature creep should not occur at this stage, and I intend waiting until any transition problems are fixed before thinking about changing the code. Johnuniq (talk) 00:52, 27 November 2013 (UTC)
Yes, just listing it here for a future check. -DePiep (talk) 16:17, 27 November 2013 (UTC)
Yes, as I understand it too. Here is one more checklist for late features: Category:2013 Convert unit subtemplates (... click in January 2014). BTW, I like the {Hand} conversion as a puzzle, solved. -DePiep (talk) 16:16, 27 November 2013 (UTC)

Wrapper templates

In response to DePiep's above category and comment at "22:03, 26 November 2013", my thoughts on the templates which call convert follow. They are a problem, and maintenance will be needed after switching convert to use the module. Recently that switch occurred at Simple and Commons, and some tweaks were needed to make everything work. Here things are much more complex, and some tricky editing of the wrapper templates may be required. Anyone concerned about breakages in articles during a transition period should bear in mind that the thousands of existing convert templates have problems of their own (examples of bugs).

I have not followed the changes made by Wikid77 in the last few weeks, but a couple of months ago I checked all usage of most of the wrapper templates in articles and convinced myself that the module could produce satisfactory results. Some wrappers have extra features that are not implemented in the module, but those features appeared to be unused when I checked (possibly with a couple of exceptions). I checked these:

{{convert/2}} ∙ {{convert/3}} ∙ {{convert/4}} ∙ {{convert/f}} ∙ {{convert/flip}} ∙ {{convert/flip2}} ∙ {{convert/flip3}} ∙ {{convert/flip4}} ∙ {{convert/scale}} ∙ {{convert/spell}}

Usage of the above will need to be checked and adjusted to use the module. In a couple of cases it may be necessary to introduce a wording workaround to give a satisfactory result because the module does not support arbitrary join text between items in a range. The fact that the module has limitations can be seen as a feature because it already supports a bafflingly large number of options, and I doubt that more than a handful of editors know how to find more options.

Here is an example from Nybergsund showing what would be needed to replace one wrapper:

  • {{Convert/scale |2.6|million litres|U.S. gallons|a=265384.615385|r=0}} →
  • {{convert/sandboxlua|2.6|e6l|U.S.gal|abbr=off}} → 2.6 million liters (690,000 U.S. gallons)

From Ballochroy (note that the first output has " ," with a space before the comma):

  • {{convert/flip3|3.5|,|3.0| and| 2.0|m|ftin|abbr=on}} → {{convert/flip3|3.5|,|3.0| and| 2.0|m|ftin|abbr=on}}
  • {{convert/sandboxlua|3.5|,|3.0|and|2.0|m|ftin|abbr=on|disp=flip}} → 11 ft 6 in, 9 ft 10 in and 6 ft 7 in (3.5, 3.0 and 2.0 m)

From Blue Origin:

  • {{convert/f|100000|lbf|kN|x3=about|lk=out}} → 100,000 pounds-force (about 440 kN*)
  • {{convert/sandboxlua|100000|lbf|kN|disp=x| (about |)|lk=out}} → 100,000 pounds-force (about 440 kN)

From Taiko:

  • {{convert/show2|6|shaku|cm|ft|r3=1}} → {{convert/show2|6|shaku|cm|ft|r3=1}}
  • {{convert/sandboxlua|6|shaku|cm ft}} → 6 shaku (180 cm; 6.0 ft)

The option r3=1 used by convert/show2 is not available in the module. In the above, it does not matter. In other cases, we would have to live with the fact that if a precision is specified, then it applies to all outputs (that's how converts have been done for years—a new option could be introduced later, although some rethinking of how to specify the formatting would be desirable).

Some wrappers will work unchanged because they call subtemplates which will continue to exist. Others will need tweaks when articles appear in the error categories (which are listed in the documentation at the top of Module:Convert). Some interesting new wrappers such as {{convert/E}} are used in very few articles, and in the worst case, breakages could be replaced with plain wikitext (no templates) while we decide what to do. In the unlikely event that there are hundreds of breakages that cannot be fixed quickly, we will switch the template back to the old system. Johnuniq (talk) 00:43, 27 November 2013 (UTC)

My question is, Johnuniq: will you switch over to Lua any of these wrappers simultaneously yes or no? -DePiep (talk) 11:38, 27 November 2013 (UTC)
No, I'm thinking of changing only {convert}. Then I would hope to spend a couple of days editing articles to remove usages like {convert/show2}, replacing them with equivalents using the new convert. Johnuniq (talk) 20:55, 27 November 2013 (UTC)

{convert/nonlua}

I have created {{Convert/nonlua}}. It is an exact code copy of today's {{Convert}}. Purpose: once the main template is switched to Lua, we can use this one when we want to circumvent the module. Examples, in situation after switchover:

  • Say, old {Convert|10|limb|feather} worked fine with {Convert/limb_to_feather}, but the new module does not handle these units correct. It is judged as a serious page disturbance (more than just a maintenance superscript). An editor then can edit the offended article pages to use the old style markup: {Convert/nonlua|10|limb|feather}. The article shows fine now, and Module maintenance/coding then can address this issue without time-pressure.
Module maintenance (code editors) can follow the WLH list for this template.

Caveats

  • The /nonlua template does not shield us from changes in the whole {convert} markup template family. So, any change made in January 2014 in {Convert/anypage} will be shown by this template (and not the 1 November 2013 outcome).
This because there is not feature freeze for the markup version.
  • Feature edits in the markup code after circa 1 September 2013 are not reflected in the module.
  • The template does not categorize or classify. WLH list is the only connection. Exact copy code is more important than adding code to it, even a categorisation or so.
  • It only exists for main template {Convert}, not for forks like {Convert/2}. tbd.
  • Less useful when used in large volumes in a single issue (say, 100 pages changed for issue x). Module maintenance could find an other solution for these.
  • This template is declared "deprecated" from day 1: only to be used as a temporal or testing device. It may not be used to circumvent the module, and not for minor issues (those that are tagged with superscript links). -DePiep (talk) 13:51, 27 November 2013 (UTC)
Think twice. It has a diff with the original, it has the omnious "original family of small subtemplates" as target, it no document stated such a thing, and the name "old" is not very exact. Plus, of course, we must expect edits in that one (because it is not explicitly stated otherwise) so it is unstable for this purpose. -DePiep (talk) 22:06, 27 November 2013 (UTC) -DePiep (talk) 11:16, 9 December 2013 (UTC)

automatic conversion targets

I noted in the examples that some unit conversions can be done just with a specification of the source unit: {{convert|30|GJ}} -> 30 gigajoules (8,300 kWh). Is that documented somewhere? I would expect this in the table "Units supported" (can be seen in the individual convert subpages like GN as o= parameter) . --mfb (talk) 15:20, 27 November 2013 (UTC)

  • Convert "disp=u2" shows default 2nd unit: There is an option (as "disp=u2") which can show the default output unit, but the original Convert/list_of_units did not list the default 2nd unit. Currently:
  • {Convert|1|GJ|disp=u2}} → 1 gigajoule (280 kWh)*
  • {Convert|1|GN|disp=u2}} → 1 giganewton (220,000,000 lbf)*
  • {Convert|1|km|disp=u2}} → 1 kilometre (0.62 mi)*
  • {Convert|1|C|disp=u2}} → 1 °C (34 °F)*
In practice, the default units have been obvious when Convert is used in those cases, because the default unit has been chosen to be the typical related unit. -Wikid77 (talk) 18:40, 27 November 2013 (UTC)
See testcases. -DePiep (talk) 19:28, 27 November 2013 (UTC)
We are planning to switch to a new system which uses Module:Convert/documentation/conversion data/doc as the master list of units. It's complex, but it shows the default output (almost always the same as in use currently). Johnuniq (talk) 20:52, 27 November 2013 (UTC)

Fixing old Convert glitches

Refactored for {convert/old}. -Wikid77 15:24, 11 December 2013 (UTC)

I am in the process of fixing dozens of glitches in the various subtemplates of Template:Convert, with many issues noted in User:Johnuniq/Convert_notes, as prior broken features of Convert. The analysis, when fixing the glitches, has confirmed numerous problems, as well as limited functionality where many options have not been implemented in the old Convert, but would be provided by the Lua version. Fixing these old glitches is a first step to showing how the Lua version already provides the equivalent option with correct results. Among the fixes has been the setting of commas in mixed numbers above 1,000:

  • {{convert/old |2500+4/5|mi|km}}             →
  • {{convert/sandboxlua |2500+4/5|mi|km}} → 2,500+4⁄5 miles (4,024.6 km)

Most of the fixed glitches involve reformatting only a small subset of the pages which use Convert. However, fixes to Template:Convert/numdisp will trigger reformatting of 510,000 pages for the following problem of extra "000,000" zeroes in negative numbers with &minus:

  • {{convert/old |&minus;4|m|ft}}             → , previously "–4,000,000"
  • {{convert/sandboxlua |&minus;4|m|ft}} → −4 metres (−13 ft)

I will postpone the fix to {convert/numdisp} until ready to reformat all pages which use Convert. -Wikid77 (talk) 17:20, 28 November 2013 (UTC)

Just read someone who claimed that redoing 550k pages is a bad idea. What do you think, Wikid? -DePiep (talk) 18:08, 28 November 2013 (UTC)
  • Fixes are correcting issues not forking: The glitches in the markup-based Convert were incorrect, and should not be mirrored in the Lua version. In most cases, the Lua version was already correct, and the results are the same, such as:
  • {{convert/old|1|kWh|BTU}}             →
  • {{convert/sandboxlua|1|kWh|BTU}} → 1 kilowatt-hour (3,400 BTU)
It is better to fix known bugs, now, so that the operation of the Lua module would not differ in results from {convert/nonlua}, as less confusion for people comparing both. -Wikid77 (talk) 20:38, 28 November 2013 (UTC)
Not broken, so no need to "fix" anything. And sure it is a feature fork, because the documentation (describing this) would be different. Given the status of the module, this would cause issues. And you know it. -DePiep (talk) 07:16, 29 November 2013 (UTC)
Actually, after re-reading I now understand that you are forming the nonlua template towards the lua workings. So first of all I do applaud that, because it is indeed a convergence of the two, toward that improvement.
Now I have left one argument for postponing you introducing this: the work and the mixup of issues before & during the upcoming module introduction. Any errors introduced by this change (in 550k pages) may go unnoticed (they are not detected but by view). Also such checks & edits are interfering with upcoming lua-induced edits, adding confusion. This is what I suggest: why not make the change after lua-switchover? It will affect (improve) the remaining nonlua usages and still be the improvement you aim at. -DePiep (talk) 08:45, 29 November 2013 (UTC)
Adding: it is granted that {{convert/nonlua}} is not promising pre-lua results. Full stop. After module introduction, the nonlua {convert/...} subtemplates may change (all, except {{convert}} and {{convert/nonlua}} ;-) ). In case of an emergency, page {convert} may be switched back to the markup code, operating with the later changes (backup function). Given this, for this /numdisp change there is no absolute blocking reason or moment, except for a bit of thinking. -DePiep (talk) 09:25, 29 November 2013 (UTC)

Splitting date/time and music conversions

Because of the current complexity of the Lua version, in combining all forms of measurement conversions into a single Lua script page, Module:Convert, I propose that we rework the time-of-day, date, and music conversions as separate templates, outside of Convert, and discontinue unit-codes "time" or "date" or "note" (etc.). In the new split, Template:Convert/time would become a self-contained template, which would no longer use {Convert}:

  • Old: {{convert|2:17 pm|time|24}} → 2:17 pm (14:17)
  • New: {{convert/time|2:17 pm|24}} → User:Wikid77/Template:Convert/time - fix as "14:17"
  • Old: {{convert|29 Nov|date|day}} → 29 Nov (day 333)
  • New: {{convert/date|29 Nov|day}} → {{convert/date|29 Nov|day}} - same result

As each time/date subtemplate is rewritten, then the affected pages could be soon edited to remove unit-code "time" or "date" etc. People who have used those unit-codes would be directly notified to use the new template names, and the Lua version could report the prior "time" or "date" units as "unknown unit". -Wikid77 (talk) 17:20, 28 November, 11:09, 29 November 2013 (UTC)

Why forking? -DePiep (talk) 17:39, 28 November 2013 (UTC)
The Lua module offers many advantages beyond the markup-based Convert, with more options already available today such as for speed conversions, and so splitting the non-numeric conversions away from Convert will enable a faster transition to the Lua-based Convert, while also allowing time or date conversions to be expanded with more options without triggering the reformatting of the 554,000 pages which use the measurement form of conversions. So, when the transition to the Lua module is made, then no one could complain that time, date or music conversions no longer worked, but were running instead with new template names. -Wikid77 (talk) 20:38, 28 November 2013 (UTC)
Fully agree. {{Convert/time}} then to be used directly in article pages. Will be one of the wrappers. Those pages better be edited for this soon! They are young subtemplates, numbers are low.
Lua-glasses then can look at this one later. Same for {{Convert/date}} and {{Convert/music}} then? Note: I won't edit these articles unless asked. Did do: {{Convert/runtime}} (partly done) -DePiep (talk) 09:04, 29 November 2013 (UTC)
Sidenote: could you take a look at Newsbeat, input for {{Convert/runtime}} should be ok this way? -DePiep (talk) 10:00, 29 November 2013 (UTC)
It seemed fine, but I also edited (convert/runtime} for Template:Convert/time, as stand-alone mode, and removed each optional parameter "|time" as no longer needed there. -Wikid77 11:23, 29 November 2013 (UTC)

All converts

I have extracted all converts from all articles by parsing a dump file. My scripts for doing that are slightly broken, and they have only just run for the first time, but a preliminary page of results is here. That shows 360 converts in articles which give "unit mismatch" in the module. I have not looked at the results yet, and it's possible that the existing templates are giving good results in some instances. The main point of interest is that switching to the module would show errors, including these. Johnuniq (talk) 03:57, 29 November 2013 (UTC)

Here is a short selection of freaky converts so I can share the pain.

From Short Empire:

  • {{Convert|2500|mi|km|=1}} → 2,500 miles (4,000 km)*
  • {{Convert/sandboxlua|2500|mi|km|=1}} → 2,500 miles (4,000 km)*

From Elk River (Minnesota):

  • {{convert|84.0|mi|km|adj=mid|=long}} → 84.0-mile (135.2 km)*
  • {{convert/sandboxlua|84.0|mi|km|adj=mid|=long}} → 84.0-mile (135.2 km)*

From SMS Breslau:

  • {{convert|10.5|cm|in|2|=abbr=on}} → 10.5 centimetres (4.13 in)*
  • {{convert/sandboxlua|10.5|cm|in|2|=abbr=on}} → 10.5 centimetres (4.13 in)*

A parameter with "=" should have form "x=y", and that sets parameter "x" to have value "y". In the above, "x" is missing, so a parameter with a name that is the empty string receives the value. After that, I'm lost. This might be a job for WOSlinker. Johnuniq (talk) 05:35, 29 November 2013 (UTC)

Hmmm. I just edited {{convert/sandboxlua2}} to remove "safesubst" (I also removed the warnings setting to make it the same as sandboxlua minus the safesubst). That seems to fix the above:
A 10,000-foot explanation might be interesting, but I guess the bottomline is that safesubst should be removed? Johnuniq (talk) 05:57, 29 November 2013 (UTC)
From a chair, elev. 5 ft: is/was it the intention to add safesubst: to the live {convert}? -DePiep (talk) 07:21, 29 November 2013 (UTC)
It was just added so that the results from some testing could be kept. If it's prodcing odd results then it needs to be removed. -- WOSlinker (talk) 07:36, 29 November 2013 (UTC)

More research

demo DP1: It also happens with parameter #3 + safesubst, (in /sandboxlua) (Elk River again; do not use parameter #4):
  • {{convert|84.0|mi|=km|adj=mid}} → 84.0-mile (135.2 km)*
  • {{convert/sandboxlua|84.0|mi|=km|adj=mid}} → 84.0-mile (135.2 km)* (note: ends up with {{km}})
But this is not likely to happen often (because the editor can see wrong result in pre/view). (no: an editor did not see this lua result back then) -DePiep (talk) 09:40, 29 November 2013 (UTC)
demo DP2: In a sense, the nonlua {convert} examples are wrong too. Parameter 4 is expected & promised to produce a "midword", like 84.0-mile MIDWORD (135.2 km), both in lua and nonlua. So the Minnesota river example is intended to read correctly like:
  • "A {{convert|84.0|mi|km|adj=mid|long}} → 84.0-mile long (135.2 km) river." The midword "long" is omitted by nonlua, probably causing a grammatically wrong sentence.
Our main problem is, of course, that such errors are not catched by our module maintenance system (page not categorized). Btw, magnificent research, Juniq. -DePiep (talk) 08:23, 29 November 2013 (UTC)
Should this be catched as an error/warning? After all, it is weird parameter usage causing unintended outcome (also in nonlua template). -DePiep (talk) 09:45, 29 November 2013 (UTC)
  • Have a safesubst version and check typical template names: Currently, the quick version, Template:Convert/q, could be used when needing a wp:subst'd result. Also, if {safesubst:} were retained in Convert/sandboxlua, then typical related template names could be checked:
Scanning for those typical template names could spot invalid "=xx" conversions to be fixed by editing the articles, even though no Convert warning category was linked for the invalid parameters. Overall, the unit-code mismatches are neglible, with only 360 in 553,500 pages, as 7-per-10,000 pages, and so other improvements are more important for the Lua version, rather than expanding the Lua script to catch "=1" or "=km". -Wikid77 (talk) 11:03, 29 November 2013 (UTC)
Non-lua templates have the same issues with safesubst and params that begin with an =, try for example {{str left|=1|5}}. An option could be to remove the safesubst for now and put it in later after everything is fixed, or it could be left out altogether as there shouldn't be any need to subst the template. -- WOSlinker (talk) 19:33, 29 November 2013 (UTC)
Numerous articles need to wp:subst conversions in the top paragraph, to allow display as a pop-up preview, but {{subst:convert/q|..}} can be used for subst'ing, as in dozens of pages, "This town is 6 miles (9.7 km) from St. Louis, MO". -Wikid77 (talk) 00:19, 1 December 2013 (UTC)
The issue is not with safesubst direct, but the default usage uses the blank parameter as a override, if you need to be able to handle the blank parameter, then change it to something else funny. →AzaToth 10:08, 30 November 2013 (UTC)
Lua can detect the empty-named parameter, which could be reported as "invalid '=km' option" in the hover, mouseover text, as long as the Convert module is not invoked with {safesubst:}. -Wikid77 00:40, 1 December 2013 (UTC)
Resolved

AzaToth fixed Template:Convert/sandboxlua, and I copied that fix to Template:Convert/sandboxlua2 and Template:Convert/sandbox. The fix means safesubst is still in the templates, so "subst:" can be used with converts—pretty rare, but it's nice. Someone would have to put "♥=long" in a convert to generate the weirdness previously seen (using "=long" is ignored, except that a warning is given if warnings are enabled). Johnuniq (talk) 05:12, 1 December 2013 (UTC)

Fixes for major subtemplates

I am installing fixes for the major subtemplates which format the first amount, check for fractions with default options, and format 2-unit results such as "ftin" or "stlb". The subtemplates are:

Singular fraction in {Convert/LoffAoffDbSoff}:

  • Expected: {{convert|1/2|mi|km}} → 1⁄2 mile (0.80 km)*
  • Currently: {{convert|1/2|mi|km}} → 1⁄2 mile (0.80 km)

Numbers with &minus prefix in Template:Convert/numdisp:

  • Expected: {{convert/numdisp |&minus;7.00}} → −7.00
  • Currently: {{convert/numdisp |&minus;7.00}} → −7.00

Some 2-unit conversions with zero 2nd unit in {Convert/LoffAonSoffAnd}:

  • Expected: {{convert|152.4|m|ftin}} → 152.4 metres (500 ft 0 in)
  • Currently: {{convert|152.4|m|ftin}} → 152.4 metres (500 ft 0 in)

An estimated 510,000 pages would be reformatted, during the weekend period. Any questions about these fixes? -Wikid77 (talk) 18:12, 30 November 2013 (UTC)

You are an amateur. -DePiep (talk) 18:16, 30 November 2013 (UTC)
Wrong again, I have 2 degrees in computer science and years of experience with configuration management, but your comments can be humorous at times. Anyway, are there any related issues to consider? -Wikid77 22:34, 30 November 2013 (UTC)
I could write you a third degree from Wikidemia in this. But not for working in cooperation or by agreements. For easy example: you go ! on your own statements within 24 h. Oh and here is today's fun ration [3]. -DePiep (talk) 18:55, 1 December 2013 (UTC)

New features tested by Convert/new

To minimize the massive impact of adding new features to the Lua version of Convert, we can use new-suffix sandbox templates:

Hence, major changes could be re-designed into /sandbox2, with separate testing by using {convert/new2}, while minor updates can be batched into the /sandbox version for the next update which will reformat all 554,000 affected pages. Those of us who have studied conversions for years are well aware how the world uses over a thousand measurement units, but Convert currently only supports a subset of those, but many use linear equations which would be easy to add to the current Lua version in Module:Convert/extra. However, the omitted units can be shocking, such as:

  • {{convert|1|USqt|UScup}} →
  • {{convert|1|AUtsp|AUtbsp}} →
  • {{convert|1|UStsp|UStbsp}} →
  • {{convert/sandboxlua |1|UStsp|UStbsp}} → 1 UStsp[convert: unknown unit]

The prior problem was to just focus on the units in use for English Wikipedia, without considering the remainder of the thousand units which the world at large is using. So, we need to support hundreds more units, with better formatting, but Template:Convert/f can provide the customized output which various users have requested. Meanwhile, we can continue to use Template:Convert/old to develop new features, and bypass problems in the Lua version, such as singular fractions:

  • {{convert/sandboxlua |1/2|ft|m}} → 1⁄2 foot (0.15 m)
  • {{convert/old |1/2|ft|m}}          →

Because the Lua version acts like any outdated subtemplate, inconsistent with the latest changes, then the complaints in Template_talk:Convert are likely to be similar for the next year as in prior months. Overall the worst problem will be the 3-day wait to reformat all 554,000 affected pages when any Lua feature is changed. -Wikid77 (talk) 06:58, 2 December 2013 (UTC)

For me, Johnuniq is the first one to devise a Lua development concept. This proposal smells of forking forks, and from a frustrated background. -DePiep (talk) 07:16, 2 December 2013 (UTC)
  • It's simple: {{Convert/sandbox}} is the one for {{Convert}}. /sandbox is the subpage name of 1st choiche always everywhere on WP (glas I can explain something to you). So after switchover, {{Convert/sandbox}} is available for its parent: the Lua development. btw, any other development pages sure should have "sandbox", maybe {{sandboxlua}} (though should not be needed). One should prevent using any convert/sandbox with ambiguous aim (markup or lua?).
You can develop markupcode templates through {{Convert/nonlua}} in {{Convert/nonlua/sandbox}}. Up to you to find something for {{Convert/old}}. -DePiep (talk) 07:47, 2 December 2013 (UTC)

Convert complexity

It looks like people are happy to try the module and let experience judge whether it is too complex, but I am posting these thoughts on convert complexity for anyone interested.

It is true that the module is very complex, and modifying the code would require serious thought and testing. However, there are several experienced programmers at Wikipedia who would be able to perform maintenance if I were to disappear. Apart from the fact that the module can be tested in its sandbox, it would be easy to copy it to test2wiki:Module:Convert for experimentation. I am hoping that the module is robust and capable of processing converts without blowing up (and indeed, the module is able to produce sensible output for all 1,672,207 converts that were in articles on 4 November 2013—total run time was 137 seconds). If any issues arise (bugs, or changes like using the singular "0.3 foot" rather than "0.3 feet" for values under 0.5), the module will be fixed. After a month, it is very likely that further changes to the module will be rare.

The only regular maintenance that should occur is to add new units, or occasionally change existing units. Both those can be done without any programming. Changing units is not something that a general editor would want to think about—some experience would be required to understand the steps involved. Nevertheless, the effort and level of skill required would be much less than needed now. A handful of editors have the skill to change the existing templates, but that is only because they have spent many hours becoming familiar with their operation.

Complex units—those that require more than scaling—need programming effort. If necessary, I will implement a procedure whereby such units can be added in an extra module for easier maintenance. I haven't done that because only two such units are used in articles (Mach and hand), although testing with the module has revealed that calibre may need to be added.

The module is used at bn:Template:Convert and simple:Template:Convert and commons:Template:Convert. Other wikis would find using the module much easier than using the templates because copying all the required templates is a daunting task. Further, there is no practical method by which changes in the templates can be propagated to other wikis, so bug fixes and enhancements are almost never applied. Other wikis end up with a mixture of old and new templates, and that causes problems. It would be best if the module were used here to ensure that it is fully tested and maintained. Then, other wikis can continue to copy articles for modification, confident that converts in those articles will work.

To give an idea of the complexity of the current templates, I have made a list of the 2898 convert templates and the 1107 convert redirects. While the current implementation is extraordinarily clever, it is simply impossible for that many templates to provide consistent results. Testing with the module has found hundreds of broken converts which display junk in articles. No amount of effort will ever succeed in cleaning up such problems entirely, and the problems were only found because the module can check units and parameters. Johnuniq (talk) 01:57, 2 December 2013 (UTC)

Good overview. How do you envision emigration to other language wikis? Of course the data files must be translated. But grammar differences will require recoding, I guess. Can the module be kept singular? -DePiep (talk) 05:04, 2 December 2013 (UTC)
Yes, units can easily be set to singular only. It's not well documented, but is briefly mentioned at Module:Convert/doc#Configuration. No doubt some other wikis would want a bunch of customizations that the code does not handle—I'll have to see what is wanted, and then decide whether the translation table can be extended to do the job. Johnuniq (talk) 06:10, 2 December 2013 (UTC)
(edit conflict)My bad, I meant to ask: can we keep a single code module (now en:module:convert), to handle all the wiki languages? Say, when a language puts adjectives in prefix, that could invite a code fork. -DePiep (talk) 07:05, 2 December 2013 (UTC)
My hope is that Module:Convert can be identical on all wikis, with Module:Convert/data (for units) and Module:Convert/text (for other text and a configuration table) being different. That has worked at the Bengali wiki where the module accepts Bangla or English numbers for input, and produces results formatted to their requirements. Johnuniq (talk) 07:53, 2 December 2013 (UTC)
  • The other-language wikipedias have various forms of Convert, such as for Vietnamese, Arabic, Spanish, and French, with some using the original "giant-switch" form which contained several large #switch functions to handle the most-common units. Updates to those other-language Converts have been difficult, not because of "complexity" but rather due to fear of changes from outside the regular editors, and some have been edit-protected to prevent all non-admin updates in their wikipedia. A major problem in Arabic Convert has been the left-to-right (LTR) and RTL switching inside ranges, while the single-unit conversions have formatted well. The scientific community has switched to metric, and so the use of Convert has been mainly in pages which describe American culture, or Australian culture or Imperial units, in other languages, such as bottling beer in pints or distances in foot/feet or mile units, particularly where American roadsigns say, "El Paso 856 miles" (1,378 km). -Wikid77 (talk) 06:58, 2 December 2013 (UTC)

Convert broken on main page

{{convert|23|ktonTNT|lk=on|abbr=off}} is displaying as "23 kilotons of TNT}} (96 terajoules)" in the lead of Operation Crossroads, which is on the main page today. Curly Turkey (gobble) 04:50, 4 December 2013 (UTC)

The problem was in Operation Crossroads (today's featured article). I did a quick workaround with this edit which replaced {{convert}} (using the current templates) with {{convert/q}} (using Module:Convert). The actual problem is demonstrated here in case anyone wants to fix it:
  • {{convert|23|ktonTNT|lk=on|abbr=off}} → 23 kilotons of TNT (96 terajoules)
  • {{convert/q|23|ktonTNT|lk=on|abbr=off}} → {{convert/q|23|ktonTNT|lk=on|abbr=off}}
The template is showing "}}" for some reason. Johnuniq (talk) 05:22, 4 December 2013 (UTC)
Is this a permanent solution? I mean, is convert/q the new convert in the wings? Will it have to be swiched back to convert eventually? Curly Turkey (gobble) 06:10, 4 December 2013 (UTC)
Nice! Strange how that was not noticed before. It's academic now, but in response to Curly Turkey, convert/q will continue to exist for the foreseeable future, but if the existing templates are switched to the module (see RfC above), the plain convert would be equivalent to convert/q, and I planned to use what links here to find all usages of convert/q and replace it with plain convert. Johnuniq (talk) 06:26, 4 December 2013 (UTC)

F/C ranges broken?

  • {{convert|300|to|310|F|C}} → 300 to 310 °F (149 to 154 °C)

Should return 148 to 154 or something in that range. Currently returns 100 to 154 C

Weird problem, only occurs for 300?

  • {{convert|150|to|310|F|C}} → 150 to 310 °F (66 to 154 °C)
  • {{convert|200|to|310|F|C}} → 200 to 310 °F (93 to 154 °C)
  • {{convert|250|to|310|F|C}} → 250 to 310 °F (121 to 154 °C)
  • {{convert|299|to|310|F|C}} → 299 to 310 °F (148 to 154 °C)
  • {{convert|300|to|310|F|C}} → 300 to 310 °F (149 to 154 °C)
  • {{convert|301|to|310|F|C}} → 301 to 310 °F (149 to 154 °C)
  • {{convert|350|to|310|F|C}} → 350 to 310 °F (177 to 154 °C)

— Preceding unsigned comment added by 212.72.34.175 (talk • contribs) 10:54, 4 December 2013

FIXED excessive rounding of hundreds: The rounding of 200, 300, 400 in temperatures is yet another problem of precision, depending on number sense of the amounts. We have talked about treating the final zero as a significant digit, but for years, complaints about the precision have been mostly ignored. To handle "300" as a rounded amount, the precision has been fixed to be -1, not -2 as in engineering measurements. This is a compromise value, and in some cases the rounding should be hand-specified as "|0" or "|-2" for whole hundreds. We need an essay to explain the default rounding to users. See comparisons to Lua Convert below. -Wikid77 (talk) 22:44/00:48, 5 December 2013 (UTC)
I formatted the examples above.
Here is a comparison with the module (the template currently shows "(100 to 154 °C)" as the output):
  • {{convert|300|to|310|F|C}} → 300 to 310 °F (149 to 154 °C)
  • {{convert/sandboxlua|300|to|310|F|C}} → 300 to 310 °F (149 to 154 °C)
The individual conversions are fine:
  • {{convert|300|F|C}} → 300 °F (149 °C)
  • {{convert|310|F|C}} → 310 °F (154 °C)
Johnuniq (talk) 11:08, 4 December 2013 (UTC)
  • Problems of precision: The following are issues of numerical precision which have existed for years:
{convert |43|-|45|lb|kg }} → 43–45 pounds (20–20 kg)
{convert/q|43|-|45|lb|kg }} → {{convert/q|43|-|45|lb|kg}} - Lua also
{convert|43|-|45|lb|kg|1}} → 43–45 pounds (19.5–20.4 kg) - better
{convert|43|-|45|lb|kg|sigfig=2}} → 43–45 pounds (20–20 kg)
{convert|200|to|210|F|C}} → 200 to 210 °F (93 to 99 °C) - converts 200 < 210 now
{convert|201|to|210|F|C}} → 201 to 210 °F (94 to 99 °C)
{convert|300|to|310|F|C}} → 300 to 310 °F (149 to 154 °C)
{convert|301|to|310|F|C}} → 301 to 310 °F (149 to 154 °C)
{convert|400|to|410|F|C}} → 400 to 410 °F (204 to 210 °C)
{convert|401|to|410|F|C}} → 401 to 410 °F (205 to 210 °C)
{convert|500|to|510|F|C}} → 500 to 510 °F (260 to 266 °C)
{convert|501|to|510|F|C}} → 501 to 510 °F (261 to 266 °C)
{convert|500|to|510|F|C|sigfig=2}} → 500 to 510 °F (260 to 270 °C)
When default precision is treated as "sigfig=2" then the results are reasonable for temperatures, but not 43-45 lb. We need to take time to seriously fix these issues and not keep ignoring them, year after year. I am thinking the solution for lb-to-kg is to have default precision as "1" below 100 pounds, then precision "0" below 1,000 pounds. However, a range should round, cleverly, considering both numbers, because range 300-301 cannot consider 300 as rounded while 301 as exact, so perhaps use highest precision of both numbers. I regret I never took time, years ago, to deduce this proper solution, which would be quick to perform. -Wikid77 (talk) 22:44/00:48, 5 December 2013 (UTC)
(moved tangent message to "#Fixing broken converts for Lua"). -Wikid77 03:52, 5 December 2013 (UTC)
  • Fixing range precisions can be done by checking both numbers: The simplest fix, for many ranges which have excessive rounding, will be to compare the numbers in the range and auto-increase the default precision for consecutive numbers, such as 300-301, or when one number has greater precision (200–200.05), so the other number could match the same extra precision. This is an extremely simple fix and will solve years of complaints about Convert's encyclopedia results being unacceptable with nonsense ranges such as "20–20 kg" for the range 43–45 pounds, and similar. -Wikid77 03:52, 5 December 2013 (UTC)

Fixing broken converts

Ten editors have supported using the module (AzaToth, Johnuniq, DePiep, WOSlinker, Mr. Stradivarius, Huntster, MSGJ, Frietjes, Sue Rangell, Imzadi 1979), and there is one opposed (Wikid77), so it is clear that the module will be used soon. I'm planning to break my pledge to DePiep by changing the modules before deployment because there is no reason to worry about the minor changes currently in the sandbox, and no reason to wait for a month after deployment before applying them. WOSlinker has fixed a large number of articles listed at User:Johnuniq/Convert problems, but there are plenty more that need attention. Time spent adjusting the current templates is unlikely to be productive as the templates will stop being used soon. Instead, the many articles with broken converts need to be fixed. Johnuniq (talk) 01:32, 5 December 2013 (UTC)

Go ahead!, it's not about the promise but about good process. Glad you did the big research. -DePiep (talk) 06:12, 5 December 2013 (UTC)
Please feel free to update Module:Convert while there are few pages which use it, before the planned system-wide roll-out, when the 554,000 affected pages will require 5 or more days before they show results of an edit to the Lua script. Also, I never agreed to a "feature freeze" to lock in current bugs, and I do not consider your prior offer to freeze the Lua version as binding because I also did not agree earlier. Always beware people barking "no-edit orders" as this has been rejected, for years, as an attempt to preempt wp:BRD by "prior restraint" and instead be leary of anyone who insists to freeze updates a priori. However, I still request that existing bugs in the Lua version be fixed before attempted deployment. Meanwhile, I will continue to enhance the Template:Convert/old to determine solutions to problems in the Lua version. The known problems, using {convert/q} for Lua results, include the following:
  • {convert/old|105|-|106|F|C}} → - decimal difference
  • {convert/q |105|-|106 |F|C }} → {{convert/q |105|-|106|F|C}}     - 2 numbers were same
  • {convert/old|1/2|ft|m}} → - singular "foot"
  • {convert/q |1/2|ft|m }} → {{convert/q |1/2|ft|m}} - "feet" or "foot"?
  • {convert/old|9|dm|disp=or|abbr=~}} →
  • {convert/q |9|dm|disp=or|abbr=~}} → {{convert/q |9|dm|disp=or|abbr=~}} - where is "(dm)"?
Again, I encourage fixes soon to the Lua version, and I regret you were held back by attempted "no-edit orders" which hindered improvements days ago. Meanwhile, the development of the "Transition Plan for Lua Convert" should continue to be written, listing the known bugs and explaining features of the markup-based Convert which will be dropped. -Wikid77 03:52, 5 December 2013 (UTC)
Ergh, a "feature freeze" [would] lock in current bugs??? -DePiep (talk) 06:45, 5 December 2013 (UTC)
{{convert/old}} is instable, because no guarantees are made. It is deviating from existing usage & documentation, breaking true convert {convert} by markup. Stable usage of markup code is through {{Convert/nonlua}}. -DePiep (talk) 06:12, 5 December 2013 (UTC)
Convert/old is "instable" because it is being improved every day, but it is not deviating far from the existing documentation. I learned years ago, before a transition, to fix as many glitches as possible in the prior system, to reduce confusion compared to the new system (which might otherwise copy bug results), and the fixes encourage a "shotgun test" of numerous features while fixing glitches, plus allow for a smoother return to the prior system when the new system is found to have unexpected problems, fixed when returning to the prior system (such as Lua has a 10-second timeout, compared to 60-second for markup processing). Also, a "feature freeze" [would] lock in current bugs because, "One person's 'bug' is another person's neat feature" and bugfixes can often expand or add new features as a result. -Wikid77 09:19, 5 December 2013 (UTC)

Um, just to clarify ... and I think DePiep and I were on the same page ... what I jokingly referred to as a "pledge" to not change the module was not any kind of don't edit suggestion. Instead, a freeze should be standard operating procedure for any software release—get it working and tested, wait to see that it's stable, then release. If there are good reasons to make a change (such as fixing a bug, or improving some feature, or implementing a new feature), make the change but then wait before release. Software which is changed three times a day up to its release invariably is full of gunk and bugs. I'm quite interested in implementing the new feature of rounding certain outputs to fractions, but this is not a good time for that kind of thing. Apart from scanning 44-GB files, I've been pondering stuff such as at Module talk:Convert#Useless digits—tedious beyond belief for any sane person but somehow appealing to me.

My "01:32, 5 December 2013" comment above was moved to this new section with the heading "Fixing broken converts for Lua". I have fixed that heading to just "Fixing broken converts" because that's what I'm talking about. Running the module over all converts in articles as at 4 November 2013 has revealed there are lots of broken converts, and they need to be fixed by editors who are familiar with how convert works.

By the way, there are 8 converts in the list of all converts with "abbr=~", and the current templates and the module display identical results for each. Handling "disp=or" as above could be added if it were needed. Re plural/singular unit names: I have no idea what is correct, but I would want to see a wide discussion on some MOS page rather than deciding here what should be done. Johnuniq (talk) 11:46, 5 December 2013 (UTC)

  • Update Lua to match auto-fixes in markup Convert: Because the markup-based Convert auto-corrects for some data, then the Lua module should be expanded to also auto-fix the data and perhaps log those pages in other categories, for partially corrected conversions. For example:
Although the Lua version causes a crisis, as a fatal error, the markup-based Convert gives correct results by auto-correcting for glitches in the data. So, perhaps the Lua version should, similarly, drop the extra decimal dots, and treat "7.9.0" as being 7.90 to give the same results, by substring of the number and then omitting extra dots. We have a similar auto-correction for commas, where "1,00,500" is treated by markup-based Convert as being 100,500. By auto-correcting the data, then the Lua Convert would have some of the same power as the original Convert, to show correct results despite some typos in data. -Wikid77 (talk) 16:24, 5 December 2013 (UTC)
This markup algorithm is too interpretive. There is no way to conclude safe whether "7.9.0" should be "79.0" or "7.90". Module should not tread into this. Such cases should should simply raise the inline tag and categorization. And a "partially corrected" convert is wrong too. -DePiep (talk) 20:08, 5 December 2013 (UTC)

Convert acceleration

Is there a way to convert acceleration? I checked the list of units and didn't see any listed. I'm looking to convert mph/s to km/s2. –Dream out loud (talk) 00:22, 4 December 2013 (UTC)

You can use "mph/s" and "km/hs". For example, {{convert|5|mph/s|km/hs|lk=on}} -> 5 miles per hour per second (8.0 km/(h⋅s)). — Huntster (t @ c) 00:36, 4 December 2013 (UTC)
Also, there is a module under development, and its list of units can be searched here. I think all of them will work in the current template. Johnuniq (talk) 00:49, 4 December 2013 (UTC)
If km/hs is not satisfactory and you need km/s2, then Template:Convert/km/s2 could be created so that you could use {{convert|5|mph/s|km/s2|lk=on}}. Jimp 09:10, 5 December 2013 (UTC)
Thanks for the reponse. I am specifically looking for km/s2, and I'm not really sure how to go about creating that template myself. If an editor more experienced with this template could help me out, I'd appreciate it. –Dream out loud (talk) 20:21, 5 December 2013 (UTC)
WOSlinker has added the unit to the module (just as I was doing the same—I've added to the testcases). Examples:
  • {{convert/q|1.23|km/s2}} → {{convert/q|1.23|km/s2}}
  • {{convert/q|1.23|km/s2|abbr=on}} → {{convert/q|1.23|km/s2|abbr=on}}
  • {{convert/q|1.23|km/s2|1|sp=us}} → {{convert/q|1.23|km/s2|1|sp=us}}
  • {{convert/q|1.23|km/s2|-1|sp=us}} → {{convert/q|1.23|km/s2|-1|sp=us}}
Later, I will change all "convert/q" (which currently uses Module:Convert) to "convert" (which will soon do the same). Johnuniq (talk) 22:10, 5 December 2013 (UTC)

convert/spell missing disp=flip

It seems that {{convert/spell}} is missing the disp=flip option to display the calculated units as primary, e.g. for River Moy:

{{convert/spell|5|mi|disp=flip|r=0}} → eight point zero kilometres (5 mi)*

Thryduulf (talk) 09:13, 6 December 2013 (UTC)

Comparing.
Markup code, not flipped:
  • {{convert/spell|5|mi|r=0}} → five miles (8.0 km)*
Lua (testcases):
  • {{convert/sandboxlua|5|mi|disp=flip|r=0|spell=in}} → eight point zero kilometres (5 mi)*
  • Not flipped: {{convert/sandboxlua|5|mi|r=0|spell=in}} → five miles (8.0 km)*
-DePiep (talk) 09:27, 6 December 2013 (UTC)
The issue does not seem present at example River Moy. If needed, one could use {{convert/q}} with module parameters (a preliminary module release for mainspace; use sparcely). -DePiep (talk) 10:06, 6 December 2013 (UTC)
The "r=0" parameter is used by convert/spell but is ignored by the module. Flipping is not very realistic when using spell because the output should be some arbitrary number that is going to be ugly when written in words. You can round the fraction to the nearest integer, but you need to know in advance that it's reasonable to ignore the fraction. I doubt if there are many cases where it would be useful in practice.
@Thryduulf: Like my comment in the previous section, a module will soon be used to replace the convert templates. Meanwhile, it is possible to use convert/q which invokes the module. I will later replace all such usage with the standard convert after it is switched to use the module. Using the module, spell can be flipped and rounded like this:
  • {{convert/q|5|mi||0|disp=flip|spell=in}} → {{convert/q|5|mi||0|disp=flip|spell=in}}
  • {{convert/q|5|mi||0|disp=flip|spell=In}} → {{convert/q|5|mi||0|disp=flip|spell=In}}
  • {{convert/q|5|mi||0|disp=flip|spell=In|abbr=off}} → {{convert/q|5|mi||0|disp=flip|spell=In|abbr=off}}
The "||" provides an empty output unit to mean "use the default". Johnuniq (talk) 10:11, 6 December 2013 (UTC)

Problems with disp=flip

The parameter disp=filp [flip] is very useful since it enables to input Imperial and US customary units exactly as they are found in English language books but to show them in SI unit first in pages which do not deal mainly with the UK or the US. Nevertheless, I have found some problems with the parameter in this template:

{{convert|16.3|hand|disp=flip|abbr=on}} Green tickY = 170 cm (16.3 h)
{{convert|16.3|hand|disp=flip|abbr=in}} Red XN = 16.3 h (170 cm)
{{convert|16.3|hand|disp=flip|abbr=out}} Red XN = 16.3 hands (170 centimetres)

In this case, abbr=in and abbr=out override disp=flip and the values are shown in hands first.

{{convert|300|to|310|F|C|disp=flip}} Red XN = Template:Convert/Dual/LoffAoffDflipSoffT

In this case the template simply does not work at all.

Could you fix them please?--Carnby (talk) 22:22, 5 December 2013 (UTC)

FIXED unit "hand" for abbr=in and abbr=out. For temperature ranges, use Convert/flip2, as in "{{convert/flip2|300|through|310|F|C}}" for: {{convert/flip2|300|through|310|F|C}}. -Wikid77 (talk) 10:23, 6 December 2013 (UTC)
A new module has been prepared and will soon be used to replace the current family of convert templates. Use "/q" as in the following to call the module:
  • {{convert/q|16.3|hand|disp=flip|abbr=on}} → {{convert/q|16.3|hand|disp=flip|abbr=on}}
  • {{convert/q|16.3|hand|disp=flip|abbr=in}} → {{convert/q|16.3|hand|disp=flip|abbr=in}}
  • {{convert/q|16.3|hand|disp=flip|abbr=out}} → {{convert/q|16.3|hand|disp=flip|abbr=out}}
  • {{convert/q|300|to|310|F|C|disp=flip}} → {{convert/q|300|to|310|F|C|disp=flip}}
When the module is live, I will change all occurrences of conver/q to plain "convert". Johnuniq (talk) 22:54, 5 December 2013 (UTC)
Thank you very much!--Carnby (talk) 08:35, 6 December 2013 (UTC)

Singular fractions: module

While adding to Help:Convert (to document module usage) I started wondering (again!) about the rules for when a unit should be singular. There is a bunch of code in the module to mimic the many idiosyncracies of the templates, and I have lots of tests captured months ago from Special:ExpandTemplates that show the module had good consistency with the templates.

However, a change in the templates (recent, I think) means fractions now work differently. Consider:

  • {{convert|0.5|yd|m|abbr=off}} → 0.5 yards (0.46 metres)
  • {{convert/spell|1/2|yd|m|abbr=off}} → one-half yard (0.46 metres)
  • {{convert|1/2|yd|m|abbr=off}} → 1⁄2 yard (0.46 metres)

The first and second results above produce, respectively, plural "yards" and singular "yard", and that is the way it has been for a long time. The third result used to show the plural (consistent with 0.5), but now it shows the singular.

I have changed (diff) Module:Convert/sandbox so it regards fractions under 1 as singular. The following illustrates (convert/sandboxlua invokes Module:Convert, while convert/sandbox invokes Module:Convert/sandbox):

  • {{convert/sandboxlua|0.5|yd|m|abbr=off}} → 0.5 yards (0.46 metres)
  • {{convert/sandboxlua|1/2|yd|m|abbr=off|spell=in}} → one-half yard (0.46 metres)
  • {{convert/sandboxlua|1/2|yd|m|abbr=off}} → 1⁄2 yard (0.46 metres) [plural "yards"]
  • {{convert/sandbox|0.5|yd|m|abbr=off}} → 0.5 yards (0.46 metres)
  • {{convert/sandbox|1/2|yd|m|abbr=off|spell=in}} → one-half yard (0.46 metres)
  • {{convert/sandbox|1/2|yd|m|abbr=off}} → 1⁄2 yard (0.46 metres) [singular "yard"]

I think I prefer the singular unit when using a fraction with magnitude 1 or less. Any thoughts? Should anything else be tweaked? If nothing arises, I will incorporate this change in the module. Johnuniq (talk) 09:27, 7 December 2013 (UTC)

Ooops. After saving this (with title "Singular fractions") I was taken to #Singular fractions above. I must have seen that at the time, but had forgotten. I guess that answers my question about when this change occurred. Johnuniq (talk) 09:31, 7 December 2013 (UTC)
Fractions in words should have hyphens, such as "one-half" or "three-fourths" (not "three fourths"), which was discussed enough to even be documented in wp:MOSNUM#Fractions. Excellent work, as it took over 3 years to get singular fractions in the markup-based Convert. -Wikid77 (talk) 14:09, 7 December 2013 (UTC)
Thanks, I believe I have fixed Module:ConvertNumeric (used by Module:Convert for spelling) so fractions are hyphenated. Johnuniq (talk) 10:07, 8 December 2013 (UTC)

Module switchover timetable

The above RfC shows ten editors who support using the module (AzaToth, Johnuniq, DePiep, WOSlinker, Mr. Stradivarius, Huntster, MSGJ, Frietjes, Sue Rangell, Imzadi 1979), and one opposed (Wikid77). As the RfC started on 19 November, following the 30-day convention would mean waiting until 19 December. Given the current numbers, it would seem reasonable to close the RfC early so editors will have an opportunity to respond to issues arising in advance of the Christmas period. Any thoughts? Johnuniq (talk) 10:21, 9 December 2013 (UTC)

Yes, it seems like we have a clear consensus, and I can't see much point in waiting another 10 days. Do you want me to make the switch? — Mr. Stradivarius ♪ talk ♪ 10:28, 9 December 2013 (UTC)
Wednesday would suit me. Johnuniq (talk) 11:08, 9 December 2013 (UTC)
Ok, Wednesday it is. Putting the relevant code in the sandbox and making a protected edit request should do the trick. — Mr. Stradivarius ♪ talk ♪ 12:26, 9 December 2013 (UTC)
  • An alternative proposal, for hyrid release, has been made: See above, how another proposal was logged on 8 December 2013, during the 30-day period, based on new evidence how the Lua Module:Convert is likely to trigger a 2-week reformatting period for any feature change, unless re-designed:
I will announce the alternative proposal at wp:PUMPTECH, and I have yet to read the transition plan which lists the non-supported features of the present markup-based Convert. -Wikid77 (talk) 11:52, 9 December 2013 (UTC)
Basically, Wikid77, the non-supported features are exactly those you added recently. Could you provide a list? There is also this one (covered by the process), and the already described warnings category. -DePiep (talk) 13:08, 9 December 2013 (UTC)
Johnuniq, will you declare a temporal block on editing module:convert/extra ? Otherwise it may add errors, confusingly at least. -DePiep (talk) 20:47, 9 December 2013 (UTC)
I'm happy for people to edit Module:Convert/extra as it will affect only a small number of pages (those that use a unit not known to the module), and I don't think any real damage can be done, apart from making units already in extra disappear. I would recommend that anyone wanting to add a unit for the first time try the sandbox first because you can muck around there and try things without any problem—anyone wanting more info can find some by searching for "sandbox" in the docs at Module:Convert. The most reliable technique would be to use makeunits to generate the output—that's moderately easy but would be a bit bewildering the first time. I might document that more clearly at some later time. I would recommend not adding units unless they are really needed in articles as more stuff generates more confusion. Johnuniq (talk) 03:32, 10 December 2013 (UTC)
Let's just do it. --Sue Rangell ✍ ✉ 22:10, 9 December 2013 (UTC)

Support for cost-per-mass

Refactored for {convert/old}. -Wikid77 06:43, 11 December 2013 (UTC)

The following unit-codes handle cost-per-mass conversions: $/kg, $/g, $/lb, $/ozt, and $/oz. Examples:

  • {convert/old|337.00|$/ozt|$/g}} –
  • {convert/old|454.00|$/lb |$/g }} –
  • {convert/old|279.00|$/ozt|$/kg}} –
  • {convert/old|16.35|$/oz|$/lb}}    –

The original request included currency, set here as parameter 7:

  • {convert/old|337.00|$/ozt|$/g|7=A$}}    –
  • {convert/old|454.00|$/lb |$/g|7=CA$}}    –
  • {convert/old|279.00|$/ozt|$/kg|7=CA$}} –
  • {convert/old|16.35|$/oz|$/lb|7=US$}}    –

However, a linked currency symbol will appear double-linked. The Lua version has/had lacked $/g or $/oz (28 grams) among the following:

  • {convert/q | 10.83|$/g|$/ozt}}   – {{convert/q| 10.83|$/g|$/ozt}}
  • {convert/q |279.00|$/ozt|$/kg}} – {{convert/q|279.00|$/ozt|$/kg}}
  • {convert/q |16.35|$/oz|$/lb}}    – {{convert/q|16.35|$/oz|$/lb}}

Option "disp=preunit" can be used, but the spacing is omitted:

  • {convert/q|279.00|$/ozt|$/kg|disp=preunit|CA}} – {{convert/q|279.00|$/ozt|$/kg|disp=preunit|CA}}
  • {convert/q|45|acres|ha|disp=preunit|wooded}} – {{convert/q |45|acres|ha|disp=preunit|wooded}}
  • {convert |45 |acres|ha|disp=preunit|wooded}} –

The intended spacing for "disp=preunit" should insert a space, unless the 4th parameter ends with "-" or has coded markup which begins with "&" or tag token "<" as with a style span-tag. -Wikid77 (talk) 12:29, 9 December 2013 (UTC)

Didn't take long to add $/g and $/oz to Module:Convert/extra -- WOSlinker (talk) 13:37, 9 December 2013 (UTC)
Thank you, WOSlinker; those were requested in 2010. -Wikid77 14:43, 9 December 2013 (UTC)
Aren't we supposed to work through module:Convert/extra/sandbox? Needs some direction from Johnuniq I guess. -DePiep (talk) 17:34, 9 December 2013 (UTC)
I don't think there's time to fiddle with a /sandbox, but try to update documentation, as Mr._Stradivarius has mentioned forcing the Lua version live within 29 hours. To use a sandbox, re-copy from the live version, and then update that as sandbox. This is like son of VisualEditor, to release a product with known bugs systemwide without an advance notice. -Wikid77 19:40, 9 December 2013 (UTC)

Fixed ranges for nonsense results

Refactored for {convert/old}. -Wikid77 07:59, 11 December 2013 (UTC)

I have installed the new rounding algorithm, in {{Convert/Dual/rnd}}, to reset the default precision for ranges of close values to show logical results. Previously, for years people had complained how 2 different amounts would convert to the same result, or inverted. For example:

  • Formerly:   {{convert/old|43|-|45|lb|kg}} →
  • Currently: {{convert/old|43|-|45|lb|kg}} →

Even worse than rounding to the same amount (20–20 kg) were the cases when higher amounts became lower, and then some people were downright hostile, such as when increasing by "0.4 pounds" and getting a much lower result:

  • Formerly: {{convert/old|5000|–|5000.4|lb|kg}} → 5,000–5,000.4 pounds (2,300–2,268.1 kg)
  • Currently: {{convert/old|5000|–|5000.4|lb|kg}} →
  • Lua form: {{convert/q |5000|–|5000.4|lb|kg }} → {{convert/q |5000|–|5000.4|lb|kg}}

So, when increasing by 0.4 pounds, the result had dropped 32 kilograms(!) lower, and some people were hopping mad, as how could an "encyclopedia" dare show such nonsensical results to intelligent people?!? I think we were all considered stupid "imbeciles". Well the problem was related to the concept termed number sense, where numbers are interpreted differently in different contexts, such as the range "5,000–5,000.4" implying the first number is actually "5,000.0" rather than rounded to the nearest thousand. Anyway, the new rounding algorithm works, within a hundredth second, by simply resetting the default precision to the highest of both amounts, or increases precision by 1 level for close amounts in the range. That rounding tactic avoids a higher amount showing a lower result, and more people getting severely angry about this so-called encyclopedia. -Wikid77 (talk) 18:56, 7 December 2013 (UTC)

Nice analysis & improvement. Pity you had to spoil it yourself by lamenting that a bug you didn't spend time on for five years must have been wrecking The Encyclopedia all that time. Makes me wondering what held you back.
Oh, and just in case you did not know: last ten months we are working with the sandbox version of the module, this way:
  • Lua form: {{convert/sandboxlua |5000|–|5000.4|lb|kg }} → 5,000–5,000.4 pounds (2,268.0–2,268.1 kg)
-DePiep (talk) 12:10, 8 December 2013 (UTC)
  • Fix for range precision delayed by other problems: There have been many other problems, during the past 5 years, which distracted from fixes to the rounding of ranges, such as adding option "disp=flip" and new Template:Convert/flip3, as with:
  • {{convert/flip3 |3.5|down to|3.0|by|2.0|m|ftin|abbr=on }} → {{convert/flip3|3.5|down to|3.0|by| 2.0|m|ftin|abbr=on}}
  • {{convert/sandboxlua |3.5|down to|3.0|by|2.0|m|ftin|abbr=on|disp=flip}} → 3.5 down to[convert: unknown unit]
Plus, there were the fixes to install Lua Module:Citation/CS1 to handle 178 different {{cite_web}} parameters to reformat major articles and 2.2 million pages as 2x-3x faster in March/April 2013. However, the growing abusive language about excessive rounding finally tipped the scales to address the bizarre rounding of higher amounts as showing lower results, such as the quite hostile remark of 30 April 2013:
"And we're not using any of those damn converters. They always round off figures, as I already pointed out. I honestly can't understand how any of this is even a debate. Some idiot wants to round everything off simply because he's an idiot and I have to deal with it? Morons. All of you. Worthless morons." posted by SHFW70 (talk) at 15:26, 30 April 2013 (UTC)" [see: archive]
Eventually, it became too difficult to ignore the rounding-precision problems as noted by the various upset users, although I thought of being called "imbeciles" rather than the phrase, "All of you, Worthless morons". I guess I was trying to downplay the true level of vicious hostilities in my message above. Anyway, the important point is to remember the range-precision rounding is fixed now, and hopefully less hostile vitriol in the future. -Wikid77 16:51, 8 December 2013 (UTC)

Template:Convert/calibre

Refactored for {convert/old}. -Wikid77 15:34, 11 December 2013 (UTC)

We have had {convert/calibre} for over 4 years (since October 2009‎), but it was not being used, and I expanded it for more options. People have been using "cal" and getting Template:Convert/cal for calories. Instead:

Compare with mm-to-inches:

Hence, {convert/calibre} uses a table-lookup function to get the result. Perhaps the Lua handling of Mach number is a similar problem, but all these issues are just too much at this time of the year, and we need to slow down to write some plans for how to handle non-standard, complex, table-lookup units. -Wikid77 (talk) 17:49, 1 December 2013 (UTC)

Collecting them for future con-templation in Category:Subtemplates of Template Convert/non-scalable units -DePiep (talk) 07:59, 2 December 2013 (UTC)

Needs a bit more work on some of the options. -- WOSlinker (talk) 14:00, 2 December 2013 (UTC)

FIXED. It was mainly the old MediaWiki bug where an empty parameter {{{2}}} will not accept the default value "{{{2|calibre}}}" when passed beyond 1 level deep. Thanks for taking time to test those options during this nightmare period of "Let's switch 1.6 million conversions to use Lua" etc. Perhaps we should also quietly switch the "[edit]" option to run the VisualEditor; oh wait, that was already tried and found to be somewhat unwise. -Wikid77 (talk) 01:13, 3 December 2013 (UTC)

Convert problems

I have updated my list of problems that will arise when the module goes live at User:Johnuniq/Convert problems. It currently has three sections: unsupported features, unknown units, and unit mismatches. Each includes a link to the article where the problem was present on 4 November 2013 (it might have been fixed since then). I intend ignoring the unsupported features for now—replace the templates that don't work with equivalent wikitext without a convert. I'll add the unknown units to "extra" in due course, if someone doesn't beat me to it.

The unit mismatches will require some deliberation—it's easy to guess what was intended in many cases, but they should be fixed slowly to avoid hiding something that is entirely broken (perhaps the values are not right, or perhaps the problem was due to vandalism). Anyone with a bit of time might like to start work fixing the 360 articles! Johnuniq (talk) 05:27, 1 December 2013 (UTC)

  • Data shows error messages do not fix conversions: Thanks for listing the details of all those cases. If anyone imagines that showing a glaring error message would cause people to fix invalid conversions, then there are several examples in page "User:Johnuniq/Convert problems" where invalid mismatch of "lb" with "km" went unfixed for over 2.5 months despite the bolded message:
ERROR Convert/lb: Invalid unit parameter 3: "km" - expected mass unit such as "kg" with 88,594 pounds ([convert: unknown unit]).
Instead, unit mismatches should be auto-corrected where results are obvious, and show superscript "[fix unit]" as in 10% of the cases, where "sqft" was used with a length unit "m" or volume "m3" or similar. Several cases used {convert|mm|cal} for calibre, where "cal" is the unit-code for calorie. More later. -Wikid77 (talk) 15:28, 1 December 2013 (UTC)
Cannot reproduce the error message (hardcoded here). -DePiep (talk) 03:55, 2 December 2013 (UTC)
It's not always the output unit that is wrong. For example Baipu Middle school. Yes, editors won't always notice the warning and fix it, however it's good to show for anyone reading it so that they can see there is a problem rather than seeing some odd figures instead. There's also going to be an error category so it's a lot easier for editors that like fixing things to find them. -- WOSlinker (talk) 15:45, 1 December 2013 (UTC)
  • We had that warning category in use, but the mismatched unit-codes have persisted, so I am planning to auto-correct the major units so there will be fewer worries. The invalid input unit could strike the output, as follows:
Perhaps 80% of mismatches could be auto-corrected, as with "55|acres|m" using m2. -Wikid77 (talk) 17:49/18:13, 1 December 2013 (UTC)
re Wikid77: ... went unfixed for over 2.5 months? The page was two.five days old when you wrote that. Also it is in userspace, which in itself I do not treat as a publication unless the user says it is - like Johnuniq did here. Otherwise it might be a sandbox or version mixup.
A warning category in use - they still are. But only it lists pages from mainspace and template space, for good reasons (they were mentioned quite a few times here, strange you missed that module feature). You are speculating that editors do not edit convert-tags. Citation/CS1 has those tag-categories too and got rid of 50k-100k messages. It was fun editing I remember, nothing beats a good error message!
Finally, I don't think the module should "auto-correct" units (eg, changing the second unit "m" into "m2" when the first has type=area). It hides errors that are in the first unit, eg from when the editor thinks "dunam" is a length. Better have all these checked by editor's eyes -- easily through the maintenance category. DePiep (talk) 03:55, 2 December 2013 (UTC)
Errors in the first unit should be auto-corrected as well, where the 2nd unit is already correct. For Convert, a call to use units "kt|mph km/h" could auto-correct the "kt" kilotonnes unit, to become "kn" knots to agree with speed units "mph km/h". See below: "#Auto-correction fixes conversions in archive pages". -Wikid77 05:43, 3 December 2013 (UTC)

Auto-correction fixes conversions in archive pages

Refactored for {convert/old}. -Wikid77 15:41, 11 December 2013 (UTC)

The problem of invalid parameters in archived talk-pages was discussed months ago, where the auto-correction would allow an archive page to show reasonable amounts even though not be re-edited (the archived revision would be closed). Meanwhile, Convert has had unit-mismatch messages for over 4 years, and we found them to be a minor issue. However, the page "Leroy W. Stutz" is a recent example, edited to have invalid "{{convert|68|lb|km}}" on 13 September 2013, which was caught by Template:Convert/lb when updated on 21 September 2013, to show:

  • {{convert/old|68|lb|km}} = ERROR Convert/lb: Invalid unit parameter 3: "km" - expected mass unit such as "kg" with {{convert|68|lb|...}}.

Then for almost 2.5 months after mid-September, no one corrected page "Leroy W. Stutz" to fix 'km' as 'kg' despite the large glaring error message. Instead, {Convert/lb} could auto-correct the 'km' to be 'kg' as follows:

  • {{convert/old|68|lb |km}} =

As for errors detected by Lua Module:Citation/CS1, when I wrote that Lua script, I added logic to auto-correct page parameters, so plural "pages=6" would instead show singular "p. 6" not "pp. 6" despite using wrong option "pages=" rather than "page=6". Similarly, the 50,000 error messages could have been omitted, and instead auto-correcting the parameters, to show the exact same data as if hand-edited, but with a superscript note "[fix cite]". The tactic of showing verbose error messages, with a tracking category, will just clutter a page with messages and busywork which could be auto-corrected by better templates. Instead, we now have Template:Convert/acres which auto-corrects for unit-mismatch, even inside a closed archive page. Perhaps 10 auto-correcting units would clear 90% of all unit-mismatch cases, with no hand-editing of pages needed. This ain't computer chess, but rather a series of much simpler decisions based on the likely use of units in combination. -Wikid77 (talk) 05:43, 3 December 2013 (UTC)

Look for invalid units and refactor for Convert/old

Look at various suspect pages, to see if they are showing "invalid unit" or "unit mismatch". Also, I have been updating the prior threads on this talk-page to use {convert/old}, where the results have been nonsense with the Lua version running as {convert}. -Wikid77 07:19, 11 December 2013 (UTC)

Thanks. Soon we might manually archive pretty well all this page so it is a bit cleaner if people arrive wanting to discuss any problems arising from the change. Johnuniq (talk) 11:08, 11 December 2013 (UTC)
  • Many articles in unit-categories show old revision: I have fixed 20 pages for unit-mismatch, but many of the formatted pages did not show the "[Convert: invalid unit]" note until edit-preview. The speed of the "Category:Convert invalid units" seems to update much, much faster than reformatting the cache versions of the pages, giving the illusion of markup-based {convert} formatting pages with Lua-based unit categories. Hence, pages can be fixed before readers see the Lua-message version of those pages. -Wikid77 (talk) 17:42, 11 December 2013 (UTC)
    • Yes, I noticed that. I append "?action=purge" to the URL and press Enter to make the servers refresh the displayed page. For example: https://en.wikipedia.org/wiki/Polen_Special?action=purge Johnuniq (talk) 19:37, 11 December 2013 (UTC)

New units

I added two units to Module:Convert/extra:

The "lb(f)" was for Hawker Siddeley Harrier; I suspect there will be others. An example of the resulting text is "having 15,000 pounds (67 kN) of thrust". I had been thinking we should make people use the correct unit, but I have to concede that "having 15,000 pounds-force (67 kN) of thrust" reads poorly. Johnuniq (talk) 11:08, 11 December 2013 (UTC)

the grains of water units were created for template:infobox firearm cartridge. I agree it's a somewhat fuzzy unit (see Template_talk:Infobox firearm cartridge#volumetric grain and grain (unit)). Frietjes (talk) 00:49, 12 December 2013 (UTC)
with regard to the torque, still some problems with torque units, some work, but some don't
1 kilogram force-metre (9.8 N⋅m)
1 newton-metre (0.74 ft⋅lbf)
1 foot-pound force ([convert: unit mismatch])
1 kilogram force-metre ([convert: unit mismatch])
1 kilogram force-metre (7.2 lbf⋅ft)
1 kilogram force-metre ([convert: unit mismatch])
unless I am missing something, aren't these all torque? Frietjes (talk) 00:46, 12 December 2013 (UTC)
My response is long, so I made a new section at #Converting between energy and torque. Johnuniq (talk) 09:26, 12 December 2013 (UTC)

Two nuts to crack

Must say, already it is a wonderful template to work with for new things! -DePiep (talk) 00:02, 12 December 2013 (UTC)

I started wondering about the first problem, but I'll have to leave that for another time. The second point is not our problem—it's just garbage input to the aircraft specs template, giving garbage output. At EFW N-20#Specifications (N-20.1 Glider), the article was showing:
Empty weight: −-29,800,000 kg (−397 lb)
That is the output from convert/old (the displayed page had not been updated). Appending "?action=purge" to the URL used the module to render the page, and that changed the above line to:
Empty weight: [Convert: Invalid number]
The old template treats its first parameter as a number, but the template syntax breaks in weird ways when broken input is provided, as shown here:
  • {{convert/old|1400-1580|kg|lb|0|abbr=on}} →
  • {{convert/old|-180|kg|lb|0|abbr=on}} →
I did a quick scan of some of the 44GB dump of all articles and about 10% 1% of the inputs are junk, so we can expect many more articles to pop up in the error categories. One "fix" to remove the issue from our responsibility would be to use some tool like AWB to insert an HTML comment around the bad text. Johnuniq (talk) 10:46, 12 December 2013 (UTC)
That would be actual editing to hide an error. Whether it was caused by lua-ification or it was already nonsense before: they are found & listed to be solved, not to be commented out. Parameter definition has changed. -DePiep (talk) 13:21, 12 December 2013 (UTC)
I wasn't thinking well when I wrote the above—it's 1% of inputs that are junk, and you were saying that something has to be done so "1400-1580" can be redone as a range. Other examples of bad input are "ca. 230" and "approx: 235 kg ; approx version C with carbon fibre: less than 230". Those problems will need serious attention from the relevant wikiproject, and might take a long time to fix. As you say, hiding the problem is not desirable; another procedure would be to move the invalid text to the "|empty weight note=" field, although there has to be a valid number in an "|empty weight" field in order for the note to be displayed. Or, perhaps {{Aircraft specs}} could be changed to test its argument—if a number, pass to convert; otherwise, display as text and add a tracking category. Johnuniq (talk) 21:21, 12 December 2013 (UTC)

{cvt} deprecated

I deprecated this one. It had ~80 pages with transc's in mainspace. Now replaced by its job: {convert|abbr=on}}. Some 12 are left in archives.

In the future, we could re-introduce a preset-variant (indeed {cvt|abbr=on} looks like a very convenient one, though it was little used while |abbr=on is set very often). Of course it should have full relevant module functionality available (this old {cvt} markup only passed through a few parameters & options). But before doing that, we better rethink the whole reduced-function suite as a concept. -DePiep (talk) 09:47, 13 December 2013 (UTC)

Converting between energy and torque

The rule is that force-distance (lbft or kgf.m) is torque, and distance-force (ftlbf) is energy. See WP:MOSNUM#Unit names and the discussion, and see Pound-foot (torque) and Foot-pound (energy).

Three months ago my testing showed that the above rule was disregarded by a lot of gun-related articles, so I added a table of exceptions that allow conversion between units of different types. However, when converting between units of different type, each unit must be whitelisted to allow the conversion, in order to avoid nonsensical converts. There were very few such exceptions, and I was a bit tired, so the exception table is built into Module:Convert/makeunits. When that module creates Module:Convert/data, its specials table is used to add an "alttype" (alternate type) field to the whitelisted units.

The following energy units have alttype = "torque" (the first line consists of different units, while the second line consists of aliases for units in the first line):

  • ftlb, ftlb-f, ftlbf, inlb, inlb-f, inlbf, inoz-f, inozf
  • ft.lbf, ft·lb-f, ft·lbf, in.lb-f, in.lbf, in.oz-f, in.ozf, in·lb-f, in·lbf, in·oz-f, in·ozf

The following torque units have alttype = "energy":

  • Nm
  • N.m, N·m

That means the following conversion works despite the fact that Nm is torque and ftlbf is energy:

  • {{convert|1|Nm|ftlbf}} → 1 newton-metre (0.74 ft⋅lbf)

The following conversion fails because kgf.m is torque (and kgf.m is not whitelisted), and ftlbf is energy.

We need to answer these questions:

  • How many converts fail because of torque/energy mismatch?
  • Is there a relatively easy way to fix the problem so the rule at the top is followed?
  • Or, do reliable sources use conventions that break the rule, so we should too?
  • What units need to be whitelisted to allow the rule to be broken?

An easy alternative would be to give up and redefine all torque units as "energy"—then unit mismatches would not be possible, and nonsense like converting between BTU (energy) and Nm (torque) would work.

Adding exceptions, or redefining all torque units, would require a change to Convert/data—something which should avoided, and which would best be done on a weekly or monthly schedule.

A workaround may be possible: Add a new unit to Module:Convert/extra, perhaps called "ftlbf(t)" and define that unit as torque unit. Then, wherever kgf.m is converted to ftlbf, change the latter to ftlbf(t). We need to work out how hard that would be, and how desirable would be the result. Thoughts? Johnuniq (talk) 09:25, 12 December 2013 (UTC)

keeping units most commonly used for torque and energy separate is fine with me. converting between the two is not entirely nonsense, since J = N m, but usually not what is desired. so we should leave it as it is. Frietjes (talk) 20:36, 13 December 2013 (UTC)

Taking the hands out of the fire

Wikid77 pointed to the unit hand:

  • {{Convert|88|cm|hand|2}} → 88 centimetres (8.2+1⁄2 hands)
  • {Convert/sandboxlua|88|cm|hand|2}} → 88 centimetres (8.2+1⁄2 hands) (bad)

There is also {{hands}}, interesting too for the hands peculiarities (see also recent archives of this talkpage):

  • {Hands|14.2}} → 14.2 hands (58 inches, 147 cm)

Hands were added recently to the {convert} repertoire. At the moment the module does not present the hands well enough. Also, we know that the module will not be adjusted for such individual issues before being rolled out (dixit Johnuniq).
To prevent bad hands showing, I propose to make {{Convert/hands}} into a stand-alone wrapper in all articles, right now (while WLH works for this). So articles are to use {{Convert/hands}} directly, or {Hands}. Then, after the module is alive and stable, there is time to look at hands-presentation without pressure.
Notes: when the module is live, an editor can use the unit "hands" legally, introducing a less OK result. We can not track such pages. Incorporation of correct hands in the module should solve this (otherwise, the bad format will stay in pages - unless we pull the unit out of the module completely). Second: this bridge solution does not imply that hands will stay out of the module definitively. Same for the other standalone template {{Hands}}. We do not need to conclude on this at this moment. -DePiep (talk) 18:00, 29 November 2013 (UTC)

  • Use Convert/old for range of fractional hands: I agree the problems with fractions, in horse hands, are a low priority for the Lua module, and we could fix {convert/old} to handle those rare ranges of cm:
  • {{convert/old |88|cm|hand|2}}         → {{convert/old |88|cm|hand|2}}
  • {{convert/old |88|-|98|cm|hand|2}}           → {{convert/old |88|-|98|cm|hand|2}}
  • {{convert/sandboxlua |88|-|98|cm|hand|2}} → {{convert/sandboxlua |88|-|98|cm|hand|2}}
We need to spend more time on formatting "#Singular fractions" for all units, and writing Lua documentation so other people know where fractions are formatted within Module:Convert. -Wikid77 (talk) 21:14, 29 November 2013 (UTC)
Fine using a generic wrapper. Except that it should be {{convert/nonlua}}. Convert/old already has diverged from current markup template code (the {Convert} itself), and is not secure against future changes (eg, breaking the input settings). -DePiep (talk) 04:56, 30 November 2013 (UTC)
Adding: the name "/old" may be misleading, suggesting that it uses and produces result as from before a Lua module introduction. In fact, the {convert} family will develop and future usage will show the future then version of a result. -DePiep (talk) 05:05, 30 November 2013 (UTC)

Random section break for new discussion

I'm sure that (a) you have more urgent things to think about at the moment and (b) you know this already, but 9.26 h is not a meaningful or possible result. Just as a reminder: in hands, the figures after the "decimal" point are in radix 4; there can be no more than two of them; the first is written in figures, and can take the values 0 (or [blank]), 1, 2 or 3 (these are inches); the second is written as a fraction and can take the values [blank], 1/4, 1/2 or 3/4 (these are fractions of an inch). The fractions are not often encountered, and should not be shown by default. Thanks for all that you people do. Justlettersandnumbers (talk) 16:19, 13 December 2013 (UTC)
Giving the wrong numbers (without warning) is very important!
Just to use the right (current) versions:
  • {{convert/nonlua|88|-|98|cm|hand|2}}           → {{convert/nonlua |88|-|98|cm|hand|2}}
  • {{convert |88|-|98|cm|hand|2}} → 88–98 centimetres (8.2+1⁄2–9.2+1⁄2 hands)
  • We would never ever ever need or use this, per JLANs comments below; don't even give someone that option! --Montanabw
The problem comes from the rounding, set by last parameter, |2 in both tests. Without:
  • {{convert/nonlua|88|-|98|cm|hand}}           → {{convert/nonlua |88|-|98|cm|hand}}
  • People like me who don't get the syntax nuances will not use or remember whatever that is --Montanabw
  • {{convert |88|-|98|cm|hand}} → 88–98 centimetres (8.3–9.3 hands)
  • This is what we will use, though we want {{convert|77|cm|hand in}} creating 77 centimetres (7.2 hands; 30 in) or something like it to work for the range also and the individual measurement, right now we get {{convert/2|137|–|162|cm|hand in}} looking like {{convert/2|137|–|162|cm|hand in}} (kind of gibberish) when we want it to look like: 137 – 162 centimetres (13.2 hands; 54 inches – 16 hands; 64 inches) ---Montanabw
Conclusion: because this is not warned, this is serious. -DePiep (talk) 16:39, 13 December 2013 (UTC)
And: since this is in pre-lua too, few such errors will actually exist (because they would have been notices before). -DePiep (talk) 16:52, 13 December 2013 (UTC)
I am happy to enhance the module to do what is needed, but I need a specification, and I would want to see at least two editors who understand the topic (say Justlettersandnumbers and Montanabw) agree, and a suitable wikiproject should be notified in case anyone else wants to comment. A recent discussion is in the October archive, and that should be studied to see that nothing is forgotten.
Hands for output: Justlettersandnumbers made a helpful statement above, but please don't be squeamish about saying what you want: the first inch digit could be "0 (or [blank])"—which of those is actually wanted? Say the result is 36.49 inches: is that 9 or 9.0 hands? Should it be 9 if no precision is specified, but 9.0 if the precision is 1 ("|1")?
Say the result is 38.49 inches. Is that 9.2 hands if the precision is not given or is 1? Is it 9.2½ if the precision is 2 or more? I suppose 36.49 inches with precision 2 would be 9½ hands (not 9.0½).
  • We would not be able to measure a horse with precision to hundredths of an inch. I have never seen a measurement refined to less than a quarter-inch. I'd round centimeters to inches, and then round to the nearest quarter inch to do the hands conversion which is based on inches. I do like the idea of 9 hands as the default if no further precision is specified and 9.0 for cases where we'd have 9.0-1/2 hands. --Montanabw
Say the result is 38.5 inches. Is that 9.3 hands if the precision is not given or is 1? Or is it 9.2 hands? It would be 9.2½ if the precision is 2 or more? What about 38.9 inches?
  • 38.5 inches would be 9.2-1/2 hands. Always. If you want to round, you ignore the fraction and go 9.3 hands, (because most people want their horses to be bigger, unless you live in the world of pony measurement politics) but if someone cares that much to note the fraction, we keep the fraction. (See, e.g. Theodore O'Connor, a famous pony who was baaaaaarely under 14.2 - his people cared.) --Montanabw
What should occur if a negative precision is used? Ignore it (treat as if no precision specified)? Should a warning be given (if warnings are enabled in the template—currently they are off to reduce noise)?
Hands for input: What happens if 9.12 hands is entered? How about 9.19? I would be happy to give a warning with no output (the result would show something like "9.12 hands [warning...]"), but what is wanted?
That should never happen. Due to the problems with the radix point system, horse people use fractions where you are between inches. We'd never have, say, 14.2.25 or something like that, it would be 14.2-1/2. Also, horse measurement cannot be any more precise; I can measure the same horse on different days and get results a half inch apart, their hooves grow ... --Montanabw
Perhaps a spec should go in a sandbox somewhere so it can be edited—I would like just one statement without having to extract the key points from a protracted discussion. Johnuniq (talk) 01:46, 14 December 2013 (UTC)
Yes, more input from users of the template would be good. Meanwhile:
  • Whether 15 hands is written as 15 h or as 15.0 h is, as with with any other unit, a question of precision. I tentatively suggest three possible precision options:
- default, precision not specified: decimal point and following zero not displayed, decimal point and any other figure always displayed, thus 15 h, 15.1 h, 15.2 h, 15.3 h, 16 h etc.
- precision=1: zero also displayed, thus 15.0 h, 15.1 h etc
- precision=2: fractions of an inch displayed, thus 15.0 h, 15.0¼ h, 15.0½ h, 15.0¾ h, 15.1 h
  • Please note that 36.5 inches converts to 9.0½ h, and that 9½ hands means 38 inches and would be written 9.2 h.
  • It might be simplest if hand heights with fractions (and there possibly won't be very many of them) could be entered in base 4 to 2 places; e.g., entering ...convert|15.03|hands... would output 15.0¾ h (154.3 cm); but that's something for those more likely to use this option to comment on. Justlettersandnumbers (talk) 12:45, 14 December 2013 (UTC)
I disfavor the "15.03" situation. It would be more complicated, actually. We already have {{hands|15.1 + 1/2}} becomes 15.1 1⁄2 hands (61.5 inches, 156 cm)

OK, I THINK that JLAN and I do agree on the formatting of output (other than the minor point above?). I am not at all an expert on markup syntax, though, I'm just all for whatever gets us there. Here is my take:

  1. the existing {{hands}} works great for what it does, and there is no real need to change that template; it takes hands measurements and converts them into both inches and centimeters. It will cover the vast majority of horse articles. THIS AIN'T BROKE, SO DON'T FIX IT!  ;-)
  2. We need to express a range as well as a single measurement, i.e. 14 to 15 hands (56 to 60 inches, 142 to 152 cm) is expressed by {{hands|14|to|15}}
  3. However, there are situations where some editors want to use a reverse conversion from cm to hands, which I think is because some horse breed registries in places like continental Europe do all their official measurements in centimeters. WPEQ seem to have reached a default consensus leaving it up to individual editors to make that choice on articles, provided we do all necessary conversions.
  4. For "centimeters first" conversion, we seem to be using {{Convert/hand}} and it's still a bit in flux. THIS MOSTLY WORKS AND ONLY NEEDS MINOR FIXES
  5. The members of WPEQ have discussed the measurement topic extensively and there is a majority consensus that a "three-way" conversion is generally preferred.
  6. {{Convert/hand}} works for converting centimeters to hands, and with a single measurement we can get cm to both hands and inches
  7. HERE IS THE ONE PROBLEM: even with Convert/2, it fails to do a proper conversion from cm to BOTH hands and inches, in a range Ideally, we'd see centimeters entered and get output that looks like this: 156 to 157 cm (15.1-1⁄2 to 15.2 hands, 61.5 to 62 inches)
  8. The only time we have a real need for fractions is where a centimeter measurement that is "official" falls in a half-inch range, maybe also a quarter-inch (see next item)
  9. It is exceedingly rare that anything other than a 1/2 inch fraction would be needed. Occasionally in the pony world, you see a 3/4 inch measurement where someone is trying to get their animal to "squeak by" into a smaller height classification (no one in the horse world wants their horse to be the smallest in a classification, kind of like weight in wrestling that way...)
  10. In any article, at first use, we do need the option to add (or later suppress) a wikilink to the article on hands, and to have the output spell out "hands". Having a wikilink s default is probably best, as sometimes we only include a height measurement once. Thereafter, the abbreviation "h" or "hh" can be used. (Might be nice to allow either h or hh for editor preference, there's a minor US/UK variation there, but it's also not a moral issue)
  11. The "15.0 hands" versus "15 hands" is purely a style issue, some editors will prefer one over the other and it would be nice to be able to do both. Right now, {{hands}} default is 15 hands (60 inches, 152 cm). For fractions, it is necessary to say "15.0-1/2 hands, as, indeed "15-1/2" hands is 15.2 and thus very confusing.

Hope that sums it up. Montanabw(talk) 22:37, 14 December 2013 (UTC)

Hands clarification

Q1 In the above, @Montanabw: said that the wanted output from {{convert/2|137|–|162|cm|hand in}} is

137 – 162 centimetres (13.2 hands; 54 inches – 16 hands; 64 inches)

Is that really wanted? The "standard" convert approach gives stuff like this:

  • {{convert|137|–|162|cm|hand in|abbr=off}} → 137–162 centimetres (13.2–16.0 hands; 54–64 inches)

Ignoring the output values (and whether they should be rounded/displayed differently), is that result ok?

  • Yes, that's even better, actually! Montanabw

Q2 At "THE ONE PROBLEM" above, Montanabw wants this result:

156 to 157 cm (15.1½ to 15.2 hands, 61.5 to 62 inches)

The module currently does this (the first is to show the accurate values):

  • {{convert|156|to|157|cm|in|3|abbr=in}} → 156 to 157 cm (61.417 to 61.811 inches)
  • {{convert|156|to|157|cm|hand in|abbr=in}} → 156 to 157 cm (15.1 to 15.2 hands; 61 to 62 inches)

I need some rules for the wanted default output rounding. Please consider and fix the following:

  • Output hands: round to nearest half inch, but omit fraction if it rounds to zero.
    That should work. I can think of rare exceptions where1/4 inch is used,(Theodore O'Connor being the only example I can think of at the moment, actually) but we can do that within the hands template if it matters that much to someone, so I wouldn't fret about it here. As I've commented before, a simple hoof trim or horseshoe can add or subtract a half inch off of a horse's height. If you really want to see the pain in the ass rules that govern pony measurements, see Pony#Horses_and_ponies, first paragraph. Bleech. --Montanabw
    • 9½ hands is nine-and-one-half hands, while 9.0½ hands is nine-hands-and-one-half-inch.
    Yes, 9.0½ is not 9½ though "9½ hands" is also very sloppy form anyway, better to say 9.2 hands due to the obvious confusion created--Montanabw
  • Output inches: same, but show ".5" for half an inch, whereas a fraction is used for hands. Is ".5" really wanted, or would "½" be preferred?
    For hands, 1/2 is preferred, but for inches, .5 is fine if that's easier. Probably more what people expect, also, I suppose --Montanabw

Thus, the wanted output would be:

156 to 157 cm (15.1½ to 15.2 hands; 61.5 to 62 inches)
  • That would work nicely. --Montanabw

I'm pondering the other stuff, and should have fractions in outputs working soon. Johnuniq (talk) 01:59, 18 December 2013 (UTC)

  • You have my admiration for being able to figure this out. I'm seriously impressed. Montanabw(talk) 08:26, 20 December 2013 (UTC)
    • OK, and thanks for the details. I'll get this done ... sometime. I'm just responding to let anyone watching this know that I will archive all this soon because this page is very big and the archive bot is broken, but I have got the info. I'll add a new section when there are some results. Johnuniq (talk) 01:06, 22 December 2013 (UTC)

Convert/hand usage

  • Listing {{Convert/hand}} usage pages in mainspace, as seen 2013-12-10, some 12h before switchover (35 pages).

Today's usage [5] (28 in mainspace) does not use the module, so should be checked for that rounding in {{convert/hands}} usage directly.

Earlier usage of hands
Page Direct Solved
1 Convert/hand African wild ass ?
2 Convert/hand Anchitherium ?
3 Convert/hand Ardennes horse ?
4 Convert/hand Auvergne horse ?
5 Convert/hand Barb horse ?
6 Convert/hand Breton horse ?
7 Convert/hand Budyonny horse ?
8 Convert/hand Camargue horse ?
9 Convert/hand Catria horse ?
10 Convert/hand Cavallo Romano della Maremma Laziale ?
11 Convert/hand Coldblood trotter ?
12 Convert/hand Comtois horse ?
13 Convert/hand Dan Blocker ?
14 Convert/hand French Saddle Pony ?
15 Convert/hand French Trotter ?
16 Convert/hand Hipparion ?
17 Convert/hand Hispano-Árabe ?
18 Convert/hand Huaso (horse) ?
19 Convert/hand Mallorquín ?
20 Convert/hand Međimurje horse ?
21 Convert/hand Menorquín horse ?
22 Convert/hand Miniature horse ?
23 Convert/hand Neapolitan horse ?
24 Convert/hand Nonius horse ?
25 Convert/hand Parahippus ?
26 Convert/hand Percheron ?
27 Convert/hand Posavac horse ?
28 Convert/hand Pottok ?
29 Convert/hand Pryor Mountains Wild Horse Range ?
30 Convert/hand Sarcidano horse ?
31 Convert/hand Selle Français ?
32 Convert/hand Silesian horse ?
33 Convert/hand Tolfetano ?
34 Convert/hand Vyatka horse ?
35 Convert/hand Yakutian horse ?

-DePiep (talk) 16:47, 13 December 2013 (UTC)

We could introduce parameter |link to page= for this effect:

{convert|1435|mm|ftin|link to page=standard gauge|abbr=on}}
current output: → 1,435 mm (4 ft 8.5 in)*
to be: → 1,435 mm (4 ft 8.5 in)

In rail gauges, this example measure is iconic. Iconic numbers make a likely usage. By first intuition, I think only out1 should be linked. Better not overload |lk= with this.

No hurry, this is just to coin the idea ;-) -DePiep (talk) 11:24, 14 December 2013 (UTC)

  • Use Convert/f for custom formatting of data: A logical alternative, to unusual choices for link-text, would be to insert a footnote or superscript as an explanatory note, such as in Template:Convert/f:
  • {{convert/f|1,435|mm|ftin|abbr=on|x2=[[Standard gauge|<sup>[usage]</sup>]]}}    → 1,435 mm[usage] (4 ft 8.5 in*)
By using the customization option "x2=" (or "x1=" or "x4=") to link a note with "Standard gauge", then any explanatory note could be inserted into the middle of a conversion. In prior years, there have been many requests to insert text at various positions within a conversion, and so the options "x0=" to "x5=" were added for custom insertions in {convert/f} or {convert/flip}. The use of superscript notes, or footnotes, allows the wikilinks of the units to function consistently, without interference from other linked text. -Wikid77 (talk) 14:31, 14 December 2013 (UTC)

Template:Gundisp

Resolved

can someone fix this one? 174.56.57.138 (talk) 20:23, 14 December 2013 (UTC)

What is broken? (Convert wrapper; not used in mainspace). -DePiep (talk) 20:32, 14 December 2013 (UTC)
nevermind, I fixed it. it was using convert subtemplates instead of the main convert template, but it's now fixed. 174.56.57.138 (talk) 21:02, 14 December 2013 (UTC)

abbr=~

what is the purpose of abbr=~? I didn't find it in the documentation. for example, {{convert|27|cm|in|1|abbr=~}} → 27 centimetres [cm] (10.6 in), which seems like an odd choice for output. 174.56.57.138 (talk) 23:10, 14 December 2013 (UTC)

The option is briefly mentioned at Help:Convert, but all it says is that abbr=~ shows the input unit symbol as well as the name. It was introduced in the November 2012 archive.
At 19 November 2013, the following articles used "abbr=~": Jhang + Mariner 1 + Puerto Errado + Sarnia Photovoltaic Power Plant + Taiko + Wolverine (train).
It looks rather odd to me, but it is supported by Module:Convert for compatibility. Johnuniq (talk) 00:29, 15 December 2013 (UTC)
I have added "abbr=~" to the /doc page. A unit symbol can be introduced by showing it in parentheses brackets with "abbr=~". In some agencies of the U.S. Federal Government, every acronym (or symbol) is introduced in documents as a parenthetical after the full name: "Hubble Space Telescope (HST)" and so option "abbr=~" provides a similar format for users: {{convert|9|kPa|abbr=~}} as "9 kilopascals [kPa] (1.3 psi)" where the symbol "kPa" can then be used as denoted. It is ironic how "abbr=~" has been rarely used to date, but would occur by the thousands in U.S. government documents, as a contrast to Wikipedia's typesetting style. -Wikid77 13:46, 15 December 2013 (UTC)

Updating Template:Convert/doc in transition

As some have noticed, the typical documentation page is out-of-date, where "Template:Convert/doc" had not been fully updated in over 5 years. I have added option "abbr=~" to the /doc page, and explained "sp=us". During the transition to Lua, we should clarify further options and begin thinking how to explain the new options of the Lua version, such as "spell=in" perhaps as a new subsection, depending on consensus for noting the Lua options. Over the years, there have been many requests to update the /doc page, but even several users who requested various updates did not always remind other volunteers about undocumented features. Anyway, I will continue documenting options which work for both the markup-based and Lua versions, plus modernize the descriptions from 5 years ago. -Wikid77 13:46, 15 December 2013 (UTC)

A very good ambition! I myself am afraid of diving into this, very difficult to write the huge and complicated doc. But there should be no inclusion of anything aimed at markup-based {convert} because a. {{convert}} does not use markup and b. it would add complexity & confusion for the user. -DePiep (talk) 18:46, 15 December 2013 (UTC)

Limited time to handle Lua problems

This time-of-year is very busy for many Wikipedians, as the start of winter in upper northern latitudes, or the start of summer in lower southern latitudes, with the related activities, on a daily basis, at the start of each season. Hence, I have asked to delay major changes for another month, into January 2014, to gather a broader consensus. The transition to Lua Convert has been a logistical nightmare at this time of year, triggering (or instigating) far more problems than it has solved, with little time to correct for all the new errors being generated. Please understand how the markup-based Convert would auto-correct for numerous problems (such as accepting "7.98.0" as 7.980, or "-" as zero, to give reasonable results in live articles) which the Lua Convert treats as fatal errors, creating busy work to update problems caused by transition to Lua without appropriate time to handle them. -Wikid77 (talk) 16:21, 16 December 2013 (UTC)

I think you mean to say that "7.98.3" is existing writing for hectare, reading "7 hectare (@ 10000 m2), 98 are (@ 100 m2), 3 centiare (@ 1 m2)" (as these units step by a factor 102, not 103 orders as we are more familiar with seeing; while the second point is a reading aide. IIRC this is accepted format for hectare in (hand-)writing. Being for an area, a 102 is understandable. When I see it in {convert} input, I check & remove the second period. Did not need exact source quoting need, so far.
{convert} could think of accepting such input for hectare. Any other units with such a systematic usage? For me, not a big or hurrying issue. Editable. -DePiep (talk) 01:21, 17 December 2013 (UTC)

Superscript disruption - containted

Little relevance, just noting. I actually encountered this: In a template: |temp=< 50 °C → (the lt sign is hardcoded, not escaped).

Input is invalid to begin with. Just to point out that the < sign disrupts the span. The rampage is contained within the superscript, no outbreak.

Variants:

-DePiep (talk) 21:46, 16 December 2013 (UTC)

Uh oh, programming 101 fail—next there will be code injection exploits. I'll have a go at escaping user input when I release (to the sandbox) the complex change I'm working on atm, per above sections. Johnuniq (talk) 22:23, 16 December 2013 (UTC)
I uploaded a fixed version to Module:Convert/sandbox and it seems to work:
The new module contains a bunch of other fiddly changes that I have been working on as preparation to handling fractions in output values—I had used the word "fraction" quite a lot in the code to refer to the fractional part of a number (so value 12.34 has "fraction" .34), and I didn't want the confusion of the new code using "fraction" to refer to actual fractions like 12⁄34.
There are now 28 fails at Module talk:Convert/sandbox/testcases because the new code does more aggressive escaping of messages. I have looked at each fail and the new results are good. Some other time I will fix the testcases to match output from the new version. Johnuniq (talk) 00:59, 17 December 2013 (UTC)
Clearly I didn't see the danger... (would have mailed then). -DePiep (talk) 01:25, 17 December 2013 (UTC)
Sorry, my comment was a joke referring to the fact that most software that works on the Internet has had security problems from a failure to properly sanitize user input, and I should have realized that plonking user input in an error message needed escaping. However, there are no security issues regarding the module because it has no privilege, and it cannot do anything that a user could not do anyway. Johnuniq (talk) 02:21, 17 December 2013 (UTC)
Yes I understood that from you. Hadn't thought of that, I was writing "curiousioty, just bad input, don't spend time". -DePiep (talk) 04:08, 17 December 2013 (UTC)

Bequerels

Comes another wishlister to your door, begging a boon.

I am able to convert from megacuries (MCi) to petabequerels (PBq). In order to handle the range of values that are required for measuring the radioactivity of atomic testing, three engineering ranges have to be accessed:

megacuries (MCi) to petabequerels (PBq) (ok)
kilocuries (kCi) to terabequerels (TBq)
curies (Ci) to gigabequerels (GBq)

Pretty please? I'll appreciate it. SkoreKeep (talk) 05:39, 17 December 2013 (UTC)

Have you tried that lately? Since the module was introduced nearly a week ago, these converts work (I hope):
  • {{convert|1|MCi|PBq|abbr=on}} → 1 MCi (37 PBq)
  • {{convert|1|kCi|TBq|abbr=on}} → 1 kCi (37 TBq)
  • {{convert|1|Ci|GBq|abbr=on}} → 1 Ci (37 GBq)
  • {{convert|1|MCi|PBq|abbr=off}} → 1 megacurie (37 petabecquerels)
  • {{convert|1|kCi|TBq|abbr=off}} → 1 kilocurie (37 terabecquerels)
  • {{convert|1|Ci|GBq|abbr=off}} → 1 curie (37 gigabecquerels)
Both Ci and Bq work with all SI prefixes. Johnuniq (talk) 05:56, 17 December 2013 (UTC)
Actually, I just did a quick test in a sandbox and the above works with the old templates as well, and it looks like it should have worked for years, so clarification of the problem is needed. Johnuniq (talk) 06:07, 17 December 2013 (UTC)
You're right, I was invoking them wrong and ran off into an unwarranted conclusion. So sorry for the trouble. SkoreKeep (talk) 06:12, 17 December 2013 (UTC)

DPI and dots/cm and micrometres per dot

I've added 3 new units to extra; I think I've done the right thing.

The issue was what the underlying units should be, I chose "length" because a dot is not any kind of standard unit and it's rather simpler.

This means that DPI/DPCM are 1/length units, which is not directly supported by convert so I set the 'iscomplex' and used the invert of -1, and in the micrometers per dot I simply set invert to 1.

It works fine, but there's a minor bug in convert in that it can't handle conversion between inverse units and units unless both units have the invert set; the script crashes badly, but for the most likely use of DPI/pitch/DPCM units this doesn't matter.

Anyway it looks more or less all right to me:

  • {{convert|1|dpi|pitch|lk=on}} → 1 DPI (25,000 μm)
  • {{convert|10|dpi}} → 10 DPI (2,500 μm)
  • {{convert|100|dpi|pitch}} → 100 DPI (250 μm)
  • {{convert|100|pitch}} → 100 μm (250 DPI)
  • {{convert|100|dpi|dpcm|lk=on}} → 100 DPI (39 dot/cm)

Not sure the sigfigs are quite right, but that's user settable anyway.GliderMaven (talk) 04:36, 14 December 2013 (UTC)

They are not actually lengths as you wouldn't want to convert between DPI & in so I've changed the utype to dotlength so all three are in a separate category. -- WOSlinker (talk) 07:51, 14 December 2013 (UTC)
On the contrary, they are actually lengths, they are the lengths of a dot, and you might want to convert the dot length into thousandths of an inch. By doing that you've modelled it incorrectly, and it cannot work as well.GliderMaven (talk) 11:05, 14 December 2013 (UTC)
They are "sort-of-lengths" but actually, they are multi-unit inverses of lengths, as composites of units-per-length, as dots-per-inch or dots-per-cm, where each is a combination of the dots unit with the inverse-length unit. The re-inverted unit would be length-per-dot, and not pure length, because 200 dpi and 400 dpi have the dots changing size, relative to an inch. -Wikid77 (talk) 11:50, 14 December 2013 (UTC)
No, dpi takes units of 1/length, and pitch takes units of length. Dots are definitely not a unit, they're a physical thing, like the length of a car, which varies car to car and dot to dot. Units don't vary.GliderMaven (talk) 12:21, 14 December 2013 (UTC)
Dpi takes units of 'per inch', which is a perfectly respectable unit.GliderMaven (talk) 12:23, 14 December 2013 (UTC)
Sorry, but dots are part of the compound unit "dots per inch" and so 200 dpi and 400 dpi vary only by the number of dots measured, where it is the same inch for both. To tranform dpi into pure dots, then multiply dpi by inches as: 200 dpi × 7 inches = 1,400 dots. I have a degree in mathematics (as well as 2 in computer science), so I have dealt with these issues for many years, but I understand how a compound of 2 units, such as dot units per inch units, could seem confusing. -Wikid77 (talk) 16:38, 16 December 2013 (UTC)
Exactly. dpi (dot/in) is a compound unit just as kg/m is and you can't convert kg/m directly into a length either. -- WOSlinker (talk) 17:08, 16 December 2013 (UTC)
Well, I'm not going to list my qualifications, but I'm qualified in physics and dimensional analysis is taught in physics and is in important in physics, and it's not very important in maths or computer science.
Look, start with pitch, pitch is just a length, right? These dots are 100 micrometres long, right? Easy peasy. We're measuring dots' pitch in units of length. Units of length. Great.
Now, dots per metre is just inverse pitch, 100 micrometre pitch is 10000 per metre. So it's units of 'per metre' 1/length, length-1.
Ignoring the fact that SI have not defined a 'dot' unit, you actually cannot have a 'dot unit' because units are always the same size. Dots vary wildly in size from dot to dot. So equally the concept of 'dot units' per 'metre' isn't a compound unit, because it would vary in size as well, So the units of dpi can't be a compound unit, it's just inverse length. Got it? It's just a trick of the English language just because it's labelled as 'dots per inch' doesn't mean that the units are formally 'dots per inch' it's actually just 'per length' which the convert script has to internally translate into 'per metre'.GliderMaven (talk) 17:57, 16 December 2013 (UTC)
And I notice that there's inverse units already in /data in fact. There's 'per unit area' which is used for things like population density. There's no other current use of 'per unit length' though, but that seems to be more by luck than judgement.GliderMaven (talk) 21:08, 16 December 2013 (UTC)
And there's no conversion currently between per area and area; even though that's a simple thing to calculate (how much area is used per person); although conversion between mph and l/km exists.GliderMaven (talk) 21:08, 16 December 2013 (UTC)
Becquerel is another one; it's marked as utype="radioactivity" but really a becquerel is 'per time'; it's radioactive decays per second. In principle it's useful to be able to convert between becquerels and seconds using an inverse (although unlike dpi and pitch I don't think it's necessarily useful, but it shouldn't be ruled out by the convert script, because the units line up).GliderMaven (talk) 22:07, 16 December 2013 (UTC)
I formatted the examples above to make it easier to see the conversions.
Most units are all lowercase for convenience. While "DPI" might be what is displayed, "dpi" as the unit code is more natural to type, and more like most other units.
The solution you found is ingenious, but something more robust would be needed for the long term. The "iscomplex" field is not documented because it is not exposed—it is set by Module:Convert/makeunits when certain conditions are met. I was thinking of perhaps "resolution" for the unit type, but "dotlength" is clearer. I'll think about the issue later. Johnuniq (talk) 07:56, 14 December 2013 (UTC)
And I found another example where creating a dotlength types doesn't work at all well. There's a unit called 'thrust specific fuel consumption" that nominally has units of g/Ns or lb/lbf.h, and there's a related unit which is specific impulse nominally seconds (although arguably it's not as there's a cancellation of lbf and lbm in the middle), but there's another related unit 'effective exhaust velocity' that is variously m/s, km/s or ft/s or miles/s or maybe fractions of the speed of light (i.e. it really is just an ordinary speed); and that's the most important unit of all. The thrust specific fuel consumption is inversely proportional to the speed, but the other units are directly proportional to speed, so I want to be able to use the inverse trick for that, and I definitely don't want to create the equivalent of a special speed; centering the conversions on speed is going to be a clear win.GliderMaven (talk) 11:05, 14 December 2013 (UTC)
It seems to be quite a robust and general trick in fact. Having units that are inversely proportional to other units is not completely uncommon and we already have other examples where they are one unit over another, like fuel consumption l/100km versus miles/gallon.GliderMaven (talk) 11:05, 14 December 2013 (UTC)
{ec} Habit proposal: let's add real usage page(s) for convert/extra additions. They are in development by defiunition.
Even better: the module code could add to Category:Pages that use module:convert/extra data: all pages that use convert/extra. -DePiep (talk) 11:07, 14 December 2013 (UTC)
So:
  • {{convert|350|isp}} → 350 seconds (3.4 km/s)
  • {{convert|1.2|tsfc|isp}} → 1.2 lb/(lbf⋅h) (3,000 s)
  • {{convert|0.71|tsfc|isp}} → 0.71 lb/(lbf⋅h) (5,100 s)
  • {{convert|450|isp|ft/s}} → 450 seconds (14,000 ft/s)
But:
  • {{convert|1.2|tsfc|m/s}} → 1.2 lb/(lbf⋅h) (29,000 m/s)
So I'm standing by my claim this is a bug in convert.GliderMaven (talk) 12:14, 14 December 2013 (UTC)
Putting undocumented and unsupported fields into convert/extra may break the module as it works on the assumption that the data modules contain valid definitions. There are two schools of thought on handling unforeseen problems—purists would like all errors trapped, and pragmatists want simpler code. As a pragmatist, I think "Script error" is as good as any message that could be displayed if the error were trapped (well, I suppose it would be nicer if the message linked to this talk page so someone seeing the problem could easily find a place to complain). I will get around to implementing (in the sandbox) a small enhancement so the module suppports inverted units in a more general way, and will announce it here.
Re all the new units: are you sure they will actually be used? New units expand the gargantuan master list, and add to the confusion resulting from so many alternatives.
@DePiep: I don't think a tracking category is worthwhile as Special:WhatLinksHere/Module:Convert/extra is sufficient. Unfortunately that list is rather long at the moment (119 articles) because extra includes a couple of units that are used in many articles and which I did not know about before deployment. My blue-sky plan is for a tool at WP:Labs that provides an interface to a weekly snapshot allowing usage of all units and options to be queried. Johnuniq (talk) 01:06, 15 December 2013 (UTC)
Yes, I think we can use these new units, they're standard book units, that are widely known in the aerospace field, and they will be useful in many hundreds and quite possibly thousands of articles; and they're a right pain and error prone to do manually. I was able to use these new conversions three times in the very first article I looked at. The only reason I think they're not there already is that it's been fiddly to add them. This 'extra' thing is very useful as a low-risk way to test new conversions out.GliderMaven (talk) 03:03, 15 December 2013 (UTC)

Ok, I've got a fixed version of 'convert' that extends the idea used in fuel consumption conversions and rounds it out to deal with all inter-convertible inverse unit relationships.

In other words you can define dpi which takes units per inch, and convert them to m, or furlongs or whatever you want. It also works with mpg, and specific impulse/thrust specific fuel consumption.

The code is straightforward.

To set up an inverse unit you define it as a normal non inverse unit and set the complex flag and the invert flag, and set the scale appropriately, and my lightly modified version of convert does the rest.

My (fully backward compatible) version is here:

Module:GliderMaven/converttest

and you can currently run it like: 

*<code>{{User:GliderMaven/convert|100|dpi|m}}</code>  → {{User:GliderMaven/convert|100|dpi|m}}
*<code>{{User:GliderMaven/convert|100|dpi|thou}}</code> → {{User:GliderMaven/convert|100|dpi|thou}}
*<code>{{User:GliderMaven/convert|100|dpi|mm}}</code> → {{User:GliderMaven/convert|100|dpi|mm}}
*<code>{{User:GliderMaven/convert|33|tsfc|km/s}}</code> → {{User:GliderMaven/convert|33|tsfc|km/s}}
*<code>{{User:GliderMaven/convert|33|km/s|tsfc}}</code> → {{User:GliderMaven/convert|33|km/s|tsfc}}

whereas:

  • {{convert|100|dpi|m}} → 100 DPI (0.00025 m)
  • {{convert|100|dpi|thou}} → 100 DPI (10 thou)
  • {{convert|100|dpi|mm}} → 100 DPI (0.25 mm)
  • {{convert|33|tsfc|km/s}} → 33 lb/(lbf⋅h) (1.1 km/s)
  • {{convert|33|km/s|tsfc}} → 33 kilometres per second (1.1 lb/(lbf⋅h))

The changes I've made are here: [6]

Is that reasonable? I'm prepared to update the documentation and it would be good to make some other changes to the existing conversions at around the same time; if people are agreeable to install it. There's no hurry to install it, it's not urgent, it could go in after Christmas if you wish, things are more or less working right now.GliderMaven (talk) 00:16, 17 December 2013 (UTC)

Editors have never been able to convert those units, and a couple of weeks delay before a fully functioning system is available will not be a problem. In particular, Wikid77 (at 16:38, 16 December 2013) and WOSlinker (at 17:08, 16 December 2013) have mentioned what I regard as a serious problem, namely that the new units need their own unit type—converting "100 dots per inch" to "0.00025 m" does not make sense to me. By the way, WP:CWW says that copy/paste of a page must use an edit summary with a link to the original page. Johnuniq (talk) 02:42, 17 December 2013 (UTC)
I agree that converting dpi to meter doesn't make any sense; Possible converting DPI to meter/dot would be OK, though I wonder if "0.25 mm/dot" is used anywhere? →AzaToth 02:54, 17 December 2013 (UTC)
Well, the first example I found when I googled it did not express it as micrometers per dot, just simply micrometers, and dimensional analysis would suggest this is correct. I believe that the resolution of 3D printers is described either as dpi or in micrometers. I also found this book which seems to be a reliable source, and I've found no reliable sources that use um/dot. The clear convention among the reliable sources I've found is to use simply micrometers. Fortunately as a convention it's the most dimensionally correct, and requires the least conversions to be written. So I propose to follow the reliable source.
The screw case that is supported by inverse relations is the conversion between lb/lbf.h and m/s or km/s which does not work correctly without the code patch; and those are definitely valid, common conversions in the aerospace field, that are otherwise not supported. It's the aerospace version of mpg. The units are strange looking because F=ma is arguably not dimensionally correct(!)
As to the existence of a copy of 'convert', it's going to be deleted, there's a specific clause in WP:CWW that it only matters for things that are going to be kept, it's about attributing the history correctly; but I'll gladly tag it in the meantime.GliderMaven (talk) 11:22, 17 December 2013 (UTC)

Detecting incorrect number formatting

At the Vietnamese Wikipedia, where numbers are of the form "123.456,7", we prefer templates to take Vietnamese-style numbers as input, especially considering that VisualEditor lets editors enter parameters into a form with Vietnamese text all around. So we need to detect when editors have blindly copy-pasted English-style numbers without swapping the commas and periods. With these changes, a number like "123,456.7" is converted properly, but a small warning appears after the conversion and the article is added to a tracking category. (Ambiguous numbers like "123.456" and "123,456" are assumed to be correct.)

A reference to this number detection code might be useful in a rewritten Template:Convert/Transwiki guide. Does the reverse approach (detecting non-English numbers) make sense at the English Wikipedia?

 – Minh Nguyễn (talk, contribs) 10:22, 16 December 2013 (UTC)

Thanks for pointing out that Template:Convert/Transwiki guide needs fixing. Perhaps we could replace it with "please ask at Module talk:Convert" as an interim measure.
You have raised an interesting issue, and it's true that people do copy/paste text, particularly from enwiki. I would like to take a close look at what you've done, but I don't have any time at the moment because I'm thinking about some issues needed here (fractions in output, and the hands and "inverted" new units above). For my interest, I have put links to related pages at vi:User:Johnuniq.
You have done a lot of work, and it appears you have pretty well translated everything. Congratulations, although I am puzzled about why I can't see "translation_table". Johnuniq (talk) 11:49, 16 December 2013 (UTC)
You may not know about the translation_table because I see you have done a bunch of editing in the main module. Do you want Vietnamese digits displayed like Bengali is at bn:User:Johnuniq/Translation? Johnuniq (talk) 12:05, 16 December 2013 (UTC)
No, thankfully Vietnamese uses ASCII digits. In Vietnamese-style numbers, the commas and periods are opposite from English usage. – Minh Nguyễn (talk, contribs) 12:06, 17 December 2013 (UTC)
  • English Wikipedia needs to detect decimal commas but rare: For years, we have noted numbers being copied from some European sources with decimal commas, such as "1,25" to denote 1.25, but where "1,25" is treated as "125" or 100x times too large in conversions. Such cases are extremely rare, and often detected within a month or so to be hand-corrected. -Wikid77 (talk) 16:21, 16 December 2013 (UTC)

Tracking template space

I suggest that in the next code change, the tracking of template space can be switched off. Only mainspace pages in Category:Convert invalid options, Category:Convert invalid units. -DePiep (talk) 08:31, 19 December 2013 (UTC)

Yes, we do not seem to get much benefit from adding an error category to templates, so I have just changed the default to articles only. That will appear when I next upload the module to the sandbox. Johnuniq (talk) 09:10, 19 December 2013 (UTC)

Infobox fixes needed

I listed some articles at WT:WikiProject France#Place Dauphine that are broken because text is being passed to convert instead of a number to be converted. I'm hoping a wizard will work out why the infobox apparently used to work, but now fails. A particularly bad case is at Rue Royale, Paris where the defect mentioned at #Superscript disruption - containted above causes a long error message which makes the infobox expand to fill the window. What's puzzling, is that the Google cache of that page shows that it used to work. In case the cache disappears, I'll explain that it shows a normal infobox with "Width" at the left, and the following at the right (this text wraps to four lines):

22 m (72 ft) 80 between place de la Concorde and rue du Faubourg Saint-Honoré; 43 m elsewhere.

Some of the text is not visible in the cache, but selecting it shows that it is there. Johnuniq (talk) 00:47, 19 December 2013 (UTC)

looks like this broke it. 99.151.37.7 (talk) 03:12, 19 December 2013 (UTC)
fixed that article, and added a width_note parameter for references or other notes. 99.151.37.7 (talk) 04:06, 19 December 2013 (UTC)
Thanks 99, that seems to have fixed it nicely. Johnuniq (talk) 05:27, 19 December 2013 (UTC)
|width2= was not documented. Good {convert} showed this. I started using |width2= this way because some other street uses a "width range" preferably throug {convert}. Solution by IP is nice & complete. -DePiep (talk) 08:39, 19 December 2013 (UTC) added -DePiep (talk) 11:18, 19 December 2013 (UTC)

Convinfobox

I created a version of {{convinfobox}} which uses the lua module (see {{convinfobox/sandbox}}), rather than the convert subtemplates. a comparison of the output can be found in the Template:Convinfobox/testcases. note that the current version is broken in that abbr=off behaves like abbr=out, so the abbr=off mismatches are not a concern. however, it does seem like we should do something about 65 kilograms (143 lb; 10 st 3 lb), since I would expect the precision to be the same for both output units? thank you. Frietjes (talk) 21:44, 17 December 2013 (UTC)

Can |0 be inserted as a quick fix?
  • {{convert|65|kg|lb stlb|0}} → 65 kilograms (143 lb; 10 st 3 lb)
Rounding is complex. I see that the old template converts 65 kg to 143 lb (whereas the module gets 140 lb), but I suspect it has been tweaked to give extra precision. I haven't looked recently, but it's likely that the module is just applying its standard rules in the same way it would for any other conversion, but unfortunately it's getting bad results for important measurements like a person's weight. I could investigate the precision stuff if the workaround is not attractive. Johnuniq (talk) 22:37, 17 December 2013 (UTC)
yes, specifying the precision would work, so would adding sigfig=3. in fact, I had just removed this hack since I was worried about the case where a higher precision was specified for the input. the other reason for not introducing the hack there is that this goes beyond {{convinfobox}}, and is really at the level of convert. some problems could be fixed by introducing a fixed precision in templates like {{infobox rugby biography}}, but that won't entirely solve the problem. as for the old convert, it uses template:Convert/LoffAonSoffMinp. Frietjes (talk) 23:21, 17 December 2013 (UTC)
if this can't be easily fixed, it would be good to have some tracking for the conversion to lb stlb without sigfig or precision specified. I just fixed ice hockey player, but there are certainly more. Frietjes (talk) 00:10, 18 December 2013 (UTC)
I'll have a look at the precision issue, but probably won't report back for a day or two. If I forget, please remind me! Johnuniq (talk) 00:33, 18 December 2013 (UTC)
on second thought, it looks like the change is broader, the old convert reported a higher precision for 65 kilograms (143 lb) (143 vs. 140 lb) as well, so the thing to do would be to increase the precision for all conversions from kg to lb, if we want to match the old behaviour. thank you! Frietjes (talk) 00:35, 18 December 2013 (UTC)
This counting sigfig only works straight within the same (linear) scale. That is where it is defined (using mantissa notation). But when changing scale: a kg digit measurement precision (0--9) contains ~twice in lb precision (0--19). So sigfig=3 in kg corresponds to sigfig=~3.5 in lb (how to calc with that is another issue). This is why sigfig is not usuful always ("not always" is devastating in physics, right?). In inch-to-mm with sigfig=3, that would be ~3.4.
Then, in these persons weights, there may be cultural ways of roundings involved (babies?). Question: while 64 kilograms (141 lb) is not wrong (calculates back ok: 140 pounds (64 kg)), don't we expect 141 lb? -DePiep (talk) 02:13, 18 December 2013 (UTC)
Some investigation shows that Template:Convert/lb was changed to give more default precision when the input value is an integer. The same is done for feet. As a quick experiment, I have created unit "LB" in Module:Convert/extra with the same property as the old template. After some testing, I will delete the "LB" experiment and put the required property in "lb", but that will require an update to the data module. On the topic of making big changes, I started looking at the job queue (WP:JQ) while wondering why the categories were not filling up with convert problems, but unfortunately I did not look before the switch to the module. The job queue has been around 7 million for the last week, but it started going down 24 hours ago, and it is now under 1 million. I need to remember to monitor it more closely before and after when we update the live modules because I have no idea if the 7 million is connected with the convert module. Examples:
  • {{convert|65|kg|lb}} → 65 kilograms (143 lb)
  • {{convert|65|kg|lb stlb}} → 65 kilograms (143 lb; 10 st 3 lb)
  • {{convert|65|kg|LB}} → 65 kilograms ([convert: unknown unit])
  • {{convert|65|kg|LB stlb}} → 65 kilograms ([convert: unknown unit])
Johnuniq (talk) 08:55, 18 December 2013 (UTC)
You mean lb and ft will have this incidental rounding behaviour everywhere? -DePiep (talk) 13:23, 18 December 2013 (UTC)
Yes, ft already has the feature (see exception= "integer_more_precision", in Module:Convert/data which is put there by a "specials" table in Module:Convert/makeunits). I will add lb to the specials table and update the data in due course—I guess about a week from now, oooh, that's Christmas, maybe a bit before or after. Johnuniq (talk) 20:47, 18 December 2013 (UTC)
I don't think it is a good idea to promote one way of rounding into the general one. Be it from cultural or from {convert/nonlua} behaviour in cases, we should not tie the module to one. That way, next month and after we cannot move back or forth any more because of "current behaviour" and "expected" (we have tied ourselves into a newly introduced hack). I suggest the option is to be set explicitly (can be used in {{convinfobox}}) for now. Later sound rules can be implemented that works for all. IOW, for now we emulate {convert/nonlua} behaviour where it is due. Later there is time to approach it generally. -DePiep (talk) 10:54, 19 December 2013 (UTC)
The integer_more_precision issue is a well-planned adjustment to the default precision that experiment shows is helpful for some common conversions. It was first devised for conversions from meters to feet, and it looks like it was also found helpful for kilograms to pounds (the conversion factors are similar). I had a look at quite a lot of sample converts from my local collection, and the change seemed desirable. Johnuniq (talk) 11:50, 19 December 2013 (UTC)
  • About the JQ. I found this historical graph [7]. Rolling weeks, so be quick to look & printscreen. Maybe there is more history saved. (Links at bottom of WP:JQ page). Some steep slopes:
Thu 12 Dec 2013 ~06.20 UTC: 12.5 M
Thu 19 Dec 2013 ~07.00 UTC: 11 M
The {convert} switchover was Wed 11 Dec 2013, 02.11 UTC. I see no time related edits in the big module:Citation/CS1 CS1.

This is from your interest right? Not from worrying or withholding I hope ;-) . -DePiep (talk) 10:43, 19 December 2013 (UTC)

Yes, just my interest. I expected the tracking categories to show hundreds of problems—there were almost 100 at Commons—so I wondered whether the job queue was holding up the categories. Anyway I'm glad that convert is apparently not responsible for the dramatic rise in the queue. Perhaps the categories are nearly empty because people have been quickly fixing problems—WOSlinker did hundreds before the module went live. I'll stop looking for trouble. Johnuniq (talk) 11:50, 19 December 2013 (UTC)


Another way to round: bounce it

Above we noted that "sigfix=x" is not always correct when switching units (different scales). In calculating, there is another route: bounce it. Calculate the reverse (lb to kg), and keep just those digits (in lb) needed to reach the original precision (in kg). In the example 65 kilograms (143 lb; 10 st 3 lb):

Step 1: source ('input') is "65 kg" (has sigfig=2).
Step 2: in digits unlimited, this is 65 kilograms (143.3004704 lb) to return.
Step 3: How many sigfig n in lb are required, to arrive back at "65" (sigfig=2)?
n=2 140 pounds (63.50293180 kg) -- wrong, would yield "64"
n=3 143 pounds (64.86370891 kg) -- OK
n=4 143.3 pounds (64.99978662 kg) -- OK too, but too precise.
So for "65 kg", n=3.
This way, "64 kg" and "66 kg", need n=2.
64 kilograms (141.0958478 lb) -- n=2 needed, from 140 pounds (63.50293180 kg)
65 kilograms (143.3004704 lb) -- n=3 needed, from 143 pounds (64.86370891 kg)
66 kilograms (145.5050930 lb) -- n=3 needed, from 145 pounds (65.77089365 kg)

This might need some extra working I guess ;-). -DePiep (talk) 14:07, 18 December 2013 (UTC)

Well, still does not deliver the more obvious 141 lb for 64 kg. -DePiep (talk) 15:03, 18 December 2013 (UTC)
I'm going to pass on thinking about variations on rounding atm. It's very tricky, and will probably wait for next year. Johnuniq (talk) 20:50, 18 December 2013 (UTC)
My suspicion is that the rounding is currently being a little bit too clever: it seems to be rounding from 2 digits to 2 digits. This very nearly works, but there's corner cases where it does the wrong thing (65kg -> 140 kg being one of them.) It would be better to simply round 2 digits to 3 digits everywhere; it doesn't look as good, but otherwise the converted digits have been rounded a second time and so you've lost precision; and the converted results are unreliable for scientific work which is a primary use of Wikipedia; which is after all a reference work.GliderMaven (talk) 14:39, 19 December 2013 (UTC)

Changing sigfigs?

When going from kg to lb, the sigfigkg is changed to sigfigkg+0.45. Because a single lb digit has more weight precision (being ±0.23kg) that 1 digit kg weight (being ±0.5kg).

Does not this lead to this rule: When the unit scale 1 lb⁄1 kg <1, the sigfig should have +1? (sigfigkg=2, sigfiglb=2+1=3)? -DePiep (talk) 15:03, 18 December 2013 (UTC)

Todo list

Is there a todo list anywhere? One of the previous sections mentioned ranges and precisions.

For example: {{convert|5000|–|5000.4|lb|kg}} 5,000–5,000.4 pounds (2,268.0–2,268.1 kg)

The module needs modifying to calculate the precision for each input number and then use the largest for all rather than doing each number individually. -- WOSlinker (talk) 21:58, 18 December 2013 (UTC)

Hmmm, ok. A todo list is going to be needed, where do you suggest? A subpage here is the obvious place, but there may be too many subpages of Template:Convert already. Johnuniq (talk) 00:37, 19 December 2013 (UTC)
I've added a todo list on Module talk:Convert and put a couple of item in it. May be others to add though. -- WOSlinker (talk) 12:27, 19 December 2013 (UTC)

Please clarify todo#2: |disp=output unit. Is that syntax to match what {{val}} does? There already is |disp=unit which seems to do what is wanted:

  • {{convert|1|m|disp=unit}} → metre
  • {{convert|1|m|sp=us|disp=unit}} → meter
  • {{convert|1|m|disp=unit|lk=on}} → metre
  • {{convert|1|m|disp=unit|abbr=on}} → m
  • {{convert|1|m|disp=unit|abbr=on|lk=on}} → m

Related options are at Help:Convert#Displaying parts of a convert. If necessary, it would be easy to make "output unit" an alias for "unit", but that would be confusing on the convert side of things because "output" means the result of the conversion, whereas disp=unit is displaying the input unit. Johnuniq (talk) 22:13, 19 December 2013 (UTC)

Yes, disp unit is fine. No need for output unit. -- WOSlinker (talk) 22:22, 19 December 2013 (UTC)
|disp= is overloaded. Various independent settings are entered via disp, thereby making certain combinations impossible. In a module, we have freedom to solve it systematically. (We can add independent params like |what_to_show=, |separator=, |sequence=, but that is my personal response). -DePiep (talk) 22:50, 19 December 2013 (UTC)
Agreed, and in fact that has been acknowledged in the past with regard to the old templates. In a month or two we can contemplate what might be done to improve the syntax. Unfortunately, just about all of the old syntax will have to be supported for a long time because a lot of editors are familiar with it and will use it. Johnuniq (talk) 00:32, 20 December 2013 (UTC)

Todo#1 is tricky, so I thought I would share the pain. On my system I have implemented a method to ensure the highest default precision is used for each convert.

  • {{convert|10000|to|10000.5|m2|acre}} → 10,000 to 10,000.5 square metres (2.4711 to 2.4712 acres) (current module)
  • Result from my system: 10,000 to 10,000.5 square metres (2.4711 to 2.4712 acres)

But it fubars combinations:

  • {{convert|10000.5|m2|acre m2}} → 10,000.5 square metres (2.4712 acres; 10,000.5 m2) (current module)
  • Result from my system: 10,000.5 square metres (2.4712 acres; 10,000.5000 m2)

Using m2 for the output would not happen, but it illustrates the problem. Each unit has to be handled separately. Johnuniq (talk) 00:32, 20 December 2013 (UTC)

Precision in ranges

It turned out to be fairly easy to fix the convert problem which was giving the following (output is fixed text showing how the module behaved today):

  • {{convert|5000|–|5000.4|lb|kg}} → 5,000–5,000.4 pounds (2,300–2,268.1 kg)

I have added some code to repeat the convert if necessary—the code monitors the default precision for each convert for each output unit, and triggers a repeat of the convert if the precision increases.

It was fairly easy to do, but it's taking quite a long time to convince myself that I haven't introduced some subtle bug. Anyway, I thought the following results might be of interest.

Running on my system, I compared the new code with the old code when run over the 1.7 million converts from all articles at 4 November 2013 (that does not include converts called from other templates). About 7700 of these (1 in 200) have a different output using the new code. Of those, 2500 converts had to be run twice because the default precision increased during the conversion. That is a negligible overhead, so I won't worry that a convert can run twice.

Following are examples of the differences (first line = current module; second line = new system): 

{{convert|300|to(-)|600|m|ft}}                    300 to 600 metres (980–2,000 ft)
                                                  300 to 600 metres (980–1,970 ft)
{{convert|900|-|1870|m}}                          900–1,870 metres (3,000–6,140 ft)
                                                  900–1,870 metres (2,950–6,140 ft)
{{convert|3400|to|4000|m|ft|abbr=on}}             3,400 to 4,000 m (11,200 to 13,000 ft)
                                                  3,400 to 4,000 m (11,200 to 13,100 ft)
{{convert|3000|-|4500|ft|m}}                      3,000–4,500 feet (910–1,400 m)
                                                  3,000–4,500 feet (910–1,370 m)
{{convert|30000|-|41000|ft|m}}                    30,000–41,000 feet (9,100–12,000 m)
                                                  30,000–41,000 feet (9,100–12,500 m)
{{convert|60|-|3300|m|fathom ft}}                 60–3,300 metres (33–1,800 fathoms; 200–10,800 ft)
                                                  60–3,300 metres (33–1,804 fathoms; 200–10,830 ft)
{{convert|3000|to|150000|ST|LT t|lk=on}}          3,000 to 150,000 [[short ton]]s (2,700 to 130,000 [[long ton]]s; 2,700 to 140,000 [[tonne|t]])
                                                  3,000 to 150,000 [[short ton]]s (2,700 to 133,900 [[long ton]]s; 2,700 to 136,100 [[tonne|t]])
{{convert|4000|to|4436|MT|abbr=on}}               4,000 to 4,436 t (3,900 to 4,366 long tons; 4,400 to 4,890 short tons)
                                                  4,000 to 4,436 t (3,937 to 4,366 long tons; 4,409 to 4,890 short tons)
{{convert|300|and|1000|nmi|km mi}}                300 and 1,000 nautical miles (560 and 1,900 km; 350 and 1,200 mi)
                                                  300 and 1,000 nautical miles (560 and 1,850 km; 350 and 1,150 mi)
{{convert|3|to|5|in|cm}}                          3 to 5 inches (7.6 to 13 cm)
                                                  3 to 5 inches (7.6 to 12.7 cm)
{{convert|4.1|×|2.4|in|mm|abbr=on|disp=number}}   100 mm × 61
                                                  104 mm × 61
{{convert|4|to|10|kn}}                            4 to 10 knots (7.4 to 19 km/h; 4.6 to 12 mph)
                                                  4 to 10 knots (7.4 to 18.5 km/h; 4.6 to 11.5 mph)
{{convert|30|-|36.5|kn|lk=in}}                    30–36.5 [[Knot (unit)|knots]] (56–67.6 km/h; 35–42.0 mph)
                                                  30–36.5 [[Knot (unit)|knots]] (55.6–67.6 km/h; 34.5–42.0 mph)
{{convert|148|+/-|10|pc|ly|disp=number}}          480 ± 33
                                                  483 ± 33

I'll upload the code to the sandbox, but it will be a while longer before I get a chance to finish checks. Johnuniq (talk) 10:44, 20 December 2013 (UTC)

Unit in /extra not accepted in "outlist"

A. We have the nice feature of what I call "outlist":

  • {convert|65|kg|lb stlb}} → 65 kilograms (143 lb; 10 st 3 lb)

B. Unfortunately, a new unit in convert/data/extra cannot be in such an outlist:

  • {convert|65|kg|LB}} → 65 kilograms ([convert: unknown unit]) -- OK, "LB" is in /extra at the moment; an lb test variant
  • {convert|65|kg|lb stlb LB}} → 65 kilograms ([convert: unknown unit]) -- LB not recognised in the outlist
More on the outlist

C. I have a useful usage of the outlist this way (details when requested):

  • {convert|25|C|C F K}} → 25 °C (25 °C; 77 °F; 298 K)

D. It shows another rounding issue, possibly temperature-related (no urgent action requested; just to have it noted for now):

  • {convert|90|K|C F K}} → 90 K (−183.2 °C; −297.7 °F; 90.0 K)
-DePiep (talk) 13:43, 18 December 2013 (UTC)
I noticed this issue when trying LB with stlb. I've fixed it, but have not uploaded yet. It's not the new "LB", it's the fact that when I quickly added the ability to have user-defined output combinations, I made it more restrictive than necessary. The problem is that stlb was blocked by the restriction because it consists of more than one unit. At any rate, a one-word change allows "multiples" like stlb which is really a single unit. It will be live when module:convert is next updated.
Temperatures have some extra rounding precision to account for the fact that when people talk about, for example, 100°F they generally mean a value very close to 100 (and certainly not 99 or 101). So, yes, I guess that means that "90" as input ends up as "90.0" on ouput. Bit silly, but possibly an unforeseen consequence of the default rounding. Johnuniq (talk) 20:41, 18 December 2013 (UTC)
  • Using Convert/show2 cannot handle new unit-codes: The whole concept of the wp:wrapper templates is to piggyback extra functionality atop the latest revision of Convert features. So {convert/show2} should work with new unit-codes:
{convert |65|kg|lb LB}}          - 65 kilograms ([convert: unknown unit])
{convert/show2|65|kg|lb|LB}} - {{convert/show2 |65|kg|lb|LB}}
I will have to rework {convert/show2}. As long as users have the wrapper templates, then they will have much greater functionality, in total. -Wikid77 (talk) 19:54, 20 December 2013 (UTC)

nbsp missing on primary unit?

I just noticed in an article that the number and primary unit breaks. To show this, placed some conversions into a table with a fixed width and hopefully this will work for most people.

6 miles (9.7 km)
some 6 miles (9.7 km)
some 6 pounds (2.7 kg)
some 6 miles

Inspecting the html code for the first row, I get 6 miles (9.7&nbsp;, &NonBreakingSpace;km); I would expect 6&nbsp;, &NonBreakingSpace;miles (9.7&nbsp;, &NonBreakingSpace;km) Edgepedia (talk) 14:47, 20 December 2013 (UTC)

Good point. This has been discussed for years, and we were beginning to use &nbsp when less than 2,000 in some cases, for no-wrap up to "1,999&nbsp;miles" but allow wrapping of longer numbers, such as "87,000 kilometres" rather than join both which leaves a 17-character gap when wrapped, together, at the end of the prior line. Ideally, the wrapping should consider the decimal digits, to allow wrapping of "2.123456789 feet". Many conversions use 2-digit numbers, and so the no-wrap below 2,000 would improve the typesetting of most conversions. The full unit names would wrap, such as "square miles" in all cases. -Wikid77 (talk) 15:34, 20 December 2013 (UTC)

There have been many long discussion over whether a space or &nbsp; should occur between a number and a unit name. The general view is that full words (and numbers) should wrap, so a space should be used. WP:MOSNUM says to use nbsp between a number and a unit symbol, but that's all it says. Use Special:ExpandTemplates to see exactly what a template outputs. For example: 

{{convert|6|mi}}	   6 miles (9.7&nbsp;km)
{{convert|6|mi|adj=j}}     6&nbsp;miles (9.7&nbsp;km)

The adj=j option ("join") was introduced by Wikid77 and emulated in the module which now implements converts. Options are at Help:Convert. Johnuniq (talk) 20:45, 20 December 2013 (UTC)

Singular fractions

Refactored to use {convert/old}. -Wikid77 08:21, 22 December 2013 (UTC)

One of the major topics left unfinished has been the need to show singular "1⁄2 unit" for fractions below 1.0. This has been implemented in a test version of Convert, shown by "lk=test":

  • {{convert/old |1/2|mi|km|lk=test}} -
  • {{convert/old |7/8|mi|km|lk=test}} -
  • {{convert/old |1+7/8|mi|km|lk=test}} -
  • {{convert/old |9/100|kg|lb|lk=test}}                 -
  • {{convert/sandboxlua |9/100|kg|lb|lk=test}} → 9⁄100 kilogram (0.20 lb)*

There has been nearly universal acceptance for singular "1⁄2 unit" and that should be added soon. -Wikid77 (talk) 21:14, 29 November 2013 (UTC)

  • Fixed 30-Nov-2013 and 4-Sep-2011: The display of singular fractions, "1⁄2 unit" had been resolved, over 2 years ago, and User:Jimp created Template:Convert/plural (4 September 2011) to show singular fractions when "disp=or" and for "abbr=out". I added similar logic, on 30 November 2013, to show "1⁄2 foot" as the default format, or with "abbr=in" as matching the results of {convert/plural} from 2011. Even years ago, the general consensus was to show singular fractions below 1.0, but a search of common text in Google seemed to prefer plural decimals under one, such as "0.5 inches" in many cases, as the typical style for decimals, contrary to singular fractions. The default precision, as 2-decimal "1⁄2 foot(0.40 km)" reflects the 2-digits of 0.25 as being one-fourth unit, but the default precision increases to 3-decimal level for "1⁄100". -Wikid77 (talk) 04:11, 3 December 2013 (UTC)

Disp=Table not working so well

I have a delicious table at Daihatsu E-series engine, but conversions with three values using disp=tablecen are coming out wonky. Here is an example of the current state:

hm
300 296 221

That semicolon should have made another column instead. Help please!  Mr.choppers | ✎  15:38, 22 December 2013 (UTC)

temporarily fixed with this edit, we can change this back to convert once the module is updated. Frietjes (talk) 17:28, 22 December 2013 (UTC)
Thanks.  Mr.choppers | ✎  23:15, 22 December 2013 (UTC)
Thanks for what is probably the nicest ever bug report at this page! (I trawled the archives while planning for the module, and some very obnoxious editors have been here in the past.)
I have never encountered this issue, but the fix was simple and is now in the module on my system. It will be included in the next upload to the sandbox, but the way things are going I suppose it will be early 2014 before the module is updated. Johnuniq (talk) 03:11, 23 December 2013 (UTC)

Proposed Lua advance version Convert/+

This reformatting of 554,000 pages (over 10 or more days) is a cumbersome, demoralizing problem which could be sidestepped by having a 2nd version of Lua Convert as Template:Convert/+ (or such) to run a tested, advance Lua version in pages where a new feature was needed soon, as installed from a well-tested new version, as Module:Convert/+ (or such). Then there would be less push to install an updated original version, system-wide, just to get new features into some articles. Instead, the {convert/+} would "instantly" carry some various articles into the immediate new features, days or weeks ahead of being put into the tediously tested base version, Module:Convert. We certainly do not want to risk 3 consecutive, oops edits to Module:Convert just because there was a rush to have new features (in some articles). Hence, the Convert/+ advance fork would be the proposed future version of regular Lua Convert, but might go totally wrong in live release yet quickly fixed for the few hundreds or thousands of pages which had been using it. The wp:Job_queue(s) reformat as 500-page groups, and if used <1,000 pages, then Convert/+ would trigger instant reformatting of all 999 pages without queuing. The wp:CS1 cite templates had 23 forks which provided similar "pre-release" of new features into just a few hundred live articles, before wider update of {cite_web}. Otherwise, the one-version Lua Convert presents a demoralizing situation, burdened by the fear of a wrong change going wild when triggering another 10-day reformatting. So, {convert/+} would allow easy testing of new features, weeks sooner, without all the worries or frustration.
Post below: "#Opinions of Lua advance version". -Wikid77 14:36, 19 December 2013 (UTC)

Recap: When code is changed in {{convert}} or its module, 550.000 pages must be reformatted, once. That is aka "cleaning the cache"; they are put "in the job queu". It may be 10 days before this queu is done indeed (when passively), but who cares? Every page opened is shown up to date. Apart from Wikid77, I have heard no one for whom this would be a problem. Be sure, that if there was troublesome behaviour or bad server effects, people who know about this would have said so. Actually it is the other way around: the careful process as pursued by Johnuniq this year did much to even reduce such loads. Simply, Wikid77: the process is OK to very OK, not "demoralizing". There is no argument at all from the queu to change our way of working here. Wikid77 should know by now.
From now on I will oppose each and every suggestion by Wikid77 that is based on this "550.000" argument. Because the argument is not true. That is a sorry for companion arguments that might be useful, but are drowned by the big wrong one used. Enough. -DePiep (talk) 15:06, 19 December 2013 (UTC)
You claimed, "Every page opened is shown up to date" but that is totally false because most users will see a cache-copy of the previously reformatted page since the last edit or job-queue reformat, which would contain out-dated results from the old revision(s) of the templates. Only users with custom formats in Special:Preferences, such as default image-size not 220px, would see a live-reformatted page. For example, the recent update to Template:Convert/numdisp ran 8 days of reformatting 510,000 pages before updating the one page where the error "&minus;4" showing "−4,000,000" had been noticed. I regret that you do not understand the weeks of delay when reformatting over 550,000 pages, but that doesn't make the problem "not true". As for, "people who know about this would have said so" well I have said it many times, over many years. The very fact that the wp:Job_queue(s) show a backlog of millions for days will lead to a conclusion that extra reformat jobs will mean a longer wait. Plus, when the queue backlog shows 12.5 million, and there are only 4.3 million articles plus some thousands of related pages, then double re-reformatting of pages is an obvious conclusion. So, you do the math, again, and re-think the consequences. -Wikid77 (talk) 16:32, 19 December 2013 (UTC)
No. A backlog can exist in the linklist, not on the page itself. No content page is shown with outdated formatted templates. -DePiep (talk) 16:01, 20 December 2013 (UTC)
Most users (>95%) will see the old results in the page's cache-copy. Check your Special:Preferences, and reset to the original settings, then look at an unreformatted page and note the old results still show from the old templates. A cache-copy is processed within 1/3 second; otherwise, a longer page runtime (such as 1-14 seconds) means Special:Preferences triggered a personal copy for your viewing. -Wikid77 (talk) 20:06, 20 December 2013 (UTC)
I stand corrected. Wikid77 is right in that WP serves the old pages. (I am flabbergasted too). That leaves only the remarks "a cumbersome, demoralizing problem", "risk 3 consecutive, oops edits to Module:Convert", and my "Apart from Wikid77, ... no one for whom this would be a problem". With this the argument not a wrong fact, but still wrong in declaring it a "problem". -DePiep (talk) 13:28, 22 December 2013 (UTC)

Opinions of Lua advance version

The 550,000-reformat argument is true, as I noted, for most users with default Special:Preferences. -Wikid77 08:12, 22 December 2013 (UTC)
As I corrected myself above: the argument is not wrong as a fact; it is wrong in declaring it a "problem". It is not a problem. -DePiep (talk) 13:28, 22 December 2013 (UTC)
The Lua Convert is already a fork of Convert/old, which has different features. -Wikid77 08:12, 22 December 2013 (UTC)
How can a delay of 13-day reformat to show a new feature, versus a 5-minute install be a non-issue? -Wikid77 08:12, 22 December 2013 (UTC)
  • Disagree with above comments, but still Opposed The general idea seems to be to use a new version of convert on a small, but significant subset of live pages that use the convert script before rolling it out to all of the other pages (and presumably after testing it on a standard set of regression testing). Especially given the large number of pages that use the script, this does not seem to be a terrible idea, nor does it constitute forking in any way. However, given that the convert script is self contained it would be better to do the opposite, cull converts from live pages and test them under a test harness on non live pages, and only roll it out when the chances of major failures are found to be vanishingly unlikely.GliderMaven (talk) 03:42, 22 December 2013 (UTC)
Well, then how would new features, or minor adjustments, be released every day, without triggering the reformatting of all 554,000 pages every day? -Wikid77 08:12, 22 December 2013 (UTC)
If they're minor it doesn't matter that much. Note that 554,000 can't be retriggered every day; if they're already on the queue they don't get put in twice, only the ones that have already been been recached get added, a much smaller number. So at the limit the more often you edit 'convert' the less reformatting happens; which is why wikipedia is using a queue.
New features aren't a problem either; in that case the article pages using it will be edited, and then they jump the queue and are automatically purged and recalculated when they're accessed. And occasionally you want to manually purge individual pages.
Overall, it's not a total non issue, but it mostly is, and you certainly wouldn't want to break a whole bunch of pages, that's why you test before going live.GliderMaven (talk) 11:45, 22 December 2013 (UTC)
The flaw in that line of reasoning is treating {convert/+} as a one-time release, for a few articles, but also consider how {convert/+} could be used inside a shared infobox (or wp:wrapper templates) which would be used hundreds of thousands of times, with cache invalidated by several quick updates to {convert/+}, rather than hand-editing of all pages which use the shared infobox. The plan is to use {convert/+} as a long-term advance release, in hundreds/thousands of pages (or later reduced), but far less than 554,000. It is the wiki-edit concept of rapid live release, with other people giving feedback or better ideas or removing the instance, not exhaustive pre-testing as formal acceptance testing. Meanwhile there would be no release which triggered 554,000 reformats, but only updates to {convert/+} for while. Do you see the differences by release into one infobox, versus hand-editing a few pages to reformat with a minor new conversion feature? I have been dealing with multi-version templates and timing of JQ performance for years. -Wikid77 16:40, 24 December 2013 (UTC)
Thanks for explaining these JQ details, in various posts, GM. -DePiep (talk) 08:28, 23 December 2013 (UTC)

Status of Lua Convert reformat and leftover subtemplates

Reformatted 95% by 14th day. -Wikid77 17:09, 24 December 2013 (UTC)

The reformatting seems beyond 75% finished. I have been estimating the progress of reformatting all 554,000 {convert} pages, and it seems over 40% had completed after 7 days, but still many WhatLinksHere show use of markup-based Convert with (Template:Convert/LoffAoffDbSoff, etc.). Meanwhile, some reformatted pages, showing Module:Convert, also link to old subtemplates, perhaps from navboxes. In particular, page Asteroid (edit | talk | history | protect | delete | links | watch | logs | views) has a combination of Lua Convert and markup subtemplates (which remain even after edit-preview):

However, notice how {convert/ft}, typical with /m metres, is missing from the list. These "leftover subtemplates" are a quite minor issue, so just beware how they make the reformatting seem to be unfinished in various articles which are, in fact, using Lua Convert. The gargantuan Module:Citation/CS1 triggered reformatting 2.2 million pages, on 14 December 2013, but edited 3 times (3 × 2.2 = 6.6 million reformats?). As I understand the competing jobs in the wp:Job_queue(s), they are interleaved (as batches of 500 pages each) among the prior jobs in the queue(s). Otherwise, it seems Lua Convert would reformat within 9 days(?). I wish we had a "cancel reformat" button, and could then resubmit an updated revision, after just a few days of results, without piling 554,000 reformats atop the prior 554,000 reformats. -Wikid77 (talk) 13:55, 19 December 2013 (UTC)

The Asteroid example is due to the use of the {{Val}} template, which currently uses some of the convert subtemplates. -- WOSlinker (talk) 14:29, 19 December 2013 (UTC)
  • Still reformatting on 14th day: The reformatting of Lua {convert}, begun at 02:15 on 11 December 2013, has stretched into the 14th day (24 December), as seen by thousands of pages for Special:WhatLinksHere/Template:Convert/track/adj/. The transclusion count has been long outdated, actually below 8,500 pages when showing "122,255" as transcluded, but the listed pages are indeed still linked (although far fewer than 122,000). See transclusion information report:
https://en.wikipedia.org/w/index.php?title=Template:Convert/track/adj/&action=info#mw-pageinfo-transclusions
Some other large Lua modules had been updated during the reformatting, including Module:Citation/CS1, used in 2.3 million pages. -Wikid77 (talk) 17:09, 24 December 2013 (UTC)

Switch convert to use module

Lua Convert reformatted in 17 days. -Wikid77 16:51, 27 December 2013 (UTC)

Per the above RfC and timing discussion, please copy Template:Convert/sandboxlua to replace Template:Convert in order to implement convert using Module:Convert.

The template to be copied is /sandboxlua because Template:Convert/sandbox has parameters for running the sandbox version of the module. Johnuniq (talk) 02:10, 11 December 2013 (UTC)

Done.
—Trappist the monk (talk) 02:17, 11 December 2013 (UTC)
@Trappist the monk: Thanks. I should also have asked for the modules to be template-protected as they are now widely used: Module:Convert and Module:Convert/data and Module:Convert/text (but not Module:Convert/extra as it will not be widely used and is available for editors to add a new unit). Johnuniq (talk) 02:31, 11 December 2013 (UTC)
Done.
—Trappist the monk (talk) 02:57, 11 December 2013 (UTC)
  • Watch for stragglers after 10-15 days: In past massive template reformats which changed links, some pages did not relink (perhaps due to write lock to hit a "relink conflict") while reformatting all related pages. So, after 10-15 days (21-26 Dec.), look for WhatLinksHere to have some stuck pages, such as for Special:WhatLinksHere/Template:Convert/fathom, which had 149 links today (11 December 2013), and should drop to only talk-page links during the next 2 weeks. Straggler pages can be cleared by null-edit, to relink without saving revision. Also note: transclusion counts have been run on mirror-database servers and might be 2-3 days outdated, compared to the live WhatLinksHere, but those mirror transclusion counts of subtemplates should begin to lower within 3-4 days. If other mass reformats have also been submitted meanwhile, then the Lua {convert} reformatting might run for 3 weeks (or more). The average {convert} usage has been 3 per page, among ~554,000 pages. -Wikid77 07:19, 11 December 2013 (UTC)
A lot of other templates use template:convert subpages directly. It takes time for the "what links here" to be updated, because it is done through the WP:Job queue. Christian75 (talk) 18:28, 12 December 2013 (UTC)
  • Release of first Lua Convert reformatted by 27 December 2013: Following the initial release, at 02:15, 11 December 2013, now over 99.9% of related pages seem to have been reformatted, and have delinked the subtemplates which were used by the prior markup-based {convert}, such as {convert/track/abbr/}, with mostly talk-page or user-page links remaining:
                          • Special:WhatLinksHere/Template:Convert/track/abbr/
    Some wp:wrapper templates might still use the Convert subtemplates, such as when the positional wrapper Template:Convinfobox has called {convert/<unitcode>...}. At this point, I think null-edits (because "?action=purge" will not relink templates) for any stragglers could be performed since the 17-day reformat has been effectively completed for all major pages. -Wikid77 16:51, 27 December, 08:13, 28 December 2013 (UTC)

Fractions in output

The module accepts fractions in input:

  • {convert|+2+3/16|in|mm}} →+2+3⁄16 inches (56 mm) -- nice

In nonlua code there exists an option to write fractions in the "output" (i.e., the calculated measure):

  • {height|m=1.77|frac=16}} → 1.77 m (5 ft 9+11⁄16 in) -- using {{Height/m to ft in}}

It is a very elegant option. It is within {convert} scope to me, so I suggest we consider implying it.

More background
See {{Height/m to ft in}} (edit talk history links # /subpages /doc /doc edit /sbox /sbox diff /test)
Through {{Height}} (100k transc pages), this template is used in 64k pages (=all metre-to-ft&inch usage). Not all may use the fractions option though. Since this option is not in the module, {Height} can not be changed into the module (there may be other reasons too).
There is also unused, but similar {{Convert/ftinfrac}}.
Usage: I encountered inch fractions as defined in source or as being iconic in {{RailGauge}}. (Sidenote: there may be other reasons not to use calculated fractions in there, e.g., being unscaled definitions).
To consider
Don't know if 1+6⁄8 should be turned into 1+3⁄4. Opt-in or opt-out?
The complete option could be: |show_fraction_when_in_inch_and_feet=on (whether in first or later positions of output).
Or: |show_the_calculated_measure_in_frac=on; |show_the_metre_units_in_frac=on (how to point units in here at all).

-DePiep (talk) 11:38, 21 December 2013 (UTC)

Note also that some articles use {{frac|1|2|3}} → 1+2⁄3 and some use {{sfrac|1|2|3}} → ⁠1+2/3⁠.  Stepho  talk  14:47, 21 December 2013 (UTC)

As mentioned, input fractions are supported; examples:

  • {{convert|1+2/3|in|mm}} → 1+2⁄3 inches (42 mm)
  • {{convert|1+2//3|in|mm}} → 1+2/3 inches (42 mm)
  • {{convert|1+2/3|in|mm|spell=in}} → one and two-thirds inches (42 mm)

Output fractions are nearly ready as I have been working on them for a few days after seeing them used in couple of places, and per the discussion on hands above (which sometimes wants output fractions). Following are some examples; output is fixed text copied from my system.

  • {{convert|0.12|m|in|frac=4}} → 0.12 metres (4 3⁄4 in)
  • {{convert|0.12|m|ft|frac=4}} → 0.12 metres (1⁄2 ft)
  • {{convert|0.12|m|in|frac=-4}} → 0.12 metres (4 3/4 in)
  • {{convert|0.12|m|ft|frac=-4}} → 0.12 metres (1/2 ft)

Output fractions are reduced per these examples:

  • {{convert|160.02|cm|ydftin|frac=64}} → 160.02 centimetres (1 yd 2 ft 3 in)
  • {{convert|161.9|cm|ydftin|frac=64}} → 161.9 centimetres (1 yd 2 ft 3 47⁄64 in)
  • {{convert|161.925|cm|ydftin|frac=64}} → 161.925 centimetres (1 yd 2 ft 3 3⁄4 in)

When an output combination is specified, output fractions are not applied to any unit which takes an SI prefix.

  • {{convert|161.9|cm|ydftin m|frac=64}} → 161.9 centimetres (1 yd 2 ft 3 47⁄64 in; 1.619 m)
  • {{convert|161.9|cm|m|frac=64}} → 161.9 centimetres (1 5⁄8 m)

Notice the ugly-but-convenient tricks to get a horizontal fraction bar: for input, use two slashes; for output, specify a negative frac (where the hyphen is supposed to represent a horizontal bar). Johnuniq (talk) 01:01, 22 December 2013 (UTC)

So I asked for something you already had in the pipeline. I am :-). -DePiep (talk) 13:03, 22 December 2013 (UTC)
I thought this was ready and was trying to apply it - I was getting frustrated until I came here and read things more carefully. Looking forward!  Mr.choppers | ✎  23:23, 22 December 2013 (UTC)
Mr.choppers, just to improve our documentation (and prevent frustrations you mentioned): where did you look first, where did you expect to find the answer? -DePiep (talk) 08:33, 23 December 2013 (UTC)
I was just absent mindedly reading this bit while stalking Stepho, and liked the elegance of this method. It was the answer to a question I wasn't asking. Cheers,  Mr.choppers | ✎  08:44, 28 December 2013 (UTC)
  • IIC, the next option is not covered: "show input (source) in fractions"
{convert|5.75|in|m|frac="use 4 for ydinft"}} → 5+3⁄4 in (0.146 m) -- constructed demo
This option needs a number option too, somehow (as we want to use |frac=8).
Usage: don't know importance, but looks consistent to me.
Note on our language: I am not happy with the way we use "out" and "output" in describing {convert}, because the "input" measure is in presented in the output too. When needed to prevent misunderstanding, I'll start using "source" for the input values. -DePiep (talk) 09:25, 23 December 2013 (UTC)
  • Parameter overload. The whole |frac= options for the visual result has multiple dimensions: 1. which nominator to use, 2. which units to apply it to, 3. which formattings, like with horizontal-or-slash and reduce y/n. These dimensions are generally independent (-ly to be set), ultimately. It would be going backward to fold these into a single parameter setting, imo. This is for future considerations wrtt parameter overload. -DePiep (talk) 09:25, 23 December 2013 (UTC)

Proposals

  • Ranges should show differing results: The prior updates for auto-adjusting of range precision, now in Template:Convert/old, will automatically increase precision of close amounts, to differ in results:
  • {convert/old |43|-|45|lb |kg }}           -
  • {convert/sandbox|43|-|45|lb|kg}}       - User:Wikid77/Template:Convert/new
  • {convert/old |890|-|891|lb |kg }}       -
  • {convert/sandbox|890|-|891|lb|kg}}   - User:Wikid77/Template:Convert/new
  • {convert/sandbox|105|-|106|F|C}}         - 105–106 °F (41–41 °C)
  • {convert/sandbox|500|-|500.04|lb|kg}} - 500–500.04 pounds (226.80–226.81 kg)
  • {convert/old |500.03|-|500.04|lb |kg }}     -
  • {convert/sandbox|500.03|-|500.04|lb|kg}} - 500.03–500.04 pounds (226.81–226.81 kg)
Hopefully, during the next 2-3 weeks, the Lua Convert can be updated to also restore this auto-adjusting of range precision, which several users had requested (for years) but now lost during early transition to Lua. I agree this has been a horrific awkward time, and Lua Convert was rushed into release with these known problems, so I proposed a {convert/+} advance version of Lua Convert to offer new features (or bugfixes) without waiting another 15 days to reformat all 554,000 pages to get the bugfixes or new options. -Wikid77 (talk) 15:59, 24 December 2013 (UTC)
Argh. You started õut so promising here, but in the end ... spoiled. -DePiep (talk) 17:37, 24 December 2013 (UTC)
Recall Lua option "near=5" is already rounding to nearest 5:
  • {convert|34|m|ft|near=1}} - 34 metres (112 ft)*
  • {convert|34|m|ft|near=5}} - 34 metres (112 ft)*
  • {convert|34 |m |ft |near=25 }}          - 34 metres (112 ft)*
  • {convert/sandbox |34|m|ft|near=25}} - 34 metres (112 ft)[convert: invalid option]
So generalize "near=n" to handle 0.5, 8, 25, 50, etc. -Wikid77 17:21, 25 December 2013 (UTC)
If |round= can do the job without prohibiting other round-options (i.e., |round= has a one-dimensional meaning; no overload), that should do it. We can declare |near= deprecated after some time. -DePiep (talk) 12:39, 28 December 2013 (UTC)
  • Add more range symbols: The range words used in Template:Convert/old had redirects, such as for unicode mdash ("—"):
    • {convert/old |43|—|49|lb |kg }}       -
    • {convert/sandbox|43|—|49|lb|kg}}   - User:Wikid77/Template:Convert/new
    • {convert/old |55|&plusmn;|2 |m }}       -
    • {convert/sandbox|55|&plusmn;|2|m}}   - User:Wikid77/Template:Convert/new
Many people have used mdash ("—") in text, and hence use in ranges could be expected. -Wikid77 17:21, 25 December 2013 (UTC)
Using an m-dash is not MOS. Instead of allowing & supporting this mistake, these dashes shuold be edited out in the text. They are tagged & categorized. -DePiep (talk) 10:42, 26 December 2013 (UTC)
  • Treat plus/minus temperatures as relative: This has been a problem for years, with temperatures based on 32-degree shift:
    • {convert/old |23|±|4|C |F }}       -
    • {convert/sandbox|23|±|4|C|F}}   - 23 ± 4 °C (73 ± 7 °F)
    • {convert/old |212|±|2|F |C }}        -
    • {convert/sandbox|212|±|2|F|C}}    - 212 ± 2 °F (100 ± 1 °C)
    • {convert/sandbox|2|F-change}} - 2 °F (1.1 °C)
Temperature ranges should be fixed for "±" to show ±2 °F as ±1.1 °C, as the relative change, which I have fixed in {convert/old} by treating 32 as 0 when the range is +/-. -Wikid77 17:21, 25 December 2013 (UTC)
Thanks for pointing out that ± was broken with temperature units. I have fixed that, although the rounding needs more thought:
  • {{convert/sandbox|23|±|4|C|F}} → 23 ± 4 °C (73 ± 7 °F)
  • {{convert/sandbox|212|±|2|F|C}} → 212 ± 2 °F (100 ± 1 °C)
  • {{convert/sandbox|50|+/-|50|C}} → 50 ± 50 °C (122 ± 90 °F)
  • {{convert/sandbox|5|±|5|to|95|±|5|C}} → 5 ± 5 to 95 ± 5 °C (41 ± 9 to 203 ± 9 °F)
Also, the module now accepts a range with "&plusmn;", although I don't think it is used. I'm inclined to agree with DePiep about em dash—that is not needed.
Re "round" and "near": I introduced |round=each when I found that the new default method of handling default precision in ranges was not always desirable. It seemed rather lonely with only "each" being available for the new "round", so I made |round=5 and |round=25 work because they look sensible, and the change was very minor. Let's think about "near" later—it's just an experiment and is probably not used. As several people have said, a significant reworking of the convert syntax would be worthwhile, but that's not going to happen soon.
I'm thinking about the "Ranges should show differing results" issue. Johnuniq (talk) 21:56, 26 December 2013 (UTC)
  • Auto-correcting for common mistakes: People have been fixing recent unit-mismatches (watching categories), rather rapidly, and that gave the illusion that "no one" had miscoded conversions yesterday and saved the invalid parameters. However, the reality seems to be where people write {convert} with invalid parameters, save the page, and then only later, they or someone would quietly fix the {convert} parameters and prolong the illusion of smooth operation. That fix-it-later scenario probably explains why, among 1.6 million {convert} calls, there were only a few hundred invalid parameters. The following are common:
· foot or feet is used and should auto-correct as "ft".
· km is used with sqmi or sqft and should auto-correct as "km2".
· m is used with sqmi or sqft and should auto-correct as "m2".
The total oblivion, to proofreading for warnings, is not a matter of newcomers unaware nor "too-small" warning messages, but rather many of us experienced editors also forget to proofread, distracted by many details, and hit "Save-page" too soon. Hence, even User:BracketBot often notifies expert users who should proofread first. However, with auto-correction, then perhaps 90% of miscoded units would be overridden to show valid conversions, and the "[fix unit]" could wait until also editing for other issues as well. That is why {{convert/old|95|sqft|m3}} will auto-adjust to show "" and the unit-codes for "tons" and "tonnes" to default had been added. -Wikid77 (talk) 05:59, 27 December 2013 (UTC)
  • Unit-mismatches or Script errors: During the talk about dpi (dots per inch), there were some unit-mismatches which generated red "Script error". The status is now:
  • {convert |1.2 |tsfc}}   = 1.2 lb/(lbf⋅h) (34 g/(kN⋅s))
  • {convert |1.2 |tsfc |m/s }}         = 1.2 lb/(lbf⋅h) (29,000 m/s)
  • {convert/sandbox|1.2|tsfc|m/s}} = 1.2 lb/(lbf⋅h) (29,000 m/s)
  • {convert |200 |dpi |m }}         = 200 DPI (0.00013 m) [should mismatch]
  • {convert/sandbox|200|dpi|m}} = 200 DPI (0.00013 m) [should mismatch]
Alternatively, parameters "dpi|m" could auto-correct as "dpi|dpcm" to dots-per-centimetre as a common unit. There was a claim above, "dots are not units" and well, not SI units of weight/mass or volume (etc.), but dots are units of counting, similar to "items per inch" or "inhabitants per square mile" even though inhabitants are not SI units, nor all the same size. Anyway, we need to fix any Script-error loopholes in unit mismatches. -Wikid77 (talk) 09:14, 28 December 2013 (UTC)
I've just posted below about an update to the sandbox modules. Regarding the script errors, my comment above starting "Putting undocumented and unsupported fields into convert/extra may break the module" explains the issue (for when that's archived, I'll mention that it is in section #DPI and dots/cm and micrometres per dot and is dated "01:06, 15 December 2013"). Johnuniq (talk) 11:41, 28 December 2013 (UTC)

Template:Convert/per for inverse units

New Template:Convert/per is a wp:wrapper template using Lua {convert} to handle generic "items per unit" with optional "out=" for related item name. Examples:

  • {convert/per |567|dogs|sqmi}}         - 567 dogs per square mile (219 dogs/km2)
  • {convert/per |1|dog|km2|out=dogs}} - 1 dog per square kilometre (2.6 dogs/sq mi)
  • {convert/per |1|[[pygmy elephant]]|acre|out=elephants}} - 1 pygmy elephant per acre (2.5 elephants/ha)
  • {convert/per |3|cats|sqft|lk=in}}     - 3 cats per square foot (32 cats/m2)
  • {convert/per |14|fish|USqt|L}}        - 14 fish per US quart (15 fish/L)
  • {convert/per |9|dots|in|ly|abbr=off}}   - 9 dots per inch (3.4×1018 dots per light-year)

The formatting parameters are based on {{convert/f}}, such as "x1=gold" or "near=25" or such:

  • {convert/per |3|fish|usgal|L|x1=gold|x4=partial}}   - 3 gold fish per US gallon (0.79 partial fish/L)
  • {convert/per |7,200|orbital miles|h|s}}        - 7,200 orbital miles per hour (2.0 orbital miles/s)

Note how Convert/per is limited to conversions of just the per-unit part, whereas multi-unit conversions should be done with regular {convert} by slash unit-codes, such as "m/s" to "ft/h". However, note the per-inverse of "m/s" is effectively seconds/metre (s/m), giving results as duration, as time-per-distance, which is likely too confusing in {convert/per}:

  • {convert/per |7,200|units|mph|km/h}}   - 7,200 units per mile per hour (4,500 units/km/h)

Anyway, any of the hundreds of current unit-codes can be used in combinations, but limited to whatever unit-mismatch restrictions as when used as non-inverted units. -Wikid77 14:19, 28 December 2013 (UTC)

RfC for spacing mixed numbers

Notice of central discussion affecting {convert} and  {convert/old}.

Again, people have noticed unusual spaces inside mixed numbers (space before fraction part), and I have tagged the discussion as RfC:
              • WT:Manual_of_Style/Dates_and_numbers#Spacing_of_mixed_numbers
This topic of typesetting fractions, possibly hiding a space within a span-tag, crosses into technical means to format fractions with templates ({{frac}}, {{sfrac}}, {{convert}}, etc.), yet support wp:Accessibility for screenreaders, as a mix of policy/style and technical issues. As an RfC, we can gain a broader, 30-day consensus to settle the issues in all the various facets, now starting early to gather opinions at year-end in 2013. -Wikid77 19:11, 27 December 2013 (UTC)

  • Mixed-number space hidden December 2011: The RfC has confirmed the space with a fraction was hidden as "display:none" over 2 years ago (in {{sfrac}} by dif714), rehidden by "position:absolute; left:-10000px" but a later edit accidentally re-displayed the hidden space as &#32, and now rehidden in {{frac}} as "&nbsp;". However, upcasing the fraction by {uc:} shows "&NBSP" and so the space should use code &#160 as with:
  • {{uc: text {{frac|8|1|2}} }}       - TEXT 8+1&FRASL;2
  • {{uc: text {{smallfrac|8|1|2}} }} - TEXT 8 1⁄2
Consequently, the 2-year technical precedent has been to hide the space which is needed by screenreaders to separate the whole-number and fraction parts, as pre-empting the RfC's issue of recommended style which is likely now to confirm technical use of the 2-year hidden space. -Wikid77 (talk) 13:25, 29 December 2013 (UTC)

Round input

After writing list of longest streams of Idaho several years ago, I've been in constant search for a convert template that can round the input number to the nearest whole number, so that I can save overprecise lengths in the article without displaying the extra digits. I've been using my jury-rigged solution, {{convert/round input}}, in the interim. Today, I came across {{convert/flip}}, which seems to do exactly what I want, but it says it's deprecated in favor of disp=flip. The problem is, Module:Convert can only round the input to one, two, or three decimal points via adj= ri1, ri2, or ri3, not the nearest whole number. Is there any possibility that this functionality could be added to the module? (If there are more pressing issues to attend to, I certainly understand.) Thanks, LittleMountain5 23:40, 12 December 2013 (UTC)

For the module, I often did just enough to emulate the old templates, so only ri1, ri2, ri3 were supported. I just added ri0 to the sandbox, example:
  • {{convert/sandbox|1234.567|km}} → 1,234.567 kilometres (767.124 mi)
  • {{convert/sandbox|1234.567|km|adj=ri0}} → 1,235 kilometres (767.124 mi)
  • {{convert/sandbox|1234.567|km|adj=ri1}} → 1,234.6 kilometres (767.124 mi)
However, you would need more because Special:ExpandTemplates shows the following output:
{{convert/ri|101.168|km}} → <span style="display:none" class="sortkey">7001630000000000000</span>63 mi (101 km)
I have a tentative idea for when the teething problems of switching to the module are resolved, namely that a new template could be created (perhaps Template:Convertf per traditional names like printf), and the first parameter would specify the text wanted for the entire output, with placeholders to show input and output values and units. It could include some input rounding specification. The point of that is a different rounding value could be provided for each input and output, if wanted. In the current system, ri0 applies to all inputs in a range.
After some discussion and testing, if ri0 is useful and desirable, it could go in the main module when that is next updated—there is no timetable for such an update at the moment, but possibly a week or a month. Johnuniq (talk) 00:47, 13 December 2013 (UTC)
Alright, thanks. The only difference between the two is the hidden sort key:
  • {{convert/sandbox|101.168|km|mi|disp=flip|abbr=on|sortable=on|adj=ri0|0}} → <span style="display:none">7002101168000000000</span>63 mi (101 km)
  • {{convert/ri|101.168|km}} → <span style="display:none" class="sortkey">7001630000000000000</span>63 mi (101 km)
If I'm not mistaken, I think {{convert/sandbox}} is producing the error here. It's basing its sort key off of the kilometer value, not the mile value like it should. A problem with the disp=flip/sortable=on combination? LittleMountain5 01:38, 13 December 2013 (UTC)
Yes, the module gets the sort key from the first input value, regardless of whether the display is flipped. There should be no difference in the result, providing all items in a sortable column are converted in the same way—sorting by the number of kilometers should be the same as sorting by the number of miles. The module could use the first output value if disp=flip is in effect, if that was necessary. Using the raw input is simpler for the module code at the point where the sort key is added, but I can rationalize that as a good choice because the output is rounded, and it is conceivable that two rounded outputs might be the same, so basing the sort on the input will give best results. The module uses the raw input for the sort, not the value after rounding. It looks as if convert/f is generating the sort key from the rounded output, although that would make no difference in the vast majority of cases. Johnuniq (talk) 03:05, 13 December 2013 (UTC)
The Idaho list uses a mixture of kilometers and miles, so that method won't work there. Oh well, I'll stick to using /round input for now. (I just changed its sort key to use unrounded values.) Cheers, LittleMountain5 05:16, 13 December 2013 (UTC)
First, let me ask Johnuniq not to even suggest introduction of variants like {convertf}. If a fork would change the documentation (parameters & behaviour), it is future horror for the editor. I hope we can address this later, right before such a proposal would get substance.
Then the /flip. ({convert/flip} has an option to round the input' value, whatever output position it ends up). This feature is not present in module:convert yet. So to be correct, I'll remove the "deprecated" tag (that I had put on) for now. This is one of the {convert/x} examples that needs coding attention. -DePiep (talk) 06:30, 13 December 2013 (UTC)
@LittleMountain5: I see what you mean. I have added a note to my "think about later" list.
@DePiep: I was only thinking of trying a new template as an experiment to see if my very partially thought-out idea would be useful. I would want people to try a new system for two or more weeks and provide ideas. After that, if thought to be worthwhile, we could discuss integrating it into the existing template. I mentioned it merely to indicate that I'm not satisfied with certain aspects of the current convert, but I think improvements would require a new syntax. Johnuniq (talk) 08:55, 13 December 2013 (UTC)
All fine (and who am I to talk like that). Yes, once stable we could rethink the setup. There's also some parameter overload/underload. -DePiep (talk) 09:32, 13 December 2013 (UTC)

@Little Mountain 5: I have implemented a new option that appears to fix the issue you raised. Previously, sortable=on was the only "sortable" option, and as discussed above, the module uses the given input value (first such value if a range) to make the sort key. The new feature is that sortable=out is supported, and it calculates the sort key from the first output value, before rounding. To illustrate, consider 204.386688 km which is 127 mi exactly. The following uses debug=yes to demonstrate that the normally hidden sort key is the same for each of the following converts:

  • {{convert/sandbox|204.386688|km|mi|disp=flip|abbr=on|sortable=on|adj=ri0|0|debug=yes}} → 7005204386688000000♠127 mi (204 km)
  • {{convert/sandbox|127|mi|km|abbr=on|sortable=out|adj=ri0|0|debug=yes}} → 127 mi (204 km)[convert: invalid option]

Or, if preferred for consistency with other values in the sortable table (on my system, the keys are nearly identical, but different due to a rounding difference, but they are the same here):

  • {{convert/sandbox|204.386688|km|mi|disp=flip|abbr=on|sortable=out|adj=ri0|0|debug=yes}} → 127 mi (204 km)[convert: invalid option]
  • {{convert/sandbox|127|mi|km|abbr=on|sortable=on|adj=ri0|0|debug=yes}} → 7005204386688000000♠127 mi (204 km)

Please give the new option a workout and report any problems. In a week or two, the sandbox will be used to update convert, and that will make the new option available using {{convert}}. BTW, since sortable=out is now supported, sortable=in also works and is equivalent to sortable=on. Johnuniq (talk) 10:37, 29 December 2013 (UTC)

I updated round input's sandbox to use the new parameters, and it seems to work great. Thanks! One last question: Why is the round input option ("ri0") part of the "adjective" parameter? I know that it has been that way since before the module was implemented, but I just find it odd. Maybe something like |ri=number would be better? Just a thought. LittleMountain5 01:08, 30 December 2013 (UTC)
Thanks for checking. The system of templates used before the module needed to restrict some option names because of the techniques used to invoke subtemplates (extremely clever techniques, btw). I imagine that those factors influenced the choice. I do not want to make unnecessary changes to the syntax at this stage because the whole set of options should be carefully considered in order to decide whether a better system might be introduced, and even a sensible variation, such as your suggestion, might lead to a desire to continue support for something when a better method was devised. Johnuniq (talk) 02:28, 30 December 2013 (UTC)
How interesting: I just noticed that the "but they are the same here" comment just above no longer applies. When I first previewed then saved that comment, the sort keys were the same, but now they are slightly different. This page must have been rendered by a different server. Johnuniq (talk) 02:32, 30 December 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_December_2013&oldid=1255170384"