Module talk:Convert

Module:Convert/makeunits

I've done some major refactoring on Module:Convert/makeunits and it now runs on wiki (no stand-alone computer needed, although I have made a system to invoke the new makeunits for easier testing on my local computer). As noted on the doc page, there is some weirdness in the output that can be worked around by using "subst:". Someone may like to experiment and put the newly defined units in Module:Convert/data. BTW I have reported the bug currently visible in the archives box on this page. Johnuniq (talk) 10:48, 7 October 2013 (UTC)

Great! May I suggest we start with the habit to put any new version into Module:Convert/data/sandbox first, and test the /sandbox? -DePiep (talk) 11:10, 7 October 2013 (UTC)

Status

I've seen this project working in the shadows, and I wonder what the status is, and if it's going to gonna get ready for prime time any time soon. _→AzaToth 19:27, 14 November 2013 (UTC)

I'm a bit embarassed about the status as the module has been nearly ready for three months. The module actually is ready (and has been used at the Bengali wiki since June, see here), but I've wanted to do a couple of other things, and I wanted to wait for some personal quiet time before asking for {{convert}} to be changed to use the module. I have no plans to change anything in the module—the "other things" involves setting up a more extensive set of testcases and finishing some documentation. The "quiet time" is because quite a bit of work will be required when the module is live, and there's sure to be a couple of weeks of problem fixing (defining missing units; handling reports of breakage; changing the syntax for some features such as spelling which the module does differently). Unfortunately real-life stuff has got quite hectic, and while I've had time to respond to a couple of things on my watchlist, I've had hardly any thinking time for a couple of weeks. In a week I will have a good idea of how off-wiki problems are going. Come to think of it, I might never be "ready" and the best thing might be to just switch the damned thing on and see what happens... Johnuniq (talk) 08:45, 15 November 2013 (UTC)

I would suggest release it now; If there are minor problems, others can probably fix it if you are not around, and if it crashes totally, then I assume it can be reverted. _→AzaToth 21:45, 19 November 2013 (UTC)

Johnuniq is saying that he/she will need personal quiet time when this one goes live: there could be major problems popping up. I remember when citation /CS1 went live last April, it needed 15 updates in the first month (not that number is important, but the thinking & coding it represents). Leave it up to J I say. -DePiep (talk) 06:11, 20 November 2013 (UTC)

Thanks DePiep: you have read me accurately. However, I'm glad to say that the last couple of days have gone well here, and my hectic period has passed for the moment.

Thanks AzaToth: you have pushed at exactly the right moment to get me going again, and I've spent the last couple of days checking some matters that were outstanding. I will recommend the switch at Template talk:Convert#Request to switch to Module:Convert. Johnuniq (talk) 09:28, 20 November 2013 (UTC)

Feature request: configReport feedback

I propose the module get s a "config feedback" public function. Its job is to return what configuration settings the module uses. It would be used in document pages & sandboxes (not in mainspace). Demo: Say the module is live, and calling template has this code:

• {{Convert}} {{#invoke:convert|convert| numdot = , }}

Then on Template:convert/doc we ask for the config overview:

• {{#invoke:convert|configReport| numdot = , }}

The report would return:

Incomplete, mockup list

configReport for Module:convert

Variable	Value	Note
Configuration of	#invoke:convert
Template invoking	Module:convert/doc	(template calling configReport)
Module invoked	Module:convert
Parameter(s) set in invoking template:	|numdot=,
|is_test_run=	false
Units data page used	Module:Convert/data
Text data page used	Module:Convert/text
Value applied for numsep	,
Value applied for numdot	,
Value applied for max_sigfig	14
Value applied for lang	(none)	implies en for current wiki
...	...

Rationale.
A lot of configs variables are set, in multiple locations (template, data, text, in module code various places, ...). Also, many are interacting (e.g., sandbox, testing, and language). Some settings are hardcoded in the main convert function. Also there is the logic to be reporduced in the function (prevalence and logic of settings, e.g. overwriting defaults). These has to be copy-pasted or hardcoded into the configReport function; this requires attention. And this configReport also must be called from a template that has copy-paste all parameters from the researched one, another manual action = risk. On the other hand, it gives an editor an overview & a check. It is self-documenting the configuration. Notes: This idea is working in Module:RailGauge to check the datafiule. (coding: User:Mr. Stradivarius). -DePiep (talk) 06:55, 20 November 2013 (UTC)

Good idea, although I'm not sure how much use it would get. Rather than a new function, it should be pretty easy to have a new option (perhaps report=on inside a normal {{convert}}) which would display the table instead of the normal output. I don't think the first three lines are achievable (configuration of, template invoking, module invoked). Johnuniq (talk) 09:56, 20 November 2013 (UTC)

Yes, better: calling through function "convert" prevents having to copy-paste the very settings & logic one wants to check.

Self-identifying the calling template &tc. was a long shot - failed.

Would not be used much, but invaluable in sandboxing. -DePiep (talk) 10:04, 20 November 2013 (UTC)

Use of Lua Convert fork

Currently, the Lua script version of Template:Convert (as [[Module:Convert) has been treated as a sandbox version, with Template:Convert/sandboxlua, but installation for wider usage is being discussed. However, despite fears of forking the template, the Lua version has diverged as a fork with different features, incompatible with the markup-based Convert. Originally, {convert} was a simple gateway template to hundreds of subtemplates, which each could convert more than just measurements, but also dates and times which the Lua fork does not handle. Examples of non-numeric conversions:

• {{convert|25 November|date|day}} → 25 November (day 329)
• {{convert|3:45 pm|time|24}} → 3:45 pm (15:45)

The divergence of the Lua version, as a fork, began reasonably as an attempt to "improve" some glitches in the protected Convert subtemplates (now being fixed by the authorized wp:template editors), where the rewrite in Lua would make results consistent. Hence, the forking was a natural follow-on to also add new features, such as 3-part combinations in Lua:

• {{convert/sandboxlua |99|in|ydftin}} → 99 inches (2 yd 2 ft 3 in)
• {{convert |99|in|ydftin}}             → 99 inches (2 yd 2 ft 3 in)

Similarly, the Lua version has other new features, but they come at a high price: as a gargantuan Lua module which would trigger the reformatting of all articles (552,000) using Convert (if any feature were altered except new units in Module:Convert/extra), whereas the original markup-based Template:Convert has allowed numerous feature changes to affect only a few dozen or hundred pages at a time. Efforts to keep the 2 versions synchronized have been delayed for weeks or months, and I think we will need to release the Lua version, as a beneficial fork, but under separate template name(s). Also, there have been calls for a "feature freeze" to transition entirely to Lua, but that implies the old features will be dropped (as incompatible), while a better plan would be to accept new features until a 3-month period of no new requests, allowing the efficient markup-based Convert to reformat only the few articles using a new feature each day (not reformat 552,000 pages for each Lua edit). Meanwhile, I have created Template:Convert/q, to run the rapid Lua version, for rare cases beyond the typical 3-7 conversions, in pages which would contain hundreds of {convert/q}. New features could be added, to either version, and the need for identical features could be assessed in each case, as there are no "consistency police" forcing similar templates to function with lock-step operation. Forks are needed at times: some prefer vanilla and some prefer chocolate, but "chocnilla" is unlikely to satisfy everyone. I think we could carefully expand the use of the Lua version, such as inside Template:Height (using ft/m units), but keep both versions and not force a VE-style upset where "edit" suddenly ran a different interface putting "<nowiki>" tags around "[__]". Because the markup-based Convert is relatively fast (over 40 per second), there is no critical need to use Lua for 7-conversions-per-page. Perhaps discuss these issues below, for use of Lua in {Height} or other templates, and then announce plans at those other templates. -Wikid77 (talk) 07:48, 25 November 2013 (UTC)