Module talk:Convert

This is an old revision of this page, as edited by DePiep (talk | contribs) at 22:35, 19 September 2013 (Before going live: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Latest comment: 11 years ago by DePiep in topic Before going live

Notes

This module provides an implementation of {{convert}}. See the documentation.

Usage examples:

  • {{convert/sandboxlua|5.2|m|ftin}} → 5.2 metres (17 ft 1 in)
  • {{convert/sandboxlua|5+3/8|in}}5+38 inches (140 mm)
  • {{convert/sandboxlua|1|yd|2|ft|3|in|hand}} → 1 yard 2 feet 3 inches (15.3 hands)
  • {{convert/sandboxlua|60|x|120|m|ft}} → 60 by 120 metres (200 ft × 390 ft)
  • {{convert/sandboxlua|1|e12BTU/cuft|e9kJ/L|lk=on}} → 1 trillion British thermal units per cubic foot (37×10^9 kJ/L)

The testcases show good agreement between the templates and the module. There are some minor rounding and other differences, and the only significant disagreements appear to be problems in the templates. Substantive differences occur at:

  • energy2: different default output for in.lbf
  • energypervolume: template problems
  • exhaustemission: template problem
  • length2: different micro sign (should be "µ" U+00B5, not "μ" GREEK SMALL LETTER MU U+03BC)
  • mole: different micro sign
  • power: calorie disagreements
  • time: module cannot handle unit horse year (unit not used)
  • torque: template problems and minor differences
  • volume: template hectolitre problems
  • misc: module cannot handle units note, spanner, wrench (units not used)
  • options: template problems and minor differences
  • options2: template problems and minor differences
  • spell: minor differences

The module appears to correctly implement the main features of the template. There are some minor disagreements concerning rounding of results, and some units and options have not yet been implemented. More testing is needed. Johnuniq (talk) 10:52, 26 April 2013 (UTC) Updated 09:56, 19 July 2013 (UTC)Reply

Discussion

Some interesting performance challenges exist. The "NewPP limit report" in the html source for this test page says "Lua time usage: 0.295s". Johnuniq (talk) 09:35, 19 February 2013 (UTC)Reply

presuming that a page that requires data conversion might require many of them, and consideing the sheer size of Module:Convert/data, you might want to look at the mw.loadData documentaion and see if you can use this to improve performance. peace - קיפודנחש (aka kipod) (talk) 16:45, 2 March 2013 (UTC)Reply
Mentioned at http://test2.wikipedia.org/wiki/User:Johnuniq -- WOSlinker (talk) 17:13, 2 March 2013 (UTC)Reply
Thanks, but this page is a little out of date, and I will update it with the info that WOSlinker linked to. My comment about "performance challenges" was written when I had not absorbed the fact that some testcase timeouts were due to use of frame:preprocess. It actually looks as if Module:Convert is reasonably fast, although I haven't yet hammered it. In my sandbox, there are 122 calls of {{convert/sandboxlua}}, and the HTML source shows the Lua time usage is 0.348s (2.8 ms per call). That makes me think that Lua is fast enough even with the current bloated modules. Nevertheless, I'm thinking of some ways I could improve performance and will update the "Plans" section above with info, possibly within a few hours. Johnuniq (talk) 04:08, 3 March 2013 (UTC)Reply

I've removed the plans as they were obsolete. Also, while the testcase pages require a significant time to render, the convert module appears to be sufficiently fast, so there is no reason to look for ways to speed it up. I now have 1689 calls in my sandbox, and the Lua time usage is about 1 millisecond per convert. There is a per-page overhead, and it looks like a small number of converts takes around 40 ms total. Johnuniq (talk) 10:52, 26 April 2013 (UTC)Reply

Status?

I'm curious what the status is here, and when you might hope to be ready for deployment, etc.? Dragons flight (talk) 02:13, 6 June 2013 (UTC)Reply

Yes, I've been wondering that too! I believe there are no significant problems: there are some minor rounding differences between the outputs from the template and the module, and some klunkiness where I'm not happy with the result of some combinations of options, but those same options cause the template to fail, so I do not know of anything significant. However, I've still been doing large refactoring, and I need to wait a week after I decide to stop that before moving towards deployment. The item currently at the top of my todo list is the fact that Unicode minus ('−' U+2212) is accepted with the precision (as in {{convert|123|mi|km|−2}}), and I'm wondering whether to support that. The module accepts Unicode minus and − with the input value, but the function for that does a bunch of other stuff so I would need to replace a simple tonumber(x) with yet another function. I'll also spend a couple of days doing some docs, and see if anything turns up in that process. My guess is that in about a week or two I'll ask for opinions on the next step. Deployment would show other problems, for example, there would probably be quite a few unusual units that I have not implemented. Johnuniq (talk) 03:17, 6 June 2013 (UTC)Reply
Some real-life issues caught up with me, and I haven't done any convert work for the last week and a half. I'm just slowly getting back to it. Johnuniq (talk) 03:36, 21 June 2013 (UTC)Reply
My excuse this week is that I have got into a quagmire trying to adapt the module to work properly on bn: (Bengali Wikipedia; anyone interested may like to follow my links). The unit names and so forth are pretty easy to handle, but lots of the code depends on the numbers using English digits, and it will take some time to work out how best to handle translations. Johnuniq (talk) 03:25, 28 June 2013 (UTC)Reply
It turns out that there is quite a lot of tricky stuff involved. The code should now be ok, but I'm still working with some editors there on getting the unit symbols and names fixed. Johnuniq (talk) 11:16, 5 August 2013 (UTC)Reply

Extra units

Following is a quick test of a new module (Module:Convert/extra) showing how temporary units can be created without significant overhead.

Module:Convert/extra should be transcluded into only those pages which refer to a unit that is not defined in Module:Convert/data. Johnuniq (talk) 11:16, 5 August 2013 (UTC)Reply

I have inserted subst: into the above to freeze the results as they were at the time of this comment. The units were just a temporary experiment (which can be seen in this permalink), and I will remove them soon. Johnuniq (talk) 04:52, 14 August 2013 (UTC)Reply

Error message enhancing

IIC, the default inline error message reads like: Conversion error: Cannot convert "torque" to "energy" (the link is to this talkpage).

Let's compare this with the earlier Module:citation/CS1: |accessdate= requires |url= (help). It links a specific helppage section, and adding the page to (example now on this page).

First, the link to this talkpage is very generic (the same for all errors), and not that helpful (are we supposed to report it, or to fix it?). I suggest it links to a documentation page section, at least as precise as the four categories are. It can also add a link like (talk) to this talkpage indeed.

Second, about that orange color. Note that these messages are inline, warning a reader who most likely does not know what to do with it (there are 100 readers for one knowing editor). Isn't there a less-alarming way of messaging? Put () brackets around it, to separate it from content text maybe? And anyway, it is way too dark as a background color (black or blue text does not contrast enough this way). The same standout effect on a white page is provided by a lighter orange color say #ffcc69, makes easier reading.


Together: (Conversion error (talk): Cannot convert "torque" to "energy") -DePiep (talk) 14:17, 19 September 2013 (UTC)Reply

parameter warnings=true

If I am correct, there is a parameter |warnings= that can be set to |warnings=true (see User:Johnuniq/Using the convert module#Module problems). If set, it should fill Category:Convert invalid option (when an errors occurs).


I cannot check the category filling, because I do not know how to force an "invalid option" error. A hint anyone?

Some tests:

  • {{Convert/sandboxlua|5|km|mi}} → 5 kilometres (3.1 mi)
  • {{Convert/sandboxlua|5|km|mi|warnings=true}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|warnings=false}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|warnings=}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|foo=true}} → 5 kilometres (3.1 mi)*

I find this code confusing, because the parameter name "warnings" is used (checked) twice for apparently opposing values. The logic may be right, but clear it is not.

local function add_warning(parms, mcode, text)
    if warnings then
        if parms.warnings == nil then
            parms.warnings = message({ mcode, text })
        end
    end
end

-DePiep (talk) 15:49, 19 September 2013 (UTC)Reply

Before going live

Before going live we need more testing. All options, and all extremes (for example). Also we better test the border issues (like input '0'). -DePiep (talk) 22:35, 19 September 2013 (UTC)Reply