Template talk:Convert/Archive March 2014

kcal/mol to kJ/mol and vice versa

I'd like to be able to type {{convert|xxx|kJ/mol|kcal/mol}} and see xxx kJ/mol (yyy kcal/mol). Both-way conversion would be preferred. Any chance? --John (talk) 22:35, 27 February 2014 (UTC)

@John: added, but someone should check to make sure I did it correctly. Frietjes (talk) 23:22, 27 February 2014 (UTC)

That's good, but no scale is needed with a "per" unit because it is calculated from the two units in the definition. I removed it. I thought I would demonstrate the advice "See Template:Convert/unit sandbox for a good way to prepare unit definitions" at the top of Module:Convert/extra, but if you check the history of the unit sandbox page you will see it involved a fair bit of messing around, so I might have to withdraw "good way". Unfortunately you can't preview what you are doing, so you have to edit the unit sandbox, then click the purge link on its talk page, then fix the errors shown. Here are a couple of examples which I hope can be confirmed as correct:

• {{convert|1|kcal/mol|abbr=on}} → 1 kcal/mol (4.2 kJ/mol)
• {{convert|1|kJ/mol|abbr=on}} → 1 kJ/mol (0.24 kcal/mol)
• {{convert|1|kcal/mol|4|abbr=off|lk=on}} → 1 kilocalorie per mole (4.1840 kilojoules per mole)
• {{convert|1|kJ/mol|4|abbr=off|lk=on}} → 1 kilojoule per mole (0.2390 kilocalories per mole)

Johnuniq (talk) 00:27, 28 February 2014 (UTC)

thank you. might be good to link to Joule per mole? Frietjes (talk) 00:30, 28 February 2014 (UTC)

Yes, good idea. For both of them? Using the unit sandbox, the fix would be to add the following to the "kJ/mol" line:

|| link = [[Joule per mole]]

Or, just add the following at Module:Convert/extra:

link = "Joule per mole",

Johnuniq (talk) 01:12, 28 February 2014 (UTC)

there is Kilocalorie per mole for kcal/mol. Frietjes (talk) 01:26, 28 February 2014 (UTC)

• A sidetrack. Johnuniq: "Unfortunately you can't preview what you are doing, so you have to edit the unit sandbox". One can not edit & test a convert/extra/sandbox? Does this say that [module:convert] can not have an all-/sandbox copy? (In this case, we could have a full /sandbox stack and experiment with module:convert/extra/sandbox code). -DePiep (talk) 07:20, 28 February 2014 (UTC)

No, the problem concerns the "good way to prepare unit definitions" seen at the top of Module:Convert/extra. There are two pages:

Template:Convert/unit sandbox • Extract from unit definitions.

Template talk:Convert/unit sandbox • Calls makeunits which generates Lua code from the unit sandbox.

The problem is that while editing the unit sandbox, you cannot do anything to preview what the results on the talk page will look like. So, you need to save changes to the unit sandbox, then go to its talk page, then click the "purge" link. If there are any error messages, you have to repeat.

If there are no error messages, the talk page will have some Lua code that you can copy into Module:Convert/extra. You can preview tests of this page before saving. For example, I just went to the page, clicked "edit", and changed the links for the two new units to link = "BOGUS", (but did not save). Then I pasted "Template talk:Convert" into the "Preview page with this template" box and clicked "Show preview". It showed me a preview of this talk page as it would look if the Module:Convert/extra were saved. That preview showed red links for "BOGUS" in the examples above. Johnuniq (talk) 08:58, 28 February 2014 (UTC)

Thank you for the fast result. --John (talk) 09:36, 1 March 2014 (UTC)

AH → CE

Does {{Convert}} (or any other template) handle AH to CE? I don't see it listed anywhere. If not, do you think it worth supporting? nagualdesign (talk) 19:13, 25 February 2014 (UTC)

It looks like {{AH}} does that, at least for dates before 1582. I don't think {{convert}} handles any time or date conversions. LittleMountain5 20:23, 25 February 2014 (UTC)

It does units of time but not points in time. For example {{convert|1|fortnight|0}} gives "1 fortnight (2 weeks)", {{convert|1|month|d|2|abbr=off}} gives "1 month (30.44 days)" and {{convert|1|millennium|Gs|abbr=off}} gives "1 millennium (32 gigaseconds)". The {{#time}} parser may also be useful for time/date conversions. Jimp 08:43, 26 February 2014 (UTC)

Thank you both! Regards, nagualdesign (talk) 17:22, 1 March 2014 (UTC)

Metadata

• Moved from my talk as it raises an interesting point needing wider discussion. Johnuniq (talk) 03:14, 18 February 2014 (UTC)

As I have struggled with this problem before I took a quick look on Module:Convert/data. Sorry to say but this is incomplete as it is and I'm not even sure if it is possible to correct it without some rewriting. A typical error is length calculations, where a lot of length units are missing and some finer points on when and how they were used is not available at all. A foot? When was the measurement taken. Under which jurisdiction. Some length measurements that are called the same can be quite different. Some units can even be converted to other known units from the era, but can't be converted to present time.

If you want to promote this you must be more accurate on metadata about the units. Do not just say that it is a foot. As it is now this module is misleading at best. Jeblad (talk) 02:56, 18 February 2014 (UTC)

So {{convert}} would need an extra option to allow editors to add metadata? Or, since you mentioned units, are you saying there should be several different "foot" units, each with slightly different metadata? That would be quite a challenge, mainly for editors. Has this issue arisen somewhere, or is it something that you have noticed? Do you have examples of what would be required? Johnuniq (talk) 03:14, 18 February 2014 (UTC)

1. Or maybe add "source data" to the units-table, possibly reproduced in the documentation too (by automatic documentation from the table). That way the deeper documentation is not depending on the linked wiki-article foot.

2. Or maybe this is meant: add a parameter |*context= (*name suggestion) to the /data (and thus the datatable) that allows to specify "Roman foot as defined until 456 CE" (I make this up). This could also have with an on-page reference or a more specific wikilink page (#section, redirect).

In general, sourcing the more obscure unit base & handling sounds like an improvement (handling hands!). A parameter |*context= could be useful too in handling rounding, abbreviating, linkking units-but-only-the-obscure-ones. OTOH, subdividing "foot" into different meanings as Johnuniq points to (named & identified differently) does not sound good to me. -DePiep (talk) 10:25, 18 February 2014 (UTC)

• Meta-variations are indicated by unit name: There are many units which have variations in their definition, as indicated by unit name: statute mile (smi), nautical mile (nmi), US gallon, Imperial gallon, U.S. quart, Imperial quart, Australian tablespoon, US tablespoon, US teaspoon, US pint, imperial pint, etc. Compare:

• {{convert |1|nmi|m }} → 1 nautical mile (1,900 m)
• {{convert |1|smi|m }} → 1 statute mile (1,600 m)
• {{convert |1|USgal|L }} → 1 US gallon (3.8 L)
• {{convert |1|impgal|L}} → 1 imperial gallon (4.5 L)
• {{convert |1|USpt |ml}} → 1 US pint (470 ml)
• {{convert/old |1|UStbsp|ml}} →
• {{convert/old |1|AUtbsp|ml}} →
• {{convert |1 |AUtbsp |ml}} → 1 Australian tablespoon (20 ml)
• {{convert/old |.50|calibre|mm}} →

We have been discussing the use of a co-template, {convert/+}, to allow additions of complex unit variations, in limited articles, without triggering the reformat of all pages which use {convert}. -Wikid77 06:48, 20 February 2014 (UTC)

Come to think of it, unit variations (like nmi vs mi) are not meta-data. And re wikid: when unts are used through a separate template like {convert/+}, that doesn't answer the issue. (And of course module/extra does the job Wikid mentions already; better even because the editor does not have to look up which tempalte to use). -DePiep (talk) 16:19, 20 February 2014 (UTC)

• Use {convert/+} for rapid complex units: I was noting to use a {convert/+} to rapidly deploy some rather complex new units such as:
  • {{convert|.22|calibre|mm}} → .22 calibre,
  along with adding numerous other units, without the full regression testing of prior units until the careful testing to update the massive {convert} in 554,000 pages. Remember it has been almost 6 months since discussing the benefits of {convert/old}, such as auto-precision to fix nonsense results: {{convert|105|-|106|F|C}} → 105–106 °F (41–41 °C). At this rate, it doesn't take long before 6 months becomes "one year" and then "years" of stagnation. It is very tedious to update a massive, high-use template which demands extensive retro-testing of all features. -Wikid77 (talk) 17:22, 20 February 2014 (UTC)

Off-topic to me. -DePiep (talk) 13:07, 21 February 2014 (UTC)

Some units have changed over time, and some units had local variations. If you simply say mile or foot orsomething else you leave the interpretation open. As it is now this module is posted to projects where the same units will be interpreted in another cultural context. That leads to errors, and sometimes huge errors to. If you can't fix this you should stop posting this module on projects that has other definitions. You could make the implicit interpretation clearer, but note that the default interpretation in a specific cultural context should be the implicit interpretation, which should probably be project specific. And no, the anglo-american context is not the same as a world-accepted standard interpretation. Jeblad (talk) 08:53, 2 March 2014 (UTC)

Please see my comment at "03:14, 18 February 2014" above. Johnuniq (talk) 09:53, 2 March 2014 (UTC)

Between… and

Is there any way to easily convert ranges in the form of:

between 10 and 20 kilometres (6–12 mi) long

? —sroc 💬 18:26, 8 March 2014 (UTC)

"between {{convert|10|and|20|km|0}} long" produces something similar: "between 10 and 20 kilometres (6 and 12 mi) long". I don't think convert supports the and/dash range separator combination like in your example above. LittleMountain5 20:00, 8 March 2014 (UTC)

The range and(-) exists, but it always shows "and". The module just emulates what the old templates did, and I never saw any discussion about any plans for and(-). The old template is Template:Convert/and(-) which is a redirect to Template:Convert/and (so they are equivalent).

The range to(-) shows "to" when abbreviation is off, and "-" when on, for example:

• {{convert|10|to(-)|20|km|0}} → 10 to 20 kilometres (6–12 mi)
• {{convert|10|to(-)|20|km|abbr=off|0}} → 10 to 20 kilometres (6–12 miles)
• {{convert|10|to(-)|20|km|abbr=on|0}} → 10 to 20 km (6–12 mi)

I cannot see a reason we wouldn't want the same with and(-), so I have put that in the sandbox (diff). Examples:

• {{convert/sandbox|10|and(-)|20|km|0}} → 10 and 20 kilometres (6–12 mi)
• {{convert/sandbox|10|and(-)|20|km|abbr=off|0}} → 10 and 20 kilometres (6–12 miles)
• {{convert/sandbox|10|and(-)|20|km|abbr=on|0}} → 10 and 20 km (6–12 mi)

A few articles use and(-), for example Aardvark and Io (moon). If no one can think of a reason not to make the change, that will go live when the modules are next updated in a week or two. Johnuniq (talk) 05:23, 9 March 2014 (UTC)

Great, thanks! FYI, this came up at Malaysia Airlines Flight 370#Vietnam where I used this crude workaround:

between 10 and 15{{nbsp}}km ({{convert|10|-|15|km|0|disp=output only}}) long

There were a few such ranges, so it got a bit tedious coding each one — and having to update two parts when more accurate data became available. It would be great to have the more elegant solution! —sroc 💬 06:07, 9 March 2014 (UTC)

Overruling the range indicator

Is it possible to overrule the range separator, in a template?
Editor's input: |TemperatureC=10-15
Code used: {{convert|10-15|C|F K}} → 10–15 °C (50–59 °F; 283–288 K)
Preferred output: 10 to 15 °C (50 to 59 °F; 283 to 288 K) (use "to")
We'd rather not parse or edit the input value of course. -DePiep (talk) 06:43, 5 March 2014 (UTC)

Adding: in the template ({{Chembox}}) we also want to control the sequence, e.g. case Fahrenheit:

• |TemperatureF=20-30 → {{convert|20-30|F|C F K|disp=output only}} →

−7 – −1 °C; 20–30 °F; 266–272 K. N

preferred:

−7 to −1 °C; 20 to 30 °F; 266 to 272 K. Y

That sequence might limit the options. -DePiep (talk) 06:59, 5 March 2014 (UTC)

For the TemperatureC example, are you saying that you would like an option that a template could add to a convert (perhaps |range=to) so both "10 to 15" and "10-15" produce the same output? Isn't there some other way of fixing it?

I don't follow the TemperatureF example; for one thing, how has "20 to 30" become "10 to 15"? Using output unit "C F K" will produce what you want, so what is the problem? Johnuniq (talk) 10:29, 5 March 2014 (UTC)

Fixed both examples, sorry I took your time for this. -DePiep (talk) 12:02, 5 March 2014 (UTC)

Your idea to create a |range=to would be good.

"some other way of fixing it" - could not think of one. Catching the input with "this is a range input in parameter #1, so force the range indicator to 'to' " is the wish, but starting input parsing doesn't look the right way.

OTOH, we want to keep for the editors this friendly input feature. It is available. We'd like to allow easy input and standard output.

How serious? {Chembox} has 10k transclusions, ~500 use a temperature range. Switched to the Lua {convert} last December. Until now range input is done by using |TemparatureCH= for the high end; template can detect a "range" and so sets separator to 'to'. I guess it's no big deal, if there is no solution present. -DePiep (talk) 12:16, 5 March 2014 (UTC)

For the chembox case, you could use the {{replace}} template to change "–" to " to ". -- WOSlinker (talk) 13:05, 5 March 2014 (UTC)

Would that be stable? We'd need a pattern (regex) to prevent false positive on a minus sign, ndash or hyphen. Maybe consider replacing in the input param #1, not the output. -DePiep (talk) 13:24, 5 March 2014 (UTC)

the following would probably work,

{{#invoke:string|replace|25 - 30|(%d)[ ]*[–-][ ]*(%d)|%1 to %2|plain=false}}
{{#invoke:string|replace|25-30|(%d)[ ]*[–-][ ]*(%d)|%1 to %2|plain=false}}
{{#invoke:string|replace|25 – 30|(%d)[ ]*[–-][ ]*(%d)|%1 to %2|plain=false}}
{{#invoke:string|replace|25–30|(%d)[ ]*[–-][ ]*(%d)|%1 to %2|plain=false}}

Frietjes (talk) 00:31, 6 March 2014 (UTC)

Thanks Frietjes, that looks like a good solution which should handle the above. Johnuniq (talk) 06:52, 6 March 2014 (UTC)

Thanks indeed Frietjes! Will explore these (original talk is here). -DePiep (talk) 07:14, 6 March 2014 (UTC)

OK, I arrived at pattern:

^%s*(%-?%+?%d+%.?%d*)%s*[%–%-]%s*(%-?%+?%d+%.?%d*)

to catch negatives, decimals, and more whitespace. Development continues (while learning about patterns). -DePiep (talk) 12:04, 6 March 2014 (UTC)

• Johnuniq. About the option to enter a full range in the first parameter.

{convert|10 to 20|C|F K}} → 10 to 20 °C (50 to 68 °F; 283 to 293 K) -- Y

1. This is not mentioned in the thorough Help:Convert page. Is that just a todo-issue, or is it not documented as in "no guarantees given"? (It was introduced here last January, background in the archive).

2. It appears that when input is |1=-30 to -20 (specific: use "to" and 2nd value is negative), it does not work:

{convert|-30 to -20|C|F K}} → −30 to −20 °C (−22 to −4 °F; 243 to 253 K) -- ?

{convert|-30to-20|C|F K}} → -- ?

{convert|-30 - -20|C|F K}} → −30 – −20 °C (−22 – −4 °F; 243–253 K) -- hyphen separator

{convert|-30|to|-20|C|F K}} → −30 to −20 °C (−22 to −4 °F; 243 to 253 K) -- Y Classical 3-para input.

Any remarks? -DePiep (talk) 12:04, 6 March 2014 (UTC)

3. A neighboring issue maybe, with ndash as range indicator:

{convert|30 - 20|C|F K}} → 30–20 °C (86–68 °F; 303–293 K) -- hyphen input

{convert|30 – 20|C|F K}} → 30–20 °C (86–68 °F; 303–293 K) -- ? ndash input

{convert|30|–|20|C|F K}} → 30–20 °C (86–68 °F; 303–293 K) -- 3-para input with ndash.

Less relevant for the topic here (it can be changed to 'to', we hope), but it could be in general.

-DePiep (talk) 17:04, 6 March 2014 (UTC)

unfortunately, lua regexp (as far as I can tell) does not support 'or', so you have to parse the 'to' input separate from the dashes, unless there is some clever trick that I don't know about. inspired by your regexp, see User:Frietjes/c. Frietjes (talk) 23:12, 6 March 2014 (UTC)

Yes Indeed, no "or" option in patterns by definition. I could not use a "%- or %+" sign check. -DePiep (talk) 07:29, 7 March 2014 (UTC)

@DePiep: The "simple range" feature tests for "-" before "to" for a trivial efficiency gain on the assumption that "1-5" is used more often than "1 to 5". I think I noticed that it broke with negative numbers but ignored it because there are very few converts with negative numbers and people could always write it in full. However, I overlooked that infoboxes also call convert, so there are in fact lots of ranges with negative numbers. Anyway, this edit to Module:Convert/text/sandbox fixes the issue, I hope. Please kick it as hard as you can, but convert/sandbox has to be used:

• {{convert/sandbox|-30 - -20|C|F K}} → −30 – −20 °C (−22 – −4 °F; 243–253 K)
• {{convert/sandbox|-30--20|C|F K}} → −30 – −20 °C (−22 – −4 °F; 243–253 K)
• {{convert/sandbox|-30 to -20|C|F K}} → −30 to −20 °C (−22 to −4 °F; 243 to 253 K)
• {{convert/sandbox|-30to-20|C|F K}} →

What is your regex for (I have not tried to decode it)? Are you sure the simple regex from Frietjes is not sufficient? To see how the latter works, consider input "12-34": the regex matches "2-3" and replaces that with "2 to 3" with result "12 to 34". If there is no match, no change occurs, so for example, input "12" is not changed. I would use %s* rather than [ ]*, but that's a matter of taste. I'm fiddling with some translation issues for other wikis at the moment (slowly), but in a week or two perhaps the sandbox modules could be copied to the main modules so the simple range fix works.

BTW, I carefully monitored the en.wiki job queue for nearly two weeks after the last module update and could see no correlation between that update and changes in the job queue. Regarding user documentation: I have that on my to-do list, but I'm afraid I won't get to it quickly. Johnuniq (talk) 01:44, 7 March 2014 (UTC)

The code in User:Frietjes/c looks like a workable hack, and the new sandbox module looks good as well. I think the only thing that was really missing from the original regexp was the possibility of the second number being negative. Having this work directly in the LUA module seems like a good idea as well, so long as there are no false matches. Nice work! Plastikspork _―Œ^(talk) 03:39, 7 March 2014 (UTC)

• re the pattern (Lua 'regex' is actualy called 'pattern'. It is a reduced set of regex rules & codelines. I guess I am the only one here who needs a reminder). 1. I choose to %-escape all literal punctuation marks, not just the required ones (required for "+" because "+" has a double meaning; "–" (ndash char) can be literal only so that's optional. This makes the pattern more readable for a novice like me. Reduce mental load. 2. Yes "[ ]*" better be written "%s*" to catch more whitespace chars (both in number as in ws character list). 3. The original pattern had "(%d*)" to catch a number. That is unsigned integers only. Now "(%-?%+?%d+%.?%d*)" also catches "-25.5" OK. 4. The pattern is not covering all very well, eg allowing "-+25". But in this template case the result is happily fed to {convert} to sort that out. {Convert} will then throw the message related to the edited number (not to template internals, is good). 5. Todo: accept numbers ".5" and "-.5". 6. Noting, the original Frietjes' demo put me on this do & learn track. Development continues. -DePiep (talk) 07:29, 7 March 2014 (UTC) (#5 added; DP)
• re Johnuniq. Looks good, I will shake the sandbox. Thanks for covering this. Sure you had set your priorities right back then. It's just that in this 10k articles template, we'd like to have those <few cases (through a template used 10k times, they still are few) covered or else must work around elaborately in template code or on the pages. But when it works, we can reduce {chembox} complexity seriously! (=allow user input just as it is allowed by {convert}. That would be very cool, as in: between −30 and −20 °C (−22 and −4 °F)). My "documentation?" question was not for the actual how-to text, but to get an idea whether the feature (one-parameter range input) will stay. Your answer is clear for me. For the sandbox going live, I have no time requests in weeks. I just follow this page, and will adapt when the module changes (Nice to know that last time it was invisible in the JQ!). -DePiep (talk) 08:16, 7 March 2014 (UTC)
• re range separator. Seeing this edit (checking range indicators). Could and should "–" (ndash character) not be in there too? Of course it is a common wiki range indicator.

{convert/sandbox|20| – |30|C|F K}} → 20–30 °C (68–86 °F; 293–303 K) -- Y Multi para input, OK

{convert/sandbox|20 – 30|C|F K}} → 20–30 °C (68–86 °F; 293–303 K) -- ? ndash input

{convert/sandbox|-30 – -20|C|F K}} → −30 – −20 °C (−22 – −4 °F; 243–253 K) -- ? ndash input (the separator)

And if it is a literal check, maybe even "&ndash;" could be checked OK. -DePiep (talk) 08:52, 7 March 2014 (UTC)

• Create Convert/range wrapper template: The extra complification inside the Lua {convert}, to handle free-form range expressions, is excessive creeping featurism which has led to the featured creepyism, above, as {convert|-30 to -20|C|F K}} → "^{[[convert: needs another number]}". Plus compare with {convert/old}, which calculated the expression, and consider "+" in the range:

• {convert/old |2*4-1|m|ft}} →
• {convert | 2*4-1|m |ft }} → 2×4–1 metre (6.6×13.1–3.3 ft)
• {convert | 2*4+1|m |ft }} →

Such complex features, as free-form numeric ranges, need detailed status messages to explain invalid data (here "+"), which could be developed as a wp:wrapper template to call {convert}, once the range has been parsed into numbers with separator text, telling the user how "+" is not allowed yet. Otherwise, the free-form ranges have become yet another reason to debug the Lua {convert} and re-deploy to reformat the now 576,000 related pages for another month. -Wikid77 (talk) 00:10/00:19, 7 March 2014 (UTC)

(minor. So, allowing convert input to be |-30 to -20 you consider feature creep, where it used to be |-30|to|-20. I call it a blessing for the editor. You know what: I am working to allow input to be |-30 - -20 C, in single parameter. How creepy is that. On the other hand, we see a lot of function dispersion in WP history, for example listed here and here. I am glad module:convert brought all that back to a single point of design. Yes it is complicated (especially for the designer/programmer), complicated as in "multi layered, muti aspected, multi elemented & all are connected", you know: just a technical system. Not complicated as in "unmanageable, Byzantyne". It is handled in the module, so we should enjoy the advantages (and barnstar Juniq).

To end with a positive note: why not try to expand your considerable wikiskills with the newer techniques? Like me, I am discovering regex (Lua patterns). Now tie me down or I will rewrite the whole template space! I see patterns in my curtains, dreams, and shoppings! I'll need help to get me out of this fun (but not yet please)! -DePiep (talk) 06:32, 7 March 2014 (UTC))

Thinking about en dash made me decide to add it as a simple range because if a wikignome finds something like "1-5" (with a hyphen), they are likely to change it to "1–5" (with an en dash). Examples (input uses en dash):

• {{convert/sandbox|20–30|C|F K}} → 20–30 °C (68–86 °F; 293–303 K)
• {{convert/sandbox|-30–-20|C|F K}} →

Johnuniq (talk) 09:11, 9 March 2014 (UTC)

Patterns

@DePiep: OK I forgot about minus, again. But you don't need to match the whole number. Examples:

• {{#invoke:string|replace|1|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → 1
• {{#invoke:string|replace|-1|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → -1
• {{#invoke:string|replace|1-2|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → 1 to 2
• {{#invoke:string|replace|1--2|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → 1 to -2
• {{#invoke:string|replace|1-+2|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → 1 to +2
• {{#invoke:string|replace|-12.34--56.78|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → -12.34 to -56.78
• {{#invoke:string|replace|-12.34 - -56.78|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → -12.34 to -56.78

Johnuniq (talk) 09:11, 7 March 2014 (UTC)

That must be better, but now I don't understand it any more :-). How is %1 covering too and over the period? Must be that %1 runs on until a false (the dash or hyphen) is countered.

Next accepted numbers to catch: "1,200", "1 200" (?), ".5", "-.5".

• {{#invoke:string|replace|1,200-1,300|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → 1,200 to 1,300 -- Y
• {{#invoke:string|replace|2 200-2 300|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → 2 200 to 2 300 -- ? "1 200" is not accepted by {convert} as a number: .
• {{#invoke:string|replace|.5-.9|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → .5-.9 -- N
• {{#invoke:string|replace|-.9--.4|(%d)%s*[–-]%s*([+-]?%d)|%1 to %2|plain=false}} → -.9--.4 -- N

Numbers not chechked: fractions, pattern 7×2^10, (of course. Just to be complete; we're talking earthly temperatures here). -DePiep (talk) 15:06, 7 March 2014 (UTC)

Looks like this catches the ".5-.9" number pattern:

• {{#invoke:string|replace|.5-.9|([%.%d])%s*[–-]%s*([+-]?[%.%d])|%1 to %2|plain=false}} → .5 to .9 -- Y
• {{#invoke:string|replace|-.9--.5|([%.%d])%s*[–-]%s*([+-]?[%.%d])|%1 to %2|plain=false}} → -.9 to -.5 -- Y

Input "-.9 to -.5" is accepted by {convert/sandbox}: −.9 to −.5 °C (−0.9 to −0.5 °C; 30.4 to 31.1 °F; 272.2 to 272.6 K). -DePiep (talk) 15:41, 7 March 2014 (UTC)

Regarding how the regex works, consider input "-12.34 - -56.78". The pattern matches "4 - -5", and that is replaced with "4 to -5". The rest of the input is unchanged, so the final result is "-12.34 to -56.78". In a replacement, %1 means the text matched by the first capture (the first pair of parentheses), and that is "4" in this example, while %2 is "-5".

Regarding input "2 200 to 2 300", convert cannot accept spaces in numbers because that would cause bad input to be accepted as valid. As a matter of interest, I have very recently implemented the use of nonbreaking spaces to group digits at the Norwegian wiki (see here), but even there, spaces in an input number are regarded as invalid.

Use "(%d)%s*[–-]%s*([+-]?[.]?%d)" to handle numbers that start with a dot. Note that "[%.%d]" matches a percent symbol or a dot or a digit (the first "%" must be omitted).

I'll think about what would be involved with handling en dash, but I'm reluctant to add much special-purpose code without thoroughly pondering what might be required in other usages (perhaps it should be handled some other way). For the particular issue you are addressing, there might be a simple module which parses the input (changing "12-56" to "12 to 56" and more). That would be much more easily adapted to suit current and future requirements for the chembox. I could write up something to get started, if that were needed (if so, please suggest a title: Module:Parse?). Johnuniq (talk) 03:44, 8 March 2014 (UTC)

Thanks, I get this! As for "1 200": no suggestion to have that accepted. About en dash: I'd say that if "–" is accepted as a range indicator in 3-param input ({{convert|1|–|5|C|F}} -- works OK), then the one-parameter input should do alike. That would be general behaviour & expectation. (We're talking character here, not the HTML entity). So no "special-purpose code". For my OP issues here, the problem does not exist ("–" will be catched & replaced by "to"). -DePiep (talk) 17:27, 8 March 2014 (UTC)

@DePiep: Ooops, something I ran into elsewhere made me wonder whether what I said above is correct—it isn't, and I've struck it out above. What I said is correct in some other regex implementations (although they use backslash rather than percent as the escape character), but Lua patterns are different: [.] matches "." (no need for percent), but percent is ignored when followed by any punctuation character in square brackets (and the punctuation character loses any magic property it would normally have). That means [%.] is the same as [.] and will match only the "." character, and [%[%]] will match "[" or "]". Johnuniq (talk) 03:26, 10 March 2014 (UTC)

Yes, I found that mistake when testing your statement. In pattern [%.] is the period literal, straight [.] is meta for 'all characters' (mw). So [%.%d] should not and does not recognise a % in the string. Agreed & tested, I can use this as concluded.

But there is one nut I could not crack (off topic, maybe not worth time). Checking the opposite: use [.%d] to prove that plain . should catch every character. But string 5-q9 did not hit with [–-]([.%d]) (I simplified). My theory failed. Could be the [] brackets change meaning? As I read the mw manual: In Lua patterns, letters are literal unless %-escaped, while punctuation chars are meta unless %-escaped. Mirrored definitions. So meta, or character class, are + and %d; literals are %+ and d. Did not pursue this test, because it is offtopic for me in this. -DePiep (talk) 10:15, 10 March 2014 (UTC)

Yes, the [] square brackets drastically change the meaning.

Pattern "abc" searches for the three characters "abc" (a followed by b followed by c).

Pattern "[abc]" searches for a single character: a or b or c.

Pattern "[.b]" searches for a single character: . or b. Johnuniq (talk) 10:40, 10 March 2014 (UTC)

Got that. My earlier tests showed catching difference (yes/no) between using [.] and ., other things kept the same. That looked like a [] effect I could not grasp. (No time now to provide examples - I have to pause this thread. Will be back with actual demos. That's better). -DePiep (talk) 11:16, 10 March 2014 (UTC)

More one-parameter input

Already, a range can be entered as one parameter (this became possible after we left wikicode {convert} last December).

• {convert|10|to|20|km|mi}} → 10 to 20 kilometres (6.2 to 12.4 mi) -- Y
• {convert|10 to 20|km|mi}} → 10 to 20 kilometres (6.2 to 12.4 mi) -- Y

Extending this: would it not be übercool to also allow the unit to be in parameter 1 too:

• {convert|10 to 20 km|mi}} → 10 to 20 kilometres (6.2 to 12.4 mi) -- (constructed demo outcome)

For the casual editor, this looks like a natural way of writing (good). Used in a template, the template code does not have require separately the unit (good). This is from today's {{infobox country}}.

|area =               <!--Major area size (in [[Template:convert]] either km2 or sqmi first)-->
|area_km2 =           <!--Major area size (in square km)-->
|area_sq_mi =         <!--Area in square mi (requires area_km2)-->

If correct recognition (in the input string) is a problem, the feature could: be limited to more common units; require an extra parameter |unit_is_type*=area (ugly for editors, but can nicely be set a template); ... I have not thought yet about other input variants (multidimensional, ...). -DePiep (talk) 09:39, 11 March 2014 (UTC)

Natural input would be desirable, but that would need some deep thought. For an infobox, the idea would be that there could be, for example, a generic "area" field that would take the value and the unit, so reducing the clutter and trickiness associated with area_km2 and area_sq_mi etc. But some kind of error checking would be needed—you don't want just any area unit to be available, and if someone puts "12 m" instead of "12 m2", there should be a prominent error. I'm thinking that some kind of wrapper module would be useful—the infobox would pass the input value/unit and a comma-separated list of permitted units to a wrapper, and that would call convert after extracting any range and after validating the unit, or providing a default input unit. The functionality of the wrapper might later be incorporated in convert, but I think it would be better to experiment with a wrapper first, and merging might make convert really bloated and complex. Johnuniq (talk) 10:22, 11 March 2014 (UTC)

Yes, some deep thinking needed. It should only be done if it is conceptually sound (and so systematically applicable). If your advise is to start with a wrapper - good. -DePiep (talk) 10:53, 11 March 2014 (UTC)

• prefix. Let me add this to the concept: "single parameter input" could also take care of scientific prefixes: |< 10 °C. The prefix is not part of the calculations at all, but is nicely reproduced in the output:

{convert|< 10 C|F}} → < 10 °C (50 °F) --constructed demo

I actually encounter this in {{chembox}}, where such input value exists. Today it must be covered by using extra parameter |temperature_prefix=<. For plain hand editing this is more natural writing, with a small benefit of consistent formatting (of course, when hand-editing is easy to write the prefix outside of {convert} of course). I have not idea how extended the range of possible prefixes is (cover "ca." too?). Nor any conflicting issues (~ has a meta meaning already in {convert}?). -DePiep (talk) 10:53, 11 March 2014 (UTC)

Debugging: return input

For debugging purposes, I'd like to have a parameter |test_return_input*=on that, eh, returns the input. (The * asterisk denotes that this name is just a placeholder)

• {convert|7O|C|F K|test_return_input*=on}} → 7O C|F K

-DePiep (talk) 09:23, 11 March 2014 (UTC) (fixed my example -DePiep (talk) 09:43, 11 March 2014 (UTC))

When used in mainspace, it should work too but all usage be tagged & categorised for 'maintenance'. -DePiep (talk) 09:45, 11 March 2014 (UTC)

That seems a very specialized option. I'm wondering why it would be useful given that hovering the mouse over the error message shows a significant part of the input. What about showing options like |abbr=on? One problem is that named parameters have no particular order so it is not possible to reconstruct exactly what was passed to convert as the order is unknown. The example reminds me of an irritating item on my todo list: {{convert|70|C|F|K}} has an extra "|K" parameter which convert happily ignores—even with warnings on, extra unnamed parameters are not detected. Johnuniq (talk) 10:20, 11 March 2014 (UTC)

Well, specialized for all purposes then. But you're right: I forgot the mousehover option. I'll be back if I can make a stronger case for an "explain" need (=to show inner workings & logics). -DePiep (talk) 10:58, 11 March 2014 (UTC)

Mousehover hint is only available in error situation. Also does not explain parameter options entered. That's for learning & debugging. -DePiep (talk) 11:10, 11 March 2014 (UTC)

Supporting delta mode for units with additive bias

When reading Dinosaur, I noticed a problem in the section Extinction of major groups with the unit conversion.

The planet's temperature was also much more uniform, with only 25 °C (77 °F) separating average polar temperatures ... the poles, for example, were 50 °C (122 °F) warmer than today.

The Fahrenheit values are incorrect. They should say 45°F and 90°F, respectively. I went to fix this in the editor thinking that it was a human mistake, but found out that it was a template problem:

{{convert|25|°C|°F|abbr=on}}
{{convert|50|°C|°F|abbr=on}}

It's not a bug; it's simply that the converter is assuming that you are working with an absolute temperature and not the difference of two temperatures. We don't want the converter to add 32 to the result. Would it make sense to add a new option, "delta=on", to have the converter treat the value as a difference and not apply additive unit conversions, only multiplicative (and exponential/logarithmic, e.g. pH)?

-- Myria (talk) 07:31, 10 March 2014 (UTC)

There are units for that, namely C-change, F-change, and K-change. By the way, while °C works as a unit, C also works and is recommended—the output is identical. Also, temperature units default to |abbr=on. Here are some examples:

• {{convert|25|C|F}} → 25 °C (77 °F)
• {{convert|50|C|F}} → 50 °C (122 °F)
• {{convert|25|C-change|F-change}} → 25 °C (45 °F)
• {{convert|50|C-change|F-change}} → 50 °C (90 °F)

The first two show absolute temperatures, while the last two show temperature changes. Johnuniq (talk) 08:36, 10 March 2014 (UTC)

I made the change at Dinosaur (diff). Johnuniq (talk) 22:53, 10 March 2014 (UTC)

Could & should the output unit not be like Δ°C, Δ°F and ΔK? If I recall well, the common scientific term for change is "delta" (relative difference). -DePiep (talk) 11:26, 11 March 2014 (UTC)

Mixed input units

This might simply be stupidity on my part, but I'm having great difficulty converting from "mixed" units, as used in imperial/USC, to metric. An example of what I instinctively want to type:

{{convert|3|6|ftin|m}}

But apparently "ftin" can be used only as an output unit... is there a way to have two input units? Archon 2488 (talk) 12:30, 11 March 2014 (UTC)

@Archon 2488: yes, you need to split them, {{convert|3|ft|6|in|m}} Frietjes (talk) 16:21, 11 March 2014 (UTC)

problem with e6 scaling of multiple-output-units

1. 49,525,988 hectares; 122,381,382 acres; 495,260 square kilometres; 191,221 square miles Y (normal: multiple-output with no scaling works)
2. 50 million hectares; 122 million acres; 495 thousand square kilometres; 191 thousand square miles N (problem: multiple-output with scaling fails)
3. 50 million hectares; 122 million acres; 495 thousand square kilometres; 191 thousand square miles Y (workaround: scaling works with single-output)

The error-message says that "ha e6acre e3km2 e3sqmi" is an invalid unit, which suggests that it is parsing *everything* after the initial e6 as a 'unit' and ignoring space-separators. From Barley, if it matters.  ;-)   HTH. 74.192.84.101 (talk) 01:37, 13 March 2014 (UTC)

Yes, it's a bit hard for convert to guess what the initial "e6" applies to because some unit codes contain a space. The workaround is to use "+" to separate units, rather than a space. Example:

• {{convert|49,525,988|ha|e6ha+e6acre+e3km2+e3sqmi|0|lk=on|abbr=off|disp=output only}} → 50 million hectares; 122 million acres; 495 thousand square kilometres; 191 thousand square miles

Johnuniq (talk) 02:43, 13 March 2014 (UTC)

Ahh, thanks. If using plus to separate multiple outputs works reliably, generally speaking, should the helpdocs be changed to use the plus-separator rather than the space-separator? In any case, Barley appreciates the + trick.  :-)   Thanks for improving wikipedia, see you around. 74.192.84.101 (talk) 11:02, 13 March 2014 (UTC)

Input in OP is:

1. {{convert| 49,525,988 |ha| ha acre km2 sqmi |0|lk=on|abbr=off|disp=output only}}
2. {{convert| 49,525,988 |ha|e6ha e6acre e3km2 e3sqmi |0|lk=on|abbr=off|disp=output only}}
3. {{convert| 49,525,988 |ha|e6ha |0|lk=on|abbr=off|disp=output only}}

Want to learn as much as I can ;-). -DePiep (talk) 11:18, 13 March 2014 (UTC)

@74: It's almost documented at Help:Convert units#Combinations. I'll expand it a little one day. Johnuniq (talk) 11:39, 13 March 2014 (UTC)

Aviation units - three way conversion

The aviation industry uses knots as the primary measurement of speed, but the general public understand only km/h or mph depending on where they live. What we really need for aviation articles is a conversion code which displays knots followed by km/h and mph, but the templates shown here only seem to work for conversion from one unit to one other. Does anyone know of a template to convert knots to km/h and mph? If not could someone who has the coding skills please make one? Djapa Owen (talk) 08:45, 22 March 2014 (UTC)

Like this?

• {{convert|200|knot|mi/h km/h}} → 200 knots (230 mph; 370 km/h)

So the third parameter (output units) can have multiple units (separate then with a space). -DePiep (talk) 09:13, 22 March 2014 (UTC)

(Cleaned up my own answer. Prevent distraction. -DePiep (talk) 10:32, 22 March 2014 (UTC))

• Knots defaults to 2 output units. Remember how the default output unit, for knots "kn" or some other input units, will automatically show 2 output units. Examples:

• {{convert|300|kn}} → 300 knots (560 km/h; 350 mph)
• {{convert|200|kn}} → 200 knots (370 km/h; 230 mph)
• {{convert|199|kn}} → 199 knots (369 km/h; 229 mph)
• {{convert|175|kn}} → 175 knots (324 km/h; 201 mph)
• {{convert|175|kn|disp=5}} → 175 knots (325 km/h; 200 mph)

The default precision of 300 or 200 is 2 digits, but 200 knots rounds the same at sigfig=3. To match hurricane wind speeds from the U.S. National Weather Service (NWS), then add "disp=5" to round to the nearest 5 units. However, such windspeeds, also for tornadoes or typhoons, should be quoted from sources (unless the source has errors or lacks a conversion). -Wikid77 09:29, 24 March 2014 (UTC)