Template talk:Convert/Archive January 2017

Nomination for deletion of Template:Convert/

 * TfD of all Convert subtemplates.

Template:Convert/ has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 14:32, 23 December 2016 (UTC)
 * Perhaps a better TfD link.
 * —Trappist the monk (talk) 15:00, 23 December 2016 (UTC)


 * Background of Convert/... TfD: The first Convert subtemplate (in alphabetic order), Template:Convert/ was created by me (User:Wikid77), along with hundreds of others, and so I was targeted as the template(s) author of subtemplates. Personally, I consider it wp:forum shopping to drag an active template to wp:TfD without first discussing concerns at Template_talk where more expert users would likely have extra time to explain issues and dispell misunderstandings. Otherwise, it only takes 2 "Delete" !votes, plus a wp:non-admin closure as wannabe "consensus was snow delete" in 2 days, to initiate immediate deletion by an admin in thousands of pages. Hence, a TfD of miscellaneous Convert subtemplates is a hideous risk which can trigger deletions in thousand of pages within 3 days of nomination. As for specific subtemplate {convert/}, I created it in 2011 to issue an error message for users who used {convert/old} with a blank 2nd parameter "| |" which had shown "Template:Convert/" when parameter 2 was blank. -Wikid77 (talk) 18:02, 23 December 2016 (UTC)
 * I do not expect a 2-days-old non-admin speedy closing. -DePiep (talk) 19:01, 23 December 2016 (UTC)

Keep pages Whitelist
Obviously, this TfD should not delete Template:Convert/doc. Is it useful to create a whitelist category for pages to Keep? Or does have an other sugegstion? -DePiep (talk) 19:01, 23 December 2016 (UTC)
 * Research could start in . -DePiep (talk) 19:26, 23 December 2016 (UTC)
 * Category:Subtemplates of Template Convert or Special:PrefixIndex/Template:Convert, although there are a lot of them. --RexxS (talk) 20:07, 23 December 2016 (UTC)
 * Would be the blacklists then (whitelist=to keep, I meant). Both lists may be inaccurate for this. -DePiep (talk) 01:52, 24 December 2016 (UTC)
 * Would be the blacklists then (whitelist=to keep, I meant). Both lists may be inaccurate for this. -DePiep (talk) 01:52, 24 December 2016 (UTC)

I updated my list of convert templates. Jimp may like to comment. I don't know what should be done with the old templates but the discussion should be extended beyond the normal seven days given the enormous number and the time of year. Some serious study of the list of templates is needed to see exactly what is wanted—feel free to edit. Johnuniq (talk) 00:18, 24 December 2016 (UTC)
 * By now, User:Johnuniq/Convert templates now blacklists exactly all pages that can be deleted as being Convert/Old related (parsed code, not Lua code). Some checks may be useful, see Talk . -DePiep (talk) 12:25, 28 December 2016 (UTC)

Off-topic, trivial, and misunderstood issues from the TfD

 * In the TfD, several issues and examples were brought up by related to comparing Convert (Lua code) results with  (parsed code) results. Wikid77 also stated I am not advising to revert from Lua {convert} back to wikitext {convert/old}, but rather to compare results . This makes the issues and examples Wikid mentioned moot in that TfDelete proposal. I already pointed out in the TfD that these perceived flaws are off-topic, and also trivial and a misunderstanding . After all, now each of the examples is just an illustration of possible flaws in Convert, not a proof of error. With this, their arguments are off-topic there, and should be discussed here as Lua-template-only issues.  is not needed to illustrate these flaws. So I opened this subsection.
 * Maybe later I will repeat or expand my content statements already made (essentially, that the examples are trivial, and/or misunderstanding of rounding & precision maths, and/or omitting options/solutions already available). -DePiep (talk) 08:43, 4 January 2017 (UTC)

Fixing default precision of ranges

 * (refactored {convert/old} delete. Wikid77 (talk) 10:13, 5 January 2017 (UTC))

For several years, the {convert} calculation of ranges had been over-rounding to show nonsense ranges where 2 different amounts were converted into the same number, and a fix was added in December 2013 but lost in transition to the Lua Module:Convert. One user had noted the common temperature range 105-106 °F giving nonsense range "41-41 °C" which was fixed even earlier in {convert/old}: However the default precision for other measurement ranges was fixed on 7 December 2013, just days before the 30-day RfC about Lua was wp:Snow-closed to force out Lua {convert} on 11 Dec 2013 in advance of the Christmas/Chanukah, New Year holidays. As a result of the forced chaos during the holidays, the corrected range precision was lost for the past 4 years, as in lb-to-kg: The problem had also appeared in multi-output values, converting one unit into two other units: A partial fix involved checking the difference of the range, compared to the conversion factor, such as ft-to-m being factor ~3.3 or cm-to-inch as 2.54 and so a check for amt1-amt2 < 4 worked to increase precision by +1 for ranges less than 4 units apart. However for ft-to-miles, the difference is >4, because the factor is 5,280, as thousand with digit multiplier 5.28, and hence differences near 5 feet could be rounded to the same nonsense range. Fortunately, the Lua range conversion of ft-to-miles appears correct already, and so a range difference of 4 (giving precision +1) seems to work for other units. Beyond those cases, there have been other precision problems for some decimal ranges, but those are extremely rare, and could be analyzed later after fixing the simple cases, such as the following 9 cases:
 * {convert |105 |-|106 |F |C} &mdash;> 105 - 106 F -- AA
 * {convert-old|105|-|106|F|C} &mdash;> 105 - 106 F
 * {convert|43|-|45|lb|kg} &mdash;> 43–45 pounds (20–20 kg) -- BB
 * {convert-old|43|-|45|lb|kg} &mdash;>
 * {convert|36|-|37|g |oz ozt} &mdash;> 36 - 37 g -- CC
 * {convert-old|36|-|37|g|oz ozt} &mdash;> 36 - 37 g
 * {convert |111 |-|113 |mm|in} &mdash;> 111 - 113 mm -- DD
 * {convert-old|111|-|113|mm|in} &mdash;>
 * {convert |113 |-|114 |oz|lb} &mdash;> 113 - 114 oz -- EE
 * {convert-old|113|-|114|oz|lb} &mdash;>
 * {convert |27 |-|28 |ozt|lb} &mdash;> 27 - 28 ozt -- FF
 * {convert-old|27|-|28|ozt|lb} &mdash;>
 * {convert |37 |-|39 |USfloz|USqt} &mdash;> 37 - 39 USfloz -- GG
 * {convert-old|37|-|39|USfloz|USqt} &mdash;>
 * {convert |0.113 |-|0.114 |oz|lb} &mdash;> 0.113 - 0.114 oz -- HH
 * {convert-old|0.113|-|0.114|oz|lb} &mdash;>


 * {convert |5283 |-|5287 |ft|mi} --> 5283 - 5287 ft -- II
 * {convert-old|5283|-|5287|ft|mi} --> [same]
 * {convert |5283 |-|5286 |ft|mi} --> 5283 - 5286 ft -- JJ
 * {convert-old|5283|-|5286|ft|mi} -->

Because some of the underlying Lua calculations for precision differ from the old wikitext unit-subtemplates, the corrected Lua range precisions could still differ slightly from {convert/old}; however, the main goal is to fix nonsense ranges in Lua {convert} by increasing precision +1 for close ranges. -Wikid77 (talk) 00:59, 5 January 2017, refactored Wikid77 (talk) 10:13, 5 January 2017 (UTC)
 * {convert |27 |to|29 |mm|in} &mdash;> 27 to 29 mm -- KK
 * {convert-old|27|to|29|mm|in} &mdash;>
 * {convert |189 |-|189.1 |cm|in} &mdash;> 189 - 189.1 cm -- LL
 * {convert-old|189|-|189.1|cm|in} &mdash;>
 * {convert |188 |-|188.1 |ft|m} &mdash;> 188 - 188.1 ft -- MM
 * {convert-old|188|-|188.1|ft|m} &mdash;>
 * Added labels AA–MM to examples. No reply. -DePiep (talk) 09:37, 5 January 2017 (UTC)
 * Sure they might need to be "Fixed". You can do that yourself by analysing the issue, and using the appropriate parameters.
 * None are nonsense ranges in Lua. They are the result of the well-documented and talked Rounding & Precision (R&P) mathematics. If you claim a range is nonsense, go to the source (your input).
 * None of the examples is from actual usage in content space. All are theoretical extremes. For this we can call them, and the thesis of this section, irrelevant. -DePiep (talk) 09:46, 5 January 2017 (UTC)

The issues about default precision go back even to 2007, when the Convert subtemplates were begun. However, this time of year, people want to go to the beach wherever the weather is warm now. See 2007 archive: "Template_talk:Convert/Archive December 2007". The exact examples are difficult to trace, with the history of subtemplates being deleted. As for "nonsense ranges" see the last word on that talk-archive page, when discussing bad results of precision, as "nonsense" in December 2007. The default precision of {convert} has been a major concern here for 10 years. Welcome to the discussions. -Wikid77 (talk) 10:47, 5 January 2017 (UTC)
 * Added labels AA–MM to examples. No reply. -DePiep (talk) 09:37, 5 January 2017 (UTC)
 * Sure they might need to be "Fixed". You can do that yourself by analysing the issue, and using the appropriate parameters.
 * None are nonsense ranges in Lua. They are the result of the well-documented and talked Rounding & Precision (R&P) mathematics. If you claim a range is nonsense, go to the source (your input).
 * None of the examples is from actual usage in content space. All are theoretical extremes. For this we can call them, and the thesis of this section, irrelevant. -DePiep (talk) 09:46, 5 January 2017 (UTC)


 * Here's the basic analysis.
 * In general, when meeting this try improving the R&P, especially that of your input values (numbers or parameters).
 * 1. If the range interval ≈ unit conversion factor (ucf), specify R&P (actually, "≈" should read: same order of magnitude). Try improve input quality first, otherwise output. This pertains to almost all examples AA–MM
 * Example, AA: 105 - 106 F. Range interval = 1, ucf &deg;F &rarr; &deg;C is 1 F-change.


 * If R&P refinement is not possible, e.g. when the source is not clear on this, the same-number-range output is a good approach, as it is actually stating comparatively correct basic R&P. If that number repetition is an undesired style, consider rephrasing using partial output, out:
 * ... {convert|105|F|C|disp=out} &rarr; 105–106 &deg;F (105 F)


 * 2. When converting within one unit system (e.g., from inches to miles is withing the imperial system, all lengths of course), manually set the R&P by sigfig or 4. Since this is always trivial (expected in topical articles only), one must take extra care of R&P. This is especially at hand when the unit system is non-decimal (say, everything not SI or metric). Because since the rounding uses the decimal digit (0&ndash0.4999 or 0.5–1.0), the u.c.f. is non-decimal. 1 feet = 12 inch. So in situations the "12" may cause the output value to fall on the undersired end of the "0.5" border.
 * From example EE {convert |113 |-|114 |oz|lb}:
 * 113 - 114 oz (sigfig=4: 113 - 114 oz)
 * 114 - 115 oz (sigfig=4: 114 - 115 oz)
 * 115 - 116 oz (sigfig=4: 115 - 116 oz)
 * 116 - 117 oz (sigfig=4: 116 - 117 oz)


 * 3. If you don't want to solve the issue, leave the topic and don't ask any time or attention from fellow editors. -DePiep (talk) 12:10, 5 January 2017 (UTC)


 * re . I'm sorry, . Since you changed and earlier post that already had a response, you are breaking good talkpage manners WP:REDACT. Bye. -DePiep (talk) 12:23, 5 January 2017 (UTC)

Thai area unit rai
The rai is a widely used traditional Thai unit of area which is now SI-based and equals exactly 1,600 square metres. Would it be practical to include in the template? A large range of values will have to be supported, from e.g. 4 rai (6,400 m2, 69,000 sq ft) to 215 rai (34.9 ha, 86.2 acres) to 15,294 rai (24.470 km2, 9.4481 sq mi) and 10.31 million rai (16,500 km2, 6,369 sq mi). --Paul_012 (talk) 06:15, 6 January 2017 (UTC)
 * @Paul_012: I added the unit and we can see how it is used and if there are any problems. Examples:
 * → 4 rai
 * → 4 rai
 * → 215 rai
 * → 15,294 rai
 * → 10,310,000 rai
 * I don't think convert can show the "million" but I suspect something was added to do that without the ugly effect of, but I cannot recall it now. You would need to fiddle with the rounding to exactly match your expected results. Hmm, I just noticed the italics. That's not at Rai (unit) or https://sizes.com/units/rai.htm. Is italics wanted? Johnuniq (talk) 07:12, 6 January 2017 (UTC)
 * Thanks, that was quick. I think it should be in italics per MOS:FOREIGNITALIC, since it's a foreign term not found in English dictionaries. --Paul_012 (talk) 07:31, 6 January 2017 (UTC)
 * My mind was elsewhere. Here is "million":
 * → 10.31 e6rai
 * Re italics, what about the article which does not use italics? The only units convert has in italics are for technical things such as solar mass: M☉ while there are a number of non-English units. For example, tsubo is not in italics in convert, although I see it is in that article. Please ask for guidance at MOS and report the conclusion here. Johnuniq (talk) 09:20, 6 January 2017 (UTC)
 * Okay, thanks a lot. I'll get around to the italics issue, but this is good enough already. --Paul_012 (talk) 10:31, 6 January 2017 (UTC)


 * For italics, hardcode input & use disp=out: To keep italicized units on that page, then just compute the conversion by disp=out in "(__)" as:
 * (7 rai) gives: 7 rai (7 rai)
 * Then if the template is changed to show italic "rai" that page will not be affected. -Wikid77 (talk) 11:14, 12 January 2017 (UTC)


 * I see that the 'abbreviation' (formal symbol) is "r" . However, over here althe symbol already has been implemented as "rai", not r (as the name is):
 * {convert|100|m2|rai|abbr=on} &rarr; 100 m2
 * Methinks a unit symbol never should be italicised by a MOS. -DePiep (talk) 03:34, 14 January 2017 (UTC)
 * Hmm. I've never actually seen the "r" symbol used, but if it can be reliably sourced the template should support it. I agree that it shouldn't be italicised in that case. --Paul_012 (talk) 21:09, 14 January 2017 (UTC)

Ordering for a 3-way conversion
In a 3-way conversion such as 750 PS, I can currently use flip to choose between the default '750 PS' or the weird '750 PS'. In many automobile articles we use metric first but some of the references come in PS or bhp. Is there a way to make it look like '552 kW (750 PS; 740 bhp)' or '552 kW (740 bhp; 750 PS)'? The order inside the brackets is not important but it would be really nice to specific which unit goes before the brackets. Possibly something like 2 to pick kW as the first or a more detailed 2 1 3.  Stepho  talk 05:13, 15 January 2017 (UTC)
 * See Template talk:Convert/Archive September 2016 for a new and flexible procedure.
 * Examples:
 * → 750 PS
 * → 750 PS
 * The idea is that  tells convert to display the output units in the given order; the first output unit is displayed as the "input", and the actual input unit is not displayed unless it is repeated in the output. Johnuniq (talk) 07:07, 15 January 2017 (UTC)

Way to ensure no-break?
At Hyundai Ioniq this template with mpgUS (before "just ahead of the 2016"), gets split across lines, e.g. the substripted US part. Is there a wya to fix it in the template; or a good workaround at the article? I guess a workaround is always bad, as you don't do it unless you have to, and this is always a possibility later with hcanges to preceding text.. comp.arch (talk) 09:07, 21 December 2016 (UTC)
 * @comp.arch: Are you sure that is a problem? A discussion at immediately above suggests there is no problem having a line break between a value and a unit name, and I'm not sure the example you mention could be handled better. At any rate, you can always use no wrap to cause text to not wrap, although whether that is desirable is another question. For example, the next two lines show one of the converts as it is now, and how it would look with "no wrap":
 * Here is a line of wikitext from the article, followed by the same using "no wrap":
 * combined fuel economy between 57 mpgUS and 58 mpgUS, just ahead of the 2016 Toyota Prius Eco (56 mpgUS).
 * combined fuel economy between 57 mpgUS and 58 mpgUS, just ahead of the 2016 Toyota Prius Eco (56 mpgUS).
 * I think the article is fine the way it is, unless a specific problem can be mentioned. Johnuniq (talk) 10:23, 21 December 2016 (UTC)
 * combined fuel economy between 57 mpgUS and 58 mpgUS, just ahead of the 2016 Toyota Prius Eco (56 mpgUS).
 * I think the article is fine the way it is, unless a specific problem can be mentioned. Johnuniq (talk) 10:23, 21 December 2016 (UTC)


 * You can take a look; it did "help", but now the previous line is annoyingly short. Something like  is what I would have wanted, still note in the resulting "58 mpg-US (4.1 L/100 km; 70 mpg-imp)" it was " mpg-imp " that kind of was needed. I'm fairly confident the nowrap could be put (only) in the template, for the latter (and former) place; I'm just not confident I can figure out to how to dig in and change the template myself. comp.arch (talk) 10:37, 21 December 2016 (UTC)

demos and tests
Source text (no has enforced linebreaks): between 57 mpgUS and 58 mpgUS, just ahead of the 2016 Toyota Prius Eco (56 mpgUS).

Box width:10em.
 * using :

between 57 mpgUS and 58 mpgUS, just ahead of the 2016 Toyota Prius Eco (56 mpgUS).
 * not using :

between 57 mpgUS and 58 mpgUS, just ahead of the 2016 Toyota Prius Eco (56 mpgUS).

I do not see why nowrap is needed. Convert values (number + unit) correctly and nicely break when needed. -DePiep (talk) 11:45, 21 December 2016 (UTC)


 * Nowrap isn't needed and it's not the solution to User:Comp.arch's problem. The breaking hyphen is what he was seeing as a problem. --RexxS (talk) 14:22, 21 December 2016 (UTC)

between 57 mpgUS and ...

Breaking at -
The first problem is that this particular conversion produces markup like  → 57 mpg-US which can allow a line-break at the '-' before 'US'. That can look like this: 57 mpg -US

That's really not a good break point. The solution should be to use a non-breaking hyphen,  → &#8209; but I'll let  check that, because I think he keeps the unit symbols elsewhere.

The second problem is that the small subscript is rendered at 68% of the base font size for the page. That's a complete no-no for those of us with elderly eyes and breach of the bright-line 85% rule at MOS:FONTSIZE. --RexxS (talk) 14:24, 21 December 2016 (UTC)
 * I cannot make a line break at the hyphen using two browsers but understand that a hyphen would normally be a good place for a browser to break a line. Let's take this slowly. First I will make a list of all the units with a hyphen in their symbol or name, then we can think about what to do. For experimenting we would add a couple of units to Module:Convert/extra by copying units from Module:Convert/data and adding, for example, "nb" to the unit code. Or perhaps just use the sandbox modules with . A second issue is the small subscript...we can think about that too. Johnuniq (talk) 05:22, 22 December 2016 (UTC)
 * The break at the hyphen occurs for me using Monobook or Vector on Chrome 55, and the same on Opera 42. It doesn't break using Firefox 50 or IE11 - all under Windows 7. I could boot up another few computers and check various combinations of Safari, Edge, Windows 10 and Linux, but I think there's already evidence that some common combinations are showing the OP's problem. (By the way, the small text on IE11 is absolutely microscopic). Let me know if you want me to investigate further. --RexxS (talk) 19:02, 23 December 2016 (UTC)

The following units have a hyphen in the symbol.
 * Update Have struck LTf and STf as the hyphen is in the unit name, not symbol. Johnuniq (talk) 10:35, 23 January 2017 (UTC)

The following unit codes are aliases for units which have a hyphen in the symbol.

Therefore  should be replaced with   (example: g&#8209;mol) in the symbols for the above units. See below for information on units using. Johnuniq (talk) 00:45, 29 December 2016 (UTC)

@RexxS: I'm implementing the unit changes discussed in the last few weeks. When I examined the proposal to replace hyphens in symbols with non-breaking hyphens I noticed that two browsers I tried could not find "g-" (g hyphen) in g&#8209;mol which uses the non-breaking hyphen. The table above shows the units that would be affected. What do people think? Should hyphen be replaced? Or, is breaking search a sufficient problem to not want to do that? Johnuniq (talk) 01:44, 19 January 2017 (UTC)
 * That's a good point and an interesting find. What were the browsers, out of interest? My own preference is functionality over form, so personally I'd go for enabling the search by keeping the standard hyphen, rather than the aesthetic of how the units might display as they break across a line. However, I know that I'm usually in the minority over these sort of issues, so you might want to canvass opinion before deciding. I'll alert as they commented previously. --RexxS (talk) 15:32, 19 January 2017 (UTC)
 * My take: I'd say correct presentation everywhere is better than serving one function in some browsers that do not confirm anyway (if that's correct statement). Breaking at that hyphen looks really bad. (note: g-mol/d is not SI notation; would be an uncommon search-term then; quite extreme, but could the unit with regular hyphen be added as a css id (anchor)? untested I'd say a search would have to find an id...) -DePiep (talk) 15:48, 19 January 2017 (UTC)
 * Two browsers which do not find a non-breaking hyphen when searching for a hyphen are IE 11 and Firefox 50. The issue is academic as the units are rarely used so it does not matter what happens and I just want it settled. I agree that breaking at the hyphen is bad so perhaps using a non-breaking hyphen would be best. Any other views? Johnuniq (talk) 03:27, 20 January 2017 (UTC)
 * Two browsers which do not find a non-breaking hyphen when searching for a hyphen are IE 11 and Firefox 50. The issue is academic as the units are rarely used so it does not matter what happens and I just want it settled. I agree that breaking at the hyphen is bad so perhaps using a non-breaking hyphen would be best. Any other views? Johnuniq (talk) 03:27, 20 January 2017 (UTC)

Module version 16
Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

The changes only involve units—functionality is unchanged. Release notes for earlier versions are listed here. Johnuniq (talk) 09:59, 24 January 2017 (UTC)
 * Removed new unit  (Roman mile) from Module:Convert/extra (unused); it can be restored if needed.
 * Removed new unit  from Module:Convert/extra (unused); see   below if SI prefixes are needed.
 * Removed old  units per this discussion which showed that MBtu is ambiguous and means million BTU in some contexts and thousand BTU in others. The removed unit codes were:
 * Only one article (Exelon Pavilions) was using  in a convert, and it has been edited to use the default output (MJ) instead.
 * Removed old  units as they are unused and are unnecessary clutter. Can be restored if needed. The removed unit codes were:
 * Removed redundant dunam units as they are unused and are unnecessary clutter. Can be restored if needed. Kept  and   which are used. The removed unit codes were:
 * Some unit symbols had a hyphen which could cause some browsers to insert line breaks, splitting the symbol. Each hyphen in a symbol has been replaced with a non-breaking hyphen  per discussion here. The affected unit codes are:
 * Units  and   used the symbol for the name, and the non-breaking hyphen has been used in the names as well.
 * Some unit symbols had small inside sub, such as . The small tags have been removed as they cause some browsers to render the subscript in an illegibly small font. See the discussion here. The affected unit codes are:
 * New unit rai has been added per discussion here.
 * Unit  (torque N·m) now accepts an SI prefix. For example,   can be used (but not  ). An example using fixed wikitext output that will not change follows:
 * → 120 kN·m (89,000 lbf·ft)
 * Some unit symbols had a hyphen which could cause some browsers to insert line breaks, splitting the symbol. Each hyphen in a symbol has been replaced with a non-breaking hyphen  per discussion here. The affected unit codes are:
 * Units  and   used the symbol for the name, and the non-breaking hyphen has been used in the names as well.
 * Some unit symbols had small inside sub, such as . The small tags have been removed as they cause some browsers to render the subscript in an illegibly small font. See the discussion here. The affected unit codes are:
 * New unit rai has been added per discussion here.
 * Unit  (torque N·m) now accepts an SI prefix. For example,   can be used (but not  ). An example using fixed wikitext output that will not change follows:
 * → 120 kN·m (89,000 lbf·ft)
 * New unit rai has been added per discussion here.
 * Unit  (torque N·m) now accepts an SI prefix. For example,   can be used (but not  ). An example using fixed wikitext output that will not change follows:
 * → 120 kN·m (89,000 lbf·ft)
 * Done. Johnuniq (talk) 02:32, 27 January 2017 (UTC)