Module talk:Convert

Overview

This module has been imported to w:en:Module:Convert and further work will probably be there. Johnuniq (talk) 09:16, 19 February 2013 (UTC)

This module implements {{convert}}. Associated pages are:

1. Template:Convert – template which invokes the module
2. Template talk:Convert – template tests
3. Module:Convert – module to convert units
4. Module:Convertdata – module with unit definitions, used by #3
5. w:en:User:Johnuniq/Conversion data – master list of unit definitions
6. w:en:User:Johnuniq/Making the units table – program to translate #5 to #4

Usage examples:

• {{convert|5.2|m|ftin}} → 5.2 metres (17 ft 1 in)
• {{convert|5+3/8|in}} → 5 ³⁄₈ inches (140 mm)
• {{convert|60|x|120|m|ft}} → 60 by 120 metres (200 ft × 390 ft)

Currently, the real master list of unit definitions is a text file on my computer (I have a script to convert that text file to the wikitext used at #5). The uniformly formatted text file is easier for making bulk changes, but will be discarded when the module nears completion.

In addition to the test page listed above, I run a test program on my local system that feeds hundreds of tests into the module.

Module:Convert has many issues to be fixed, and some features that need to be implemented. It does not support inputs with multiple units, such as 3 ft 6 in, and does not support large scale units like e3km. Complex units like the hand unit of length have not been implemented, and there are some hundreds of unit codes that are not yet defined (the units which are defined are listed at #5). Johnuniq (talk) 09:25, 12 February 2013 (UTC)

Transition

The module needs a lot more work and it is far too early to worry about how it might be used on enwiki (although, when fixed, the module will be useful on projects that do not have an existing convert template as it will be much easier to migrate). Nevertheless I will mention that implementing this module on enwiki would involve tremendous difficulty because the existing system of thousands of template subpages has many hard-to-pin-down features, and any attempt to simply switch from the existing template to a new system would inevitably lead to many broken pages (because the new system would not properly implement all required features for many weeks after release, and may never be able to achieve everything done by the stunningly clever existing template).

One approach would be to make a template with a new name (like {{convert2}}), then edit 100 articles to switch them from the old template to the new, and see what breaks. That would involve lots of trouble, but may be the only practical procedure. Changing any widely used template to a Lua module at enwiki is sure to be interesting, and watching the servers handle thousands of cache invalidations will be even more so. Johnuniq (talk) 05:00, 18 November 2012 (UTC)

Progress November 2012

This is in case anyone wonders about progress because there has been no visible activity here for a couple of weeks. I will finish the code, and have done many hours of invisible work on my local system, however it is likely to be several more days before anything much appears here.

The module is capable of doing many conversions, but has many defects (missing features, and some very klunky code). Rounding now works reasonably well, although there are differences from the existing template. I have nearly finished implementing adj=on, adj=mid, and disp=x, and have plans to implement input unit codes with multiple values (like 2 ft 6 in), and combined output codes (like converting acres to square yards and square kilometers).

It would be very useful if a module (particularly Module:Convertdata) could be marked as "read only" so MediaWiki would cache the Lua bytecode (the few temporary variables in that module could be moved elsewhere). Some observations I made suggest that a fresh copy of the module is loaded for every instance of {{convert}} on a page, and loading all the unit definitions for every convert is monumentally inefficient. Johnuniq (talk) 05:00, 18 November 2012 (UTC)

Convert params

Just a few comments on some of the convert params on the current convert template at en.wiki

It would be good to add some tracking categories to the current convert template to check for some of the more obscure convert param to see how widely the are currently used so see if they are worth supporting in the new version.

There are also some params which rely on positional params. For example |adj=mid|bridge or |disp=x| (begin | end). Would be better if these could be modfied to use named params for their extra data. For example |adj=mid|adj-mid=bridge or |disp=x|disp-prefix=(begin |disp-suffix=end). -- WOSlinker (talk) 23:49, 20 November 2012 (UTC)

I have been sidetracked for the last couple of days since noticing that there are hundreds more units that are not in my table (the table is based on the documented "lists of units"). I have now got a confirmed download of the 2865 pages like Template:Convert/xxx, and have extracted 1296 that appear to be unit conversions, and am working out how to extract the data from them (there are only 770 units currently in the module). In addition, I've noticed a few other strange templates that I am ignoring for now.

I don't see how it would be feasible to track which of the current parameters or units are so rare as to not be worth supporting, but if there is a method, that would be good. One point I forgot to make above is that the old and new systems would have to co-exist for a considerable period so results from them could be compared. It appears there are several parameters that are not in the Template:Convert docs, and some of them may be experimental (I've found several subpages of Template:Convert that definitely are experimental). I was thinking that it would be necessary to switch on the new system, then add features like missing parameters as they are noticed.

Yes, adding named params is both easy and useful. However, that would have to be in addition to accepting the current system of numbered params? If we accept "|adj-mid=bridge", there is no need to also enter "|adj=mid" as that is implied. Likewise, just |disp-prefix=... and/or |disp-suffix=... would be sufficient, and |disp=x could be deprecated. Johnuniq (talk) 10:40, 21 November 2012 (UTC)

I just remembered that disp=x probably uses numbered params so the leading/trailing space is preserved. If something like disp-prefix=... were used, there would need to be quotes if spaces are needed, like: |disp-prefix=" [". Johnuniq (talk) 11:09, 21 November 2012 (UTC)

You can use the "What links here" feature against some of the obscure unit templates (For example dog year) to see if it is used and worth supporting. Also some such as Convert/horse year would not be worth supporting in convert even if it was used since it's a non-linear conversion. -- WOSlinker (talk) 20:47, 21 November 2012 (UTC)

Can't you just create a tracking category to cover every occurrence of "a unit we haven't coded for yet" so you can see what obscure units need to be added? For that matter, I'm fairly sure that with this method of coding we can even spot parameters we hadn't bargained for yet, by scanning the args array for any keys we don't recognise. —Phil Boswell (talk) 15:48, 22 November 2012 (UTC)

Good point, and the code already does that for missing units, as can be seen with a couple of "Conversion error" messages at Template talk:Convert (and they put that page in "Category:Convert unknown unit"). That could be done for unknown parameters as well, although I haven't yet thought about that. The main reason I'm persisting with getting a list of all units is that I want to see what exceptions need to be handled for things like identifying the default output unit (which sometimes depends on the input value). I intend ignoring unduly complex stuff like horse years, but I want at least to have a list of what significant work needs to be done. Johnuniq (talk) 22:07, 22 November 2012 (UTC)

Default expressions

I did a bunch of clever things so an expression testing the input value could be used to evaluate the default output. It works well on standard Lua (everything is tested on a local computer during development), but I failed to grok the docs at mw:Extension:Scribunto, and did not notice that loadstring is not available in modules. The result is a bug (currently the output is a script error because loadstring is not implemented):

{{convert|123|m}} → 123 metres (404 ft)

There is only one unit (m) which currently uses an expression for the default, but there are 75 more cases occurring in units that I have not yet added to the data table. They include calculations like:

v * 3.785411784 < 1000

which the old templates handle with {{#expr}}. I was intending to use my Lua code so the expressions could (after translation for the different syntax) be used in the module. I'll ponder what to do. Johnuniq (talk) 00:55, 2 January 2013 (UTC)

OK, that wasn't too hard to fix. Expressions now work, but are less flexible than in the version that used loadstring. Johnuniq (talk) 09:26, 2 January 2013 (UTC)