Template talk:Convert/Archive July 2013

Long tons and hundredweights, "lk=on" does not work.

For LSWR H15 class, and later for others: {{convert|79|LT|19|Lcwt|t|1|lk=on}} to {{convert|82|LT|1|Lcwt|t|1|lk=on}} 79 long tons 19 hundredweight (81.2 t) to 82 long tons 1 hundredweight (83.4 t) and in addition or better yet {{convert|79|LT|19|Lcwt|t ST|1|lk=on}} to {{convert|82|LT|1|Lcwt|t ST|1|lk=on}} 79 long tons 19 hundredweight (81.2 t) to 82 long tons 1 hundredweight (83.4 t) but {{convert|79|LT|19|Lcwt|t|1}} to {{convert|82|LT|1|Lcwt|t|1}}, 79 long tons 19 hundredweight (81.2 t) to 82 long tons 1 hundredweight (83.4 t) does work Peter Horn User talk 22:50, 30 June 2013 (UTC)

---

The converts mentioned are:

• {{convert|79|LT|19|Lcwt|t|1}} → 79 long tons 19 hundredweight (81.2 t)
• {{convert|79|LT|19|Lcwt|t|1|lk=on}} → 79 long tons 19 hundredweight (81.2 t)
• {{convert|79|LT|19|Lcwt|t ST|1|lk=on}} → 79 long tons 19 hundredweight (81.2 t; 89.5 short tons)
• {{convert|82|LT|1|Lcwt|t|1}} → 82 long tons 1 hundredweight (83.4 t)
• {{convert|82|LT|1|Lcwt|t|1|lk=on}} → 82 long tons 1 hundredweight (83.4 t)
• {{convert|82|LT|1|Lcwt|t ST|1|lk=on}} → 82 long tons 1 hundredweight (83.4 t; 91.9 short tons)

Using the module for the same converts gives:

• {{convert/sandboxlua|79|LT|19|Lcwt|t|1}} → 79 long tons 19 hundredweight (81.2 t)
• {{convert/sandboxlua|79|LT|19|Lcwt|t|1|lk=on}} → 79 long tons 19 hundredweight (81.2 t)
• {{convert/sandboxlua|79|LT|19|Lcwt|t ST|1|lk=on}} → 79 long tons 19 hundredweight (81.2 t; 89.5 short tons)
• {{convert/sandboxlua|82|LT|1|Lcwt|t|1}} → 82 long tons 1 hundredweight (83.4 t)
• {{convert/sandboxlua|82|LT|1|Lcwt|t|1|lk=on}} → 82 long tons 1 hundredweight (83.4 t)
• {{convert/sandboxlua|82|LT|1|Lcwt|t ST|1|lk=on}} → 82 long tons 1 hundredweight (83.4 t; 91.9 short tons)

I had been hoping to be ready to suggest using the module more widely by now, but I have been sidetracked by the interesting problems associated with making it work on a non-English wiki (see my Bengali user talk). Johnuniq (talk) 00:52, 1 July 2013 (UTC)

I updated the sandbox for {{Convert/LT}}, and it seems there is a simple fix,

• {{convert|79|LT/sandbox|19|Lcwt|t|1}} → 79 LT/sandbox
• {{convert|79|LT/sandbox|19|Lcwt|t|1|lk=on}} → 79 LT/sandbox
• {{convert|79|LT/sandbox|19|Lcwt|t ST|1|lk=on}} → 79 LT/sandbox
• {{convert|82|LT/sandbox|1|Lcwt|t|1}} → 82 LT/sandbox
• {{convert|82|LT/sandbox|1|Lcwt|t|1|lk=on}} → 82 LT/sandbox
• {{convert|82|LT/sandbox|1|Lcwt|t ST|1|lk=on}} → 82 LT/sandbox

I will make an edit request. Frietjes (talk) 15:51, 1 July 2013 (UTC)

The problem is fixed. Jimp 01:58, 3 July 2013 (UTC)

Convert/LoffAonDxSoffT

Jimp, would you mind creating {{Convert/LoffAonDxSoffT}} so that disp=x| works with temperatures? Thanks. — Huntster (t @ c) 02:50, 4 July 2013 (UTC)

Also, does disp=comma work anywhere, as the instructions say it should? For example: {{convert|11|ft|m|disp=comma}} produces 11 feet, 3.4 m. — Huntster (t @ c) 02:55, 4 July 2013 (UTC)

{{Convert/LoffAonDxSoffT}} has been created; thanks to Frietjes. As for disp=comma, I got rid of it since it didn't seem useful. I could be wrong. It could be resurrected. Here's the code (an improved version).

{{convert/numdisp|{{{1|0}}}}} {{#ifeq:{{{1|0}}}|1|{{{n}}}|{{{l|{{{n}}}s}}}}}, {{convert/{{#if:{{{2|}}}|{{{o}}}|{{{3}}}}}|{{{1}}}|({{{1}}})*{{{b}}}|{{#if:{{{2|}}}|{{{3|}}}|{{{4|}}}}}|{{{s|}}}|r={{{r}}}|j={{{j}}}|d=LoffAoffSoff}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

On the other hand, {{convert|11|ft|m|abbr=off|disp=x|, }} will give you "11 feet, 3.4 metres", if that's what you're after. Jimp 04:53, 5 July 2013 (UTC)

• Using Convert/f for rare format options: To avoid another 800 Convert subtemplates for disp=comma, then the formatting could be handled by {Convert/f}, such as:

• {convert/f |56|mi|km|disp=comma} → 56 miles, 90 km
• {convert/f |56|mi|km|disp=or}        → 56 miles or 90 km

Then users who prefer "disp=comma" would have the option without needing the cumbersome 800 subtemplates with name-part "Dcomma". -Wikid77 (talk) 09:00, 8 July 2013 (UTC)

Thanks to everyone. I only asked about Comma since it was in the description, but I see that Jimp has removed that, so all good. — Huntster (t @ c) 09:07, 8 July 2013 (UTC)

negative 0

{{convert|251|to|273|K|°C|abbr=on|0}} gives 251 to 273 K (−22 to 0 °C) . Is there anyway to make it a plain 0 instead of -0 ?  Stepho  talk  08:59, 9 July 2013 (UTC)

the problem is in template:convert/Dual/LoffAoffDxSoffT, which computes the result with {{#expr:( 273-273.15 ) round 0}} = -0. note that convert/sandboxlua does is correctly. Frietjes (talk) 15:45, 9 July 2013 (UTC)

also note 273 K (0 °C) vs. 273 K (0 °C), so it's not just the dual conversion. Frietjes (talk) 16:07, 9 July 2013 (UTC)

• Round to 1 digit to avoid negative 0: Those happened before, and the solution was to round by one digit for temperature ranges:

• {convert |251|to|273|K|°C|1} → 251 to 273 K (−22.1 to −0.1 °C)

That avoids the negative zero, which is valid in scientific work. -Wikid77 04:01, 12 July 2013 (UTC)

Thank you for the suggestion. However, it is meant to refer to the freezing point. If I were to make it accurate to 0.1°C then I would be wrong instead of just rounding to whole units.  Stepho  talk  05:25, 12 July 2013 (UTC)

• Then use {convert/flip2} for the known results: I also recall using a flipped conversion to control the negative-zero numbers:

• {convert/flip2 |-22|to|0|°C|K|abbr=on} → {{convert/flip2|-22|to|0|°C|K|abbr=on}}

Remember to flip the results to avoid negative zeroes. -Wikid77 (talk) 06:17, 12 July 2013 (UTC)

Alternatively, as Frietjes noted, use the module which has special code to handle negative zero. Consider:

• {{convert|273.149|K|C|2}} → 273.149 K (0.00 °C)
• {{convert/sandboxlua|273.149|K|C|2}} → 273.149 K (0.00 °C)
• {{convert/sandboxlua|251|to|273|K|C|0}} → 251 to 273 K (−22 to 0 °C)

It could be argued that the second result (0.00 °C) is broken as showing a negative sign would be more accurate, but I thought that negative zero was too unfamiliar for typical usage. With both the template and the module, C and °C give the same results, and |abbr=on is not needed. Johnuniq (talk) 07:43, 12 July 2013 (UTC)

Convert/help shows options interactively

To encourage more new features for {Convert}, I have created Template:Convert/help which displays a help-box summarizing parameter options and common unit-codes. A user can put "help" as the unit-code of a conversion:

• {convert|4|m|help} → 4 metres ()

There are so many new features which could be added to {Convert}, as long as we keep focusing on progress. -Wikid77 (talk) 04:01, 12 July 2013 (UTC)

question regarding the use of e6 = millions

I am trying to do a convert involving millions of Acre feet to cubic kilometers, so that it will display as "10 million acre.ft (12.3 km³), so I believe the correct usage would be {{convert|10|e6acre.ft}}, but it doesn't work. I have tried many variations with no result. Does someone know the proper usage of the template in this way? Thanks. Shannon 06:15, 16 July 2013 (UTC)

The module that is being developed (slowly!) handles e3 to e15 with any "standard" unit (details here), so these work:

• {{convert/sandboxlua|10|e6acre.ft}} → 10 million acre-feet (1.2×10¹⁰ m³)
• {{convert/sandboxlua|10|e6acre.ft|km3}} → 10 million acre-feet (12 km³)
• {{convert/sandboxlua|10|e6acre.ft|km3|abbr=on|1}} → 10×10^⁶ acre⋅ft (12.3 km³)

You want the abbreviated input name (unit symbol) with the not-abbreviated "million". That would need a new unit to be defined. The template would do what you want if {{Convert/e6acre.ft}} were created. Johnuniq (talk) 07:37, 16 July 2013 (UTC)

should work now (10 million acre-feet (1.2×10¹⁰ m³)). Frietjes (talk) 15:22, 16 July 2013 (UTC)

Thanks. Hope it wasn't too much trouble Shannon 02:07, 17 July 2013 (UTC)

disp=or + abbr=values

0.0064 or 0.16, 0.0064 (0.16), 0.0064 in or 0.16 mm Would it be possible to make the first on [one] work? Peter Horn User talk 23:48, 17 July 2013 (UTC)

• FIXED - recreated Convert/LoffAvaluesDorSoff. I have recreated the one subtemplate needed to handle any similar cases. -Wikid77 (talk) 02:50, 18 July 2013 (UTC)

Formatting fractions

It appears that the output of fractions (or at least mixed numbers) is inconsistent with that of {{frac}}. For example, mixed numbers (a whole number and a fraction) such as 1+1⁄2 are produced by the {{convert}} without a space in between (which is required for technical reasons). This has come up in a wider discussion at Wikipedia talk:Manual of Style/Dates and numbers#Non-breaking_spaces_in_mixed_numbers.

Can the {{convert}} template be updated to use the {{frac}} template to ensure these are always kept consistent? —sroc (talk) 23:56, 16 July 2013 (UTC)

---

Following is what it looks like. The output from the module is identical with that from the template, so it is not included.

• {{frac|1|2|3}} → 1+2⁄3
• {{frac|1|2}} → 1⁄2
• {{convert|1+2/3|in|mm}} → 1+2⁄3 inches (42 mm)
• {{convert|2/3|in|mm}} → 2⁄3 inch (17 mm)

Following is from Special:ExpandTemplates (with only the number shown for the converts):

{{frac|1|2|3}}	        <span class="frac nowrap">1<sup>&#32;2</sup>&frasl;<sub>3</sub></span>
{{frac|1|2}}            <span class="frac nowrap"><sup>1</sup>&frasl;<sub>2</sub></span>
{{convert|1+2/3|in|mm}} <span class="frac nowrap">1<s style="display:none">+</s><sup>2</sup>&frasl;<sub>3</sub></span>
{{convert|2/3|in|mm}}   <span style="white-space:nowrap"><sup>2</sup>&frasl;<sub>3</sub></span>

Considerations include how the text appears, how it wraps, and how it copies in various browsers. It's easy to change. Johnuniq (talk) 02:12, 17 July 2013 (UTC)

Thanks, Johnuniq. I believe there has been concern that the hidden "+" used in the {{convert}} output was poor form from an accessibility standpoint and due to problems when copy-pasting (i.e., at least in some cases, the pasted text would render as "12/3" which misrepresents the number), which is apparently why it isn't used in {{frac}}: see Template talk:Frac#Spacing for example. In any case, it would be good to keep this consistent, but I'm not brave enough to mess with the coding myself. Perhaps wait and see where the conversation at Wikipedia talk:Manual of Style/Dates and numbers#Non-breaking_spaces_in_mixed_numbers goes first anyway. —sroc (talk) 08:58, 17 July 2013 (UTC)

I'm developing Module:Convert which I hope one day will implement nearly all of the stunningly complex features of the convert templates, so my comments were of a general nature with information that I have readily at hand. The regular maintainers of the template would be able to update the way fractions work, but it would involve tracking down exactly which templates are involved—that's not a job for mortals. When the module is ready (soon!), I can easily make it output whatever is required for fractions because it's just two lines of code for the formatting. Johnuniq (talk) 11:09, 17 July 2013 (UTC)

• Hidden '+' in fractions is browser-dependent (copy/pastes in IE): That portion of {Convert} could be changed to "show" the plus-sign '+' off-screen, so all browsers would copy/paste as "1+2/3". Internally, {Convert} must contain the +/- and so "-1-2/3" would be the negative form (although negatives are almost never used in {Convert} ). I understand the desire for consistency with other fractions as displayed. -Wikid77 (talk) 14:55, 17 July 2013 (UTC)

Just to be clear, shouldn't the output for negative numbers use the unitary minus sign (−) per MOS:NUM#Minus_sign? Presumably that would also apply to the separator (i.e., "−1−2/3")? —sroc 💬 12:13, 18 July 2013 (UTC)

Yes, minus signs would work for copy/paste to a calculator. The separator could be hidden by display in a span-tag positioned off-screen: "<span style="position:absolute; top: -9999px">−</span>" or such, which has been tested to copy/paste while hidden in Firefox, IE and other browsers. -Wikid77 23:54, 18 July 2013 (UTC)

Sorry to add to the problems, but the use of {{frac}} is discouraged in mathematics articles, and in some other scientific fields. {{sfrac}} is suggested as an alternative. Perhaps the fraction formatting in {{convert}} could take options. My apologies if this has already been discussed; I came here from WT:MOSDATE. It is sometimes difficult to find the logic behind local guidelines, but my recollection from WT:MATH is that consensus was that it didn't look right. — Arthur Rubin (talk) 22:22, 19 July 2013 (UTC)

To see how these styles look in conversions, I added a kludge to Module:Convert. If the input has one slash, the {{frac}} style is used; two slashes uses the {{sfrac}} style; three slashes uses the style of the current convert templates:

• {{convert/sandboxlua|2/3|in}} → 2⁄3 inch (17 mm)
• {{convert/sandboxlua|1+2/3|in}} → 1+2⁄3 inches (42 mm)
• {{convert/sandboxlua|-2/3|in}} → −2⁄3 inch (−17 mm)
• {{convert/sandboxlua|-1-2/3|in}} → −1+2⁄3 inches (−42 mm)
• {{convert/sandboxlua|2//3|in}} → 2/3 inch (17 mm)
• {{convert/sandboxlua|1+2//3|in}} → 1+2/3 inches (42 mm)
• {{convert/sandboxlua|-2//3|in}} → −2/3 inch (−17 mm)
• {{convert/sandboxlua|-1-2//3|in}} → −1+2/3 inches (−42 mm)
• {{convert/sandboxlua|2///3|in}} → 2/3 inch (17 mm)
• {{convert/sandboxlua|1+2///3|in}} → 1+2/3 inches (42 mm)
• {{convert/sandboxlua|-2///3|in}} → −2/3 inch (−17 mm)
• {{convert/sandboxlua|-1-2///3|in}} → −1+2/3 inches (−42 mm)

Negative fractions are rarely used in conversions (probably, never used), so I won't worry about whether the negative results are optimum.

Here are some examples in text:

The diameter is 2⁄3 inch (17 mm) and it is 2/3 inch (17 mm) up and down, and 2/3 inch (17 mm) across.

The diameter is 1+2⁄3 inches (42 mm) and it is 1+2/3 inches (42 mm) up and down, and 1+2/3 inches (42 mm) across.

Johnuniq (talk) 04:17, 20 July 2013 (UTC)

I tried copying the above text in recent versions of Firefox and Internet Explorer. The results were identical:

The diameter is 2⁄3 inches (17 mm) and it is 23 inches (17 mm) up and down, and 2⁄3 inches (17 mm) across.

The diameter is 1 2⁄3 inches (42 mm) and it is 123 inches (42 mm) up and down, and 12⁄3 inches (42 mm) across.

Johnuniq (talk) 04:27, 20 July 2013 (UTC)

Disregarding the output for negatives, it looks good! If it's not too hard to implement, could we make the default output use {{frac}} and have an optional parameter to use {{sfrac}} instead? I think the better compatibility with copy-pasting is a good reason to make {{frac}} the default for most purposes, which is consistent with MOS:FRAC. —sroc 💬 11:53, 21 July 2013 (UTC)

I'm not sure if you are aware of the difference between Template:Convert and Module:Convert. The former is a series of templates (over 2800!) that have been developed over the last several years. The latter is a Lua module that I have been working on for a long time. I am getting confident that the module will be ready for consideration as a replacement for the templates real soon now, but if and when it will replace the templates are open questions. The template {{convert/sandboxlua}} uses the module to do a convert. I changed the module so frac is the default ("1+2/3" uses the same style as {{frac}}). If you can think of a better method than using "1+2//3" to invoke the sfrac style, please suggest it. It's easy to add options, but the problem with doing so is that it makes usage more confusing and difficult. I acknowledge that a double slash is a pretty ugly kludge, but it's actually quite a good way to say "I want something extra for the slash". It would be fairly easy for Jimp to change the output style of fractions in the existing templates, although in such a complex set of inter-dependent templates, even a minor change is not easy. Johnuniq (talk) 12:35, 21 July 2013 (UTC)

Thanks for the clarification. It sounds like a herculean task, which is not surprising, and I commend you on your efforts! I don't expect this to be a quick fix! If I understand correctly that the aim is that the Module:Convert you're working on will eventually replace the {{convert}} template, by way of suggestions, would it be difficult to have a version called {{sconvert}} for example that would work in exactly the same way but use {{sfrac}} for the fractions output? That would be more intuitive, I would imagine. But that might mean more work maintaining two templates? Or could they kind of use the same engine to transclude the result before passing the output through the relevant template? Sorry, I'm pretty vague on the back-end stuff. —sroc 💬 15:31, 21 July 2013 (UTC)

Yes, it is my intention that the module replace the template. It would be easy to have another template which invokes the module, but which passes an argument that the module interprets to mean "for a fraction, use sfrac style rather than frac". However, there are lots of other options, and I doubt that it would be worth making a special template just for the fraction style. I haven't done an investigation, but it's likely that fractions in converts are rare, and the sfrac style could be accommodated with a parameter if the double-slash is considered to be too klunky. Let's worry about the exact syntax later—once the module has code to perform a particular function, it's reasonably easy to adjust the method of requesting that function in the template used in an article. Johnuniq (talk) 04:07, 22 July 2013 (UTC)

Rather than a whole different template, a parameter to control fraction style on this one may be more user friendly. You end up with dozens of special templates all doing slightly different jobs (there are plenty of examples of template families like this). One of the good things about this template is that it has taken the opposite approach replacing a whole heap of special single-conversion templates. Of course, as things got complicated this one-template-to-convert-them-all-and-on-the-encyclopædia-cover-them got difficult and special templates cropped up again (or have stuck around). I hope the new version can reverse this.

As for the difference between this as {{frac}}, it's {{frac}} which has changed. I'm not so fond of the new style {{frac}} is delivering but this is not the place to discuss that. These two templates should be consistant, yes. So let's go with what {{frac}} does. Jimp 05:44, 22 July 2013 (UTC)

"Inhabitants"

I received a request on my talk page:

"On 20 July 2008 (I know, a long time ago) you protected the template Template:Convert/PD/km2. I am regularly annoyed to see text produced by this template and the similar Template:Convert/PD/acre, Template:Convert/PD/ha, Template:Convert/PD/sqmi, saying, for example, "The population density was 1,286.2 inhabitants per square mile (496.6 /km2)." "Inhabitants" is totally superfluous. Can it be removed from the template(s)? Emeraude (talk) 11:17, 17 July 2013 (UTC)"

This sounds reasonable but I want to check for consensus before I edit the protected templates. — Carl (CBM · talk) 13:13, 17 July 2013 (UTC)

• New unit-codes PDper/sqmi & PDper/km2: I have created Template:Convert/PDper/sqmi (and PDper/km2) to omit "inhabitants" and allow {Convert/f} to insert other words ("residents") if needed:

• {convert|235|PDper/sqmi} → 235 PDper/sqmi
• {convert|50|PDper/km2} → 50 PDper/km2
• {convert/f |235|PDper/sqmi|PDper/km2|x1=residents} → 235 residents PDper/sqmi ()

Thanks for discussing this issue, which seems a reasonable concern for years now. I hope the "instant fix" of the new unit-codes will be acceptable for now. -Wikid77 (talk) 14:55, 17 July 2013 (UTC)

"inhabitants" was always optional. If you don't want this, just omit the PD. Jimp 05:55, 22 July 2013 (UTC)

Convert/C and Convert/F need fixing (and Convert/R should be deleted?)

Some admin please fix {{Convert/C}} and {{Convert/F}} – they are currently a redirects to {{Convert/°C}} and {{Convert/°F}}. This change should be made, even if this means going through all articles that use them in the sense of °C and °F. The current use is utterly inexcusable, presumably motivated by its potential use as a shorthand, but there are legitimate uses for "C" and "F": the very well-known and widely used SI units coulomb (unit) and farad (unit), which should also be supported by this template. This would also suggest that {{Convert/R}} should be deleted: use of this lazy input should be discouraged, since it may cause a similar headache. Is requiring the use of the edit bar (for °) too much to ask? — Quondum 17:03, 23 July 2013 (UTC)

Templates are supposed to help editors and be easy to use. Lots of people want to convert between °C and °F, but many do not know how to type the degree symbol, or where to find it.

Converting coulomb is extremely rare, and in fact "what links here" shows only a single article where it is used, and it's not even used there because it is converting e to its default output, which is coulombs. Summing up, there are no conversions from coulomb, and there is only a single conversion to coulomb, namely:

• {{convert|100|e|sigfig=5|abbr=on}} → 100 e (1.6022×10⁻¹⁷ C)

I gave up trying to count how many article use "C" to mean degrees Celsius—there are over 5000.

If anyone does want to convert coulombs, it is easy to do, like this:

• {{convert|1.2|coulomb|e|sigfig=4}} → 1.2 coulombs (7.490×10¹⁸ e)
• {{convert|1.2|coulomb|A.h}} → 1.2 coulombs (0.00033 A⋅h)

Displaying symbols, optionally linked, is also easy:

• {{convert|1.2|coulomb|e|sigfig=4|abbr=on|lk=on}} → 1.2 C (7.490×10¹⁸ e)
• {{convert|1.2|coulomb|A.h|abbr=on|lk=on}} → 1.2 C (0.00033 A⋅h)

No farad unit is defined for convert because no one has asked for it. That makes sense because there are not many alternative units. Johnuniq (talk) 01:06, 24 July 2013 (UTC)

There are non-conflicting expressions that are not ambiguous (e.g. degC, degF), and I'd suggest that the number of editors that know how to use {{convert}} but can't produce a ° symbol are vanishingly small. And the reason it is not linked to may be because it is unavailable, and in every case some workaround has been found, such as just not using the template. An example of the need for a workaround is in {{val/units}}, where the misappropriation of the symbol means that the symbol must be trapped before the convert symbols are checked. There are also cases where conversion to units other than the elementary charge e would be appropriate, such as statcoulombs. So I really do not buy the argument that it makes it any easier. It is just trading a simple inconvenience for a problem that forces editors to search pretty carefully how to deal with the problem. When I removed the workaround in {{val}}, a whole lot of articles using it suddenly were displaying coulombs as °C. So now there is an inconsistency between the units in {{convert}} and {{val}}, which is unfortunate and could be avoided. The use of the full name and putting abbreviations on is not as obvious as "degC", and is not available in {{val}}. Perhaps to start, the documentation should be changed to encourage use of °C and °F even if no change to the template is made for a long time – currently it actually uses C and F in examples, which is probably the primary reason its use is so widespread.

I agree that the sheer number of cases where the symbols C and F are used makes this potentially problematic, although a bot should be able to take care of these if it is decided to clean them up. I will, however, solicit opinion from the science community on this, since my lone voice is evidently not going to convince you. — Quondum 01:54, 24 July 2013 (UTC)

As John points out, there simply is no reason to change the redirects, which are heavily in use, to point to colomb and farad, which don't seem to be used as inputs at all across the entirety of the English Wikipedia. Given this, it is hard to understand why you find this change so desperately necessary. Further, I suppose I don't see why your desired mode of operation at {{val}} should affect the operation of {{convert}}. — Huntster (t @ c) 03:46, 24 July 2013 (UTC)

Ah, I see what you're doing. You use {{val/units}} to convert easily typed units such as g/cm3 to nicely display forms such as g/cm³. Anything that isn't in your list is passed to one of convert's subtemplates. That's kind of clever but very fragile as it depends on convert not changing its subtemplates. Maybe we'll change the parameter order or their meaning (valid things to do in subtemplates that should never be seen by anybody except their parent template) and your template will suddenly stop working. Published API's are wonderful things but using unpublished/undocumented API's is dangerous.  Stepho  talk  04:35, 24 July 2013 (UTC)

This is one of the issues with the rewrite of {{convert}}. We'll have not only to rewrite this template but all the others that use its subtemplates (another example is {{convinfobox}}). Anyhow, yes, there is inconsistency between the unit codes used in {{convert}} and {{val}}. Yes, it is unfortunate and could be avoided. Would it be worth it, though? Would it be worth the inconvenience of having to type °C or even degC. Is consistency between these templates so huge an issue? Then, of course, there is the problem that there are so many transclusions using C & F fixing these would be a bit of a task (we'd need a bot) and the problem that users are used to this (it would take some time for poeple to adjust). Jimp 07:05, 24 July 2013 (UTC)

Okay, let's reframe/summarize:

• {{val}} is not "my" template. But I think it is going to see a lot more use, and should be cleaned up. Recreating an entire nearly duplicate database of subtemplates for its use merely to avoid fragility seems like a bad idea.
• I take the point that changing the behaviour of {{convert}} is not necessarily a good idea, debates of "convenience" aside.
• That the subtemplates are reused elsewhere suggests the need for a coherent central database of subtemplates of this nature (names, conversions, etc.), with a well-defined and coherent interface. Any templates that use this database (which could in principle include {{convert}}) could then apply their own idiosyncrasies, such as "easy-to-type" features.
• I have suggested above that the documentation could be modified to not so prominently suggest the short-cut. To make this change might have long term benefits in terms of keeping WP more uniform, even though it mandates nothing. I've had no reaction to this.
• I find the argument that C and F (or even their spelled-out equivalents coulomb and farad) are not being used as inputs to {{convert}} to be completely spurious.

It then boils down to two suggestions:

1. Does it make sense to create an independent subtemplate database with logical, uniform behaviour and a well-defined interface for use by templates generally? A source for this is potentially already largely existent in the form of most of the many subtemplates of {{convert}}; any programmer will understand the concepts of modularity and reuse being applied here and their benefits.
2. Does it make sense to make the shorthand/irregular names (C and F) less prominent in the documentation (i.e. the examples) for {{convert}}, simply to reduce the consequent future irregularity bias?

— Quondum 11:32, 24 July 2013 (UTC)

FYI, there are over 2800 templates in the convert family, and making a uniform database from that complexity is tricky—see User:Johnuniq/Conversion data for my attempt. Of course it would be wrong to display "C" as a "simple" rendition of °C, however it is not easy to see where the balance between ease-of-use and uniformity should lie when considering the use of "C" as an input code. Editors do not need to convert coulombs, but they often want to convert °C. Johnuniq (talk) 08:09, 25 July 2013 (UTC)

Show output only or hide input.

300 US gallons (250 imp gal; 1,100 L) I don't want to show the 300 US gallons. Peter Horn User talk 16:26, 26 July 2013 (UTC)

{{convert|300|USgal|impgal L|disp=output only}} → 250 imp gal; 1,100 L  Stepho  talk  23:39, 26 July 2013 (UTC)

Thanks a million. Peter Horn User talk 01:56, 27 July 2013 (UTC)

Convert convert to use scribunto (Lua)

I think it could be an idea to convert the mass of convert to become a module; See WP:LUA for more information. Don't know thought if a conversion should be 1:1, or some other ideas should have standing (li.e for example the posibility to parse "12.45 km/h" directly). _→AzaToth 11:01, 25 July 2013 (UTC)

I've been working on it since last September, see Module:Convert. I agree that in the future it would be worth considering an alternative syntax where the module parses blocks of text rather than requiring each item to be pipe-delimited. However, the initial challenge is to cover all the amazing features provided by the complex web of over 2800 templates. I'm currently working on ranges of more than two items. Johnuniq (talk) 11:22, 25 July 2013 (UTC)

Changes to modules require reformat of million articles

The reason that {Convert} uses dynamic template names, rather than a Lua module, is to allow rapid creation of new unit-codes, on the fly, to handle conversions in a relative few articles, without requiring the extensive reformatting of all half-million articles using Convert. As Wikipedia grows in size, then Convert will be used in upwards of a million pages, where only a few hundred need be reformatted when rare unit-codes are added or updated. By comparison, the Lua wp:CS1 citation templates all use Module:Citation/CS1 which impacts over 1 million pages, and a single change to the Lua requires reformatting all million. The Lua version of Convert is an exercise, in actual existence, to demonstrate how often the module must be updated, to handle new unit-codes, and how often a million pages would need to be reformatting for 4 days at a stretch. For example, template {Convert} has new unit-code "UStsp" for US teaspoons, which did not exist in the Lua version (30 July 2013):

• {{convert|15|UStsp|ml}}               → 15 UStsp
• {{convert/sandboxlua|15|UStsp|ml}} → 15 UStsp

Ask yourself: what good is using Lua for conversions, when adding (or updating) a unit-code would require more than 4 days of reformatting articles before the new measurements would appear in all affected pages? Historically, we have seen Convert subtemplates updated at least once per week, which would mean that a Lua-based Convert would be continually reformatting articles all year long, to update them to handle the new unit-code definitions. By comparison, the markup-based Convert template can handle a new unit-code added to perhaps 500 articles and reformat them all within 5 minutes, while not bogging down the wp:Job_queue with reformatting of a million unrelated pages. Due to logistical problems with reformatting many thousands of pages, the reformatting of a million pages often "gets stuck" while awaiting the interleaved reformatting of other pages, and so the 4-day reformat of a million pages would span 5,760 minutes (4*24*60), as 1,152x longer than a 5-minute reformat for a new Convert unit-code subtemplate. Because template Convert can reformat pages over 1,000x times faster, that gives a thousand reasons to limit the use of Lua in conversions. -Wikid77 (talk) 10:45, 31 July 2013 (UTC)

Yes, there would be a large amount of server grinding when a commonly-used module was updated. I asked about that last February at VPT, and Tim Starling's reply was unconcerned. It's not clear how bad a problem it would be in practice because if someone asked for a new unit like UStsp the few pages where it was wanted could be purged (?action=purge) if needed. In fact that would not be needed because presumably the person making the request would ask for the unit before adding it to several pages, and when a page was edited to add UStsp it would work correctly, even if the module had only been changed a minute before. It is true that if, say, a default output unit was changed, then it would be a matter of hours (or even days?) before the updated information was seen in articles that had not been edited or purged, but assuming the old data was valid, the delay is not a big problem. Tim is one of the very top WMF developers, and he has spent a lot of time worrying about how to make MediaWiki work faster on the available servers in order to reduce page view and edit times. He introduced Lua as a performance improvement (as well as a syntax improvement), and it's unlikely there is anyone with a better understanding of the factors involved. Johnuniq (talk) 12:35, 31 July 2013 (UTC)

Template:Convert/LoffAoffDbSoffImp

The above template appears as a redlink when attempting {{convert|3.5|imppk}}. Using 3 pecks doesn't help, but {{convert|3.5|USpk}} does, albeit with the wrong size of course. Martin of Sheffield (talk) 14:12, 25 July 2013 (UTC)

• Use imppk/sandbox until fixed: That unit-code "imppk" is a left-over from the years that suffix "-Imp" duplicated hundreds of subtemplates. Until updated, please use the sandbox version with unit-code "imppk/sandbox":

• {convert|3.5|imppt}}            → 3.5 imperial pints (2.0 L)
• {convert|3.5|imppk}}            → 3.5 imperial pecks (32 L; 7.2 US dry gal)
• {convert|3.5|imppk/sandbox}} → 3.5 imppk/sandbox
• {convert|3.5|imppk/sandbox|L}} → 3.5 imppk/sandbox

All of the hundreds of "*Imp" subtemplates were to be removed, to reduce the size of Convert when adding newer options. -Wikid77 (talk) 11:23, 31 July 2013 (UTC)

Thanks for getting back. Within the article I have used around 3½ pecks{{efn|just under {{convert|1|impbu}}.}} which sidesteps the problem (Felling_mine_disaster#1847_disaster final paragraph). I don't like leaving problems unreported and unfixed though, hence this section. From your comments above, is "impbu" (imperial bushels) likely to disappear? Regards, Martin of Sheffield (talk) 11:42, 31 July 2013 (UTC)

The minus sign is not displayed correctly when using ranges.

The hyphen sign is incorrectly used in ranges instead of minus sign. This does not happen when using simple conversions.
Examples with the template:

• {{convert|-20|C|F}} → −20 °C (−4 °F) – correct minus sign rendered: −20 °C (−4 °F)
• {{convert|-30|to|-20|C|F}} → −30 to −20 °C (−22 to −4 °F) – incorrect minus sign rendered: -30 to -20 °C (-22 to -4 °F)

Thanks for correction. -- TH

the difference is between Template:Convert/Dual/LoffAoffDxSoffT and Template:Convert/LoffAonDbSoffT. in the single number case it calls a subtemplate (Template:Convert/-1 ) to render the minus. in the dual case, it calls template:Convert/to/AonSoff, which does not do anything special for negative numbers. Frietjes (talk) 16:41, 29 July 2013 (UTC)

• Use Convert/2 for ranges: Whenever there are problems in the typical 2-unit ranges then use {Convert/2} (or Convert/flip2 or Convert/3 or Convert/4):

• {convert/2 |-30|to|-20|C|F}} → {{convert/2|-30|to|-20|C|F}}

Use those to display the ranges with whatever results shown by Convert with one unit. -Wikid77 (talk) 11:53, 31 July 2013 (UTC)