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 Johnuniq have an other sugegstion? -DePiep (talk) 19:01, 23 December 2016 (UTC)

Research could start in Category:Convert templates. -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)

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 Wikid77 related to comparing {{Convert}} (Lua code) results with {{Convert/old}} (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 [1]. 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 [2]. 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. {{Convert/old}} 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}:

• {convert |105 |-|106 |F |C} —> 105–106 °F (41–41 °C) -- AA
• {convert-old|105|-|106|F|C} —> 105–106 °F (40.6–41.1 °C)

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:

• {convert|43|-|45|lb|kg} —> 43–45 pounds (20–20 kg) -- BB
• {convert-old|43|-|45|lb|kg} —> 

The problem had also appeared in multi-output values, converting one unit into two other units:

• {convert|36|-|37|g |oz ozt} —> 36–37 grams (1.3–1.3 oz; 1.2–1.2 ozt) -- CC
• {convert-old|36|-|37|g|oz ozt} —> 36–37 grams (1.27–1.31 oz; 1.16–1.19 ozt)

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 |111 |-|113 |mm|in} —> 111–113 millimetres (4.4–4.4 in) -- DD
• {convert-old|111|-|113|mm|in} —> 
• {convert |113 |-|114 |oz|lb} —> 113–114 ounces (7.1–7.1 lb) -- EE
• {convert-old|113|-|114|oz|lb} —> 
• {convert |27 |-|28 |ozt|lb} —> 27–28 troy ounces (1.9–1.9 lb) -- FF
• {convert-old|27|-|28|ozt|lb} —> 
• {convert |37 |-|39 |USfloz|USqt} —> 37–39 US fluid ounces (1.2–1.2 US qt) -- GG
• {convert-old|37|-|39|USfloz|USqt} —> 
• {convert |0.113 |-|0.114 |oz|lb} —> 0.113–0.114 ounces (0.0071–0.0071 lb) -- HH
• {convert-old|0.113|-|0.114|oz|lb} —> 

• {convert |5283 |-|5287 |ft|mi} --> 5,283–5,287 feet (1.0006–1.0013 mi) -- II
• {convert-old|5283|-|5287|ft|mi} --> [same]
• {convert |5283 |-|5286 |ft|mi} --> 5,283–5,286 feet (1.0006–1.0011 mi) -- JJ
• {convert-old|5283|-|5286|ft|mi} -->

• {convert |27 |to|29 |mm|in} —> 27 to 29 millimetres (1.1 to 1.1 in) -- KK
• {convert-old|27|to|29|mm|in} —> 
• {convert |189 |-|189.1 |cm|in} —> 189–189.1 centimetres (74.4–74.4 in) -- LL
• {convert-old|189|-|189.1|cm|in} —> 
• {convert |188 |-|188.1 |ft|m} —> 188–188.1 feet (57.3–57.3 m) -- MM
• {convert-old|188|-|188.1|ft|m} —> 

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)

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#Converting feet and inches into meters". 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 (41–41 °C). Range interval = 1, ucf °F → °C is 1 °F (0.556 °C).

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, |disp=out:

... {convert|105|F|C|disp=out} → 105–106 °F (41 °C)

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 ounces (7.1–7.1 lb) (sigfig=4: 113–114 ounces (7.062–7.125 lb))

114–115 ounces (7.1–7.2 lb) (sigfig=4: 114–115 ounces (7.125–7.187 lb))

115–116 ounces (7.2–7.3 lb) (sigfig=4: 115–116 ounces (7.187–7.250 lb))

116–117 ounces (7.3–7.3 lb) (sigfig=4: 116–117 ounces (7.250–7.313 lb))

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 [3]. I'm sorry, Wikid77. 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 m², 69,000 sq ft) to 215 rai (34.9 ha, 86.2 acres) to 15,294 rai (24.470 km², 9.4481 sq mi) and 10.31 million rai (16,500 km², 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:

• {{convert|4|rai}} → 4 rai (6,400 m²)
• {{convert|4|rai|m2 sqft}} → 4 rai (6,400 m²; 69,000 sq ft)
• {{convert|215|rai|ha acre}} → 215 rai (34.4 ha; 85 acres)
• {{convert|15,294|rai|km2 sqmi}} → 15,294 rai (24.470 km²; 9.448 sq mi)
• {{convert|10,310,000|rai|km2 sqmi}} → 10,310,000 rai (16,500 km²; 6,370 sq mi)

I don't think convert can show the "million" but I suspect something was added to do that without the ugly effect of 10.31e6, 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":

• {{convert|10.31|e6rai|km2 sqmi}} → 10.31 million rai (16,500 km²; 6,370 sq mi)

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'' ({{convert|7|rai|m2|disp=out}}) gives: 7 rai (11,000 m²)

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" [4]. However, over here althe symbol already has been implemented as "rai", not r (as the name is):
• {convert|100|m2|rai|abbr=on} → 100 m² (0.063 rai)

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 {{convert|750|PS|kW bhp|abbr=on|0}}, I can currently use |order=flip to choose between the default '750 PS (552 kW; 740 bhp)' or the weird '552 kW; 740 bhp (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 |order=2 to pick kW as the first or a more detailed |order=2 1 3.  Stepho  talk  05:13, 15 January 2017 (UTC)

See Template talk:Convert/Archive September 2016#order=out for a new and flexible procedure.

Examples:

• {{convert|750|PS|kW PS bhp|0|abbr=on|order=out}} → 552 kW (750 PS; 740 bhp)
• {{convert|750|PS|kW bhp PS|0|abbr=on|order=out}} → 552 kW (740 bhp; 750 PS)

The idea is that order=out 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 #Non-breaking space 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":

{{convert|57|mpgUS|abbr=on}}

{{nowrap|{{convert|57|mpgUS|abbr=on}}}}

Here is a line of wikitext from the article, followed by the same using "no wrap":

combined fuel economy between 57 mpg_‑US (4.1 L/100 km; 68 mpg_‑imp) and 58 mpg_‑US (4.1 L/100 km; 70 mpg_‑imp), just ahead of the 2016 Toyota Prius Eco (56 mpg_‑US (4.2 L/100 km; 67 mpg_‑imp)).

combined fuel economy between 57 mpg_‑US (4.1 L/100 km; 68 mpg_‑imp) and 58 mpg_‑US (4.1 L/100 km; 70 mpg_‑imp), just ahead of the 2016 Toyota Prius Eco (56 mpg_‑US (4.2 L/100 km; 67 mpg_‑imp)).

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 {{convert|57|{{nowrap|mpgUS}}|abbr=on}} is what I would have wanted, still note in the resulting "58 mpg-US (4.1 L/100 km; 70 mpg-imp)" it was "{{nowrap|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 {{convert|57|mpgUS|abbr=on}}
and {{nowrap|{{convert|58|mpgUS|abbr=on}}}},
just ahead of the 2016 [[Toyota Prius Eco]] ({{convert|56|mpgUS|abbr=on}}).

Box width:10em.

using {{nowrap}}:

between 57 mpg_‑US (4.1 L/100 km; 68 mpg_‑imp) and 58 mpg_‑US (4.1 L/100 km; 70 mpg_‑imp), just ahead of the 2016 Toyota Prius Eco (56 mpg_‑US (4.2 L/100 km; 67 mpg_‑imp)).

not using {{nowrap}}:

between 57 mpg_‑US (4.1 L/100 km; 68 mpg_‑imp) and 58 mpg_‑US (4.1 L/100 km; 70 mpg_‑imp), just ahead of the 2016 Toyota Prius Eco (56 mpg_‑US (4.2 L/100 km; 67 mpg_‑imp)).

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 mpg_‑US (4.1 L/100 km; 68 mpg_‑imp) and ...

Breaking at -

The first problem is that this particular conversion produces markup like 57 mpg<sub><small>-US</small></sub> → 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, ‑ → ‑ but I'll let Johnuniq 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 {{convert/sandbox}}. 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.

Unit code	Type	Symbol	Symbol for sp=us (if different)
g-mol	chemical amount	g-mol
lb-mol	chemical amount	lb-mol
mpge	energy per unit length	mpg-e
LTf	force	long ton-force
STf	force	short ton-force
mpgimp	fuel efficiency	mpg<sub><small>-imp</small></sub>
mpgus	fuel efficiency	mpg<sub><small>-US</small></sub>
pre1954U.S.nmi	length	(pre-1954&nbsp;U.S.) nmi
pre1954USnmi	length	(pre-1954&nbsp;US) nmi	(pre-1954&nbsp;U.S.) nmi
g-mol/d	molar rate	g-mol/d
g-mol/h	molar rate	g-mol/h
g-mol/min	molar rate	g-mol/min
g-mol/s	molar rate	g-mol/s
lb-mol/d	molar rate	lb-mol/d
lb-mol/h	molar rate	lb-mol/h
lb-mol/min	molar rate	lb-mol/min
lb-mol/s	molar rate	lb-mol/s
Ns/kg	speed	N-s/kg
kNs/kg	speed	kN-s/kg

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.

Unit code	Target
mpg-e	mpge
mpgUS	mpgus
mpgU.S.	mpgus
mpgu.s.	mpgus

Therefore - should be replaced with ‑ (example: g‑mol) in the symbols for the above units. See #Units using small tag below for information on units using <small>. 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‑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)

@Johnuniq: 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 @Comp.arch and DePiep, 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)

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.

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • different (diff)
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

The changes only involve units—functionality is unchanged.

• Removed new unit romi (Roman mile) from Module:Convert/extra (unused); it can be restored if needed.
• Removed new unit kN.m from Module:Convert/extra (unused); see Nm below if SI prefixes are needed.
• Removed old MBtu 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:

  MBtu MBTU-39F MBtu-39F MBTU-59F MBtu-59F MBTU-60F MBtu-60F MBTU-63F MBtu-63F MBTU-ISO MBtu-ISO MBTU-IT MBtu-IT MBTU-mean MBtu-mean MBTU-th MBtu-th

  Only one article (Exelon Pavilions) was using MBtu in a convert, and it has been edited to use the default output (MJ) instead.

• Removed old MMBtu-xxx units as they are unused and are unnecessary clutter. Can be restored if needed. The removed unit codes were:

  MMBTU-39F MMBtu-39F MMBTU-59F MMBtu-59F MMBTU-60F MMBtu-60F MMBTU-63F MMBtu-63F MMBTU-ISO MMBtu-ISO MMBTU-IT MMBtu-IT MMBTU-mean MMBtu-mean MMBTU-th MMBtu-th

• Removed redundant dunam units as they are unused and are unnecessary clutter. Can be restored if needed. Kept dunam and dunum which are used. The removed unit codes were:

  Cypriot donum • Cypriot donum diaeresis • Cypriot donum dots • Cypriot dunam • Cypriot dunum • Cypriot dönüm

  donum • donum diaeresis • donum dots • dönüm

  Iraqi donum • Iraqi donum diaeresis • Iraqi donum dots • Iraqi dunam • Iraqi dunum • Iraqi dönüm

  metric donum • metric donum diaeresis • metric donum dots • metric dunam • metric dönüm

  old donum • old donum diaeresis • old donum dots • old dunam • old dunum • old dönüm

• 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:

  g-mol lb-mol mpge mpgimp mpgus mpgu.s. mpgU.S. pre1954U.S.nmi pre1954USnmi g-mol/d g-mol/h g-mol/min g-mol/s lb-mol/d lb-mol/h lb-mol/min lb-mol/s Ns/kg kNs/kg

  Units Ns/kg and kNs/kg 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 mpg<sub><small>-US</small></sub>. 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:

  mpgimp mpgus mpgU.S. mpgu.s.

• New unit rai has been added per discussion here.
• Unit Nm (torque N·m) now accepts an SI prefix. For example, kNm can be used (but not kN.m). An example using fixed wikitext output that will not change follows:
• {{convert|120|kNm|abbr=on}} → 120 kN·m (89,000 lbf·ft)

Release notes for earlier versions are listed here. Johnuniq (talk) 09:59, 24 January 2017 (UTC)

• Done. Johnuniq (talk) 02:32, 27 January 2017 (UTC)