Template talk:Convert/Archive 2

• Regarding {{Convert}} the topic is closed, OK. However, I'd like to learn some more from this thread. Al lot of people put a lot of info in this. So, to consolidate, for when this is pulled from the archives, let's evaluate. -DePiep (talk) 23:44, 26 October 2020 (UTC)

I notice at

Thanks, I added terajoule and gigajoule as links (megajoule and kilojoule already existed). That will go live when I next update the modules, which I'd better do in the next week or two. Johnuniq (talk) 03:02, 17 August 2020 (UTC)

The Convert template handles absolute temperatures just fine:

"The mean winter temperature in Smallville is {{convert|3|C|F}}." yields "The mean winter temperature in Smallville is 3 °C (37 °F)."

But Convert cannot handle temperature differences correctly:

"The mean annual temperature in Smallville has increased by {{convert|3|C|F}} in the last century." yields "The mean annual temperature in Smallville has increased by 3 °C (37 °F) in the last century." which is nonsense. The correct conversion would be: "The mean annual temperature in Smallville has increased by 3°C (5.4°F) in the last century."

I noticed this error in the article about Kuujjuaq. I fixed it there by simply removing the Convert template in cases where the temperature being referenced is a difference, and doing the conversion manually. I haven't searched, but I wouldn't be surprised if this mistake has come up in many articles, such as in coverage of global warming.

I can't think of an elegant way to fix this. Perhaps a mechanism like this could be implemented: {{convert|n|deltaC|deltaF). But that would require some serious work on the Convert help page, and would still probably confuse many editors. I have little experience with templates, maybe someone with more experience could suggest a better idea. STarry (talk) 07:22, 14 September 2020 (UTC)

@STarry: it already handles this (Template:Convert#Units of difference: Expressing a change or difference in temperature) :

• {{convert|3|C-change|F-change}}: 3 °C (5.4 °F)
• {{convert|3|C|F}}: 3 °C (37 °F)

Imzadi 1979 → 07:33, 14 September 2020 (UTC)

Any idea how I should handle the following unit: Pounds of coal per indicated horsepower hour

This is a measure of the fuel efficiency of early steamships and appears in SS Carnatic. Carnatic and Agamemnon both achieved a massive stepwise improvement in efficiency (though the higher boiler pressure of SS Agamemnon (1865) became the model for immediate future development).However, in discussing this, the units look clumsy and are not friendly to anyone used to modern units.ThoughtIdRetired (talk) 20:01, 16 September 2020 (UTC)

I don't think convert can help with that—there are some strange energy and power units but nothing related to burning coal. All that could be done would be a manual conversion. I imagine the unit is a crude measure with no precise conversion available (for example, different samples of one pound of coal probably release different amounts of energy when burned). The "indicated horsepower-hour" could be converted with something like this:

• {{convert|1|hph|kWh|adj=pre|indicated}} → 1 indicated horsepower-hour (0.75 kWh)
• {{convert|1|hph|kWh|adj=pre|indicated|spell=in}} → one indicated horsepower-hour (0.75 kWh)
• {{convert|1|hph|kWh|disp=out}} → 0.75 kWh

The last would allow something like "2 lbs of coal per indicated horsepower-hour (2 lbs of coal per 0.75 kWh)". Johnuniq (talk) 05:13, 17 September 2020 (UTC)

There are 2240 pounds in a Long Ton (LT). The convert macro does not convert LT-to-ton correctly.

• Ex: {{convert|3900|LT|t}} incorrectly yields 4,000 tons, not 4,368 tons. Proof: 3,900 long tons (4,000 t)
• Ex: {{convert|2100|LT|t}} incorrectly yields 2,100 tons, not 2,352 tons. Proof: 2,100 long tons (2,100 t)
• See Propulsion section of the IJN aircraft carrier Akagi.

How to fix? Or can someone else correct the conversion? 50.107.153.113 (talk) 21:23, 17 September 2020 (UTC)

N/m. I see the authors in many pages are specifying an incorrect abbreviation, using "t" instead of "ST". Le sigh.

• Ex: {{convert|3900|LT|ST}} more correctly yields 4,400 tons, not 4,368 tons. Proof: 3,900 long tons (4,400 short tons)
• Ex: {{convert|2100|LT|ST}} more correctly yields 2,400 tons, not 2,352 tons. Proof: 2,100 long tons (2,400 short tons)

I guess the next question is if this "rounding" is desired?

50.107.153.113 (talk) 21:29, 17 September 2020 (UTC)

To be clear:

{{convert|3900|LT|ST|abbr=off|}} → 3,900 long tons (4,400 short tons)

{{convert|2100|LT|ST}} → 2,100 long tons (2,400 short tons)

→ 3,900 long tons (4,400 short tons)

-DePiep (talk) 21:33, 17 September 2020 (UTC)

Rounding can be controlled:

{{convert|3900|LT|ST|abbr=off|0}} → 3,900 long tons (4,368 short tons)

{{convert|2100|LT|ST|0}} → 2,100 long tons (2,352 short tons)

Or through the use of the sigfig or round options. Editors at the article in question should decide how much rounding is appropriate.  Stepho  talk  22:13, 17 September 2020 (UTC)

Everyone who worked on this Temp really knows what they're doing. I'm very impressed. Invasive Spices (talk) 22:41, 2 October 2020 (UTC)

It's really true. People don't appreciate it until something goes wrong. EEng 11:13, 28 November 2020 (UTC)

{{long ton|166| 6| 2}} 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t) does not work but this {{long ton|166| 6}} 166 long tons 6 cwt (372,500 lb or 169 t) does work. Talk:South Australian Railways 700 class (steam)#A flaw? Peter Horn User talk 00:43, 22 November 2020 (UTC)

That is due to how {{Long ton}} operates (it does not use convert). The fix appears to be to omit the spaces:

• {{long ton|166|6|2}} → 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t)

Johnuniq (talk) 01:18, 22 November 2020 (UTC)

 Fixed Added {{trim}} to all unnamed parameters. Demo example in OP does not show error anymore ;-) -DePiep (talk) 13:16, 28 November 2020 (UTC)

I've been impressed with how developed and flexible this template is. Ultimately, I assume that the place we want to end up is with an option in user preferences that allows choosing a unit/currency/etc. system, so that a British reader could see meters even when reading a U.S. article and a U.S. reader feet even when reading a British one, without the clutter of the other unit. How far are we from making this a reality? Is it just a matter of doing some complicated programming, or are there particular obstacles from the way articles are written, or are there editorial concerns about e.g. fracturing the encyclopedia? {{u|Sdkb}} ^talk 18:49, 21 September 2020 (UTC)

• I see issues:

• The same issues arise as with the old date autoformatting system. Basically, the only people who can benefit are logged-in users. For readers without accounts, it is worse than the status quo because the logged-in editors will just use their preferred unit and assume it will autoformat. For the logged-out reader, this may end up with a hodgepodge of different units in the same contexts in the same sentence.
• Some users are likely to prefer a set of units that does not consistently follow one system or the other. For example, they might measure their distance in miles but their temperature in Celsius (this is pretty standard in Britain). There's going to have to be a long list of preferences.
• In some contexts it will be preferable to override the user preference because it does not make sense in context. It will not necessarily be easy to identify these cases.

Kahastok talk 20:14, 21 September 2020 (UTC)

• Hugely contentious policy questions, hugely complicated design questions, huge investment of development resources desperately needed for other stuff. Besides, exposing readers to corresponding units in multiple systems, side by side, has educational value. EEng 20:26, 21 September 2020 (UTC)

Another issue: I might use a meter to measure 5 metres! Martin of Sheffield (talk) 20:45, 21 September 2020 (UTC)

• The reason this won't happen with the current MediaWiki software and server situation concerns caching of the results of rendering a page (converting the wikitext to HTML that is sent to the reader). There are "read only" servers dedicated to feeding HTML to people viewing pages. They have certain abilities that I know nothing about concerning customizing core features like the user links at the top right for a logged-in user, but the HTML of the page is essentially fixed. It would be possible for logged-in readers to run personal scripts that replaced words but that would have many flaws. Regarding the issue (the horror of showing meters/metres to someone who only wants to see feet, or vice versa), I think one of the charms of Wikipedia is that it demonstrates that the world is a big place and not everyone is same as you. In fact, some people spell words in a funny way and use crazy units. Johnuniq (talk) 23:44, 21 September 2020 (UTC)

  That last bit is an expanded version of my last point above. Absolutely right. EEng 02:56, 22 September 2020 (UTC)

  And the number of people who spell words in a funny way and use crazy units is always one more than you think. --RexxS (talk) 19:49, 22 September 2020 (UTC)

  I now see why the covert would write 1 mile (1.6 km) or 1 pound (0.5 kg). That is preferred behavior. De reverse is not 0.5 kilograms (2 lbs) or 1.6 kilometers (1 mi) is not the right way to do it. In the metric system, the number of unit is limited and known. So it should be 1.6 km (1 mi) or 0.5 kg (1 lbs). I know abbr=on will get this behavior (it should always be turned on, unless very limited decisions to turn it of when metric is the given value). Also, on purpose write the meter and the grams. Note that a lot of the other spelling concerns would be gone use the metric units only. Take a look at e.g., the German versions and see how the text flows with metric units abbreviated. — Preceding unsigned comment added by Frankk20168 (talk • contribs) 11:02, 9 November 2020 (UTC)

  @

  talk

  ) 16:21, 9 November 2020 (UTC)

  @Frankk20168: Actually, 1.6 kilometres (1 mi) is exactly the right way to do it on first occurrence. We spell out the unit name, like "kilometre", on its first use in case the reader is not familiar with the abbreviation and therefore they have a full unit name to look up. We add a parenthetical conversion every time because a reader may be familiar with an imperial unit, but not the metric unit (or vice-versa). As we are providing the conversion specifically for those who are already familiar with the alternative unit, there's no point in spelling out its full name, as the abbreviation will clearly suffice. This probably needs writing into a FAQ. --RexxS (talk) 23:27, 9 November 2020 (UTC)

@RexxS I understand where you are coming from, but ISO and even the US dept. of commerce do not agree. I am just copying the text for simplicity

https://physics.nist.gov/cuu/pdf/sp811.pdf section 7.6 This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible . This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using — the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and — the symbols for the units, not the spelled-out names of the units. Examples:

• the length of the laser is 5 m -- but not: the length of the laser is five meters
• the sample was annealed at a temperature of 955 K for 12 h -- but not: the sample was annealed at a temperature of 955 kelvins for 12 hours

--end-quote -- Bold added by me.--
The bold should be enough to use the symbols, not the full text. A couple of points to add: We are not introducing a meter (m) as this is known and understood. However a concept like Performance Management (PM) would still be introduced in this manner. Also, I would like to just point out that saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m. If that m truly has to be introduced, then the first mention should be 5 meter (m). Note that I also changed the 5 meters into 5 meter (5 meters is not allowed for sure). Hence 5 m works easier and better, because you can read it the way you want even as five metres if you want. My only additional advice would be to avoid d(deci), D(Deka) and H(Hecto) at all cost to make the text readable. Stick to micro, milli, kilo and Mega. Note that I strategically forgot to mention centi. Should not be used in this logic, but is just to pervasive to ignore in the older UOMs. I am actually not trying to create a huge stir here. But abbr=on should be used and not using it the first time does not add value and so abbr=on should be used for all. Also keep text readable by not using 0.5 km (1,640.4 ft) however true this statement is. It creates an assumption of precision in the translated unit that was not there in the original UOM. So wiki does this almost correct with 0.5 km (1,600 ft); just don't add |0 or |1 as I see very often — Preceding unsigned comment added by Frankk20168 (talk • contribs) 07:03, 28 November 2020 (UTC)

Whether or not units should be abbreviated at Wikipedia is not a matter for this template. Instead, it's a manual of style issue:

MOS:UNITS. Johnuniq (talk

) 08:38, 28 November 2020 (UTC)

@Frankk20168: When the folks at ISO and the US dept. of commerce start writing encyclopedia articles for an audience that specifically consists of readers from many different countries who may or may not be familiar with metric or Imperial units, then we can start taking some notice of them. Their advice to always use unit symbols runs completely counter to their intent to "allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English". Do you seriously contend that someone who only uses metric units will understand what 63 ch means? Language independence is not the principal priority for the English Wikipedia, and there are 300 other language Wikipedias that use their own language. The Spanish Wikipedia can write la longitud del láser es de cinco metros without confusing any Spanish speaker because even those only familiar with Imperial units will be able to work out what cinco metros means. There is absolutely no reason whatsoever that we should not write "the length of the laser is five metres" on the English Wikipedia, although supplying a parenthetical conversion to feet, (16 ft), would be helpful.

I reject your assertion that saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m. because this is not a paper encyclopedia. For a common unit, it doesn't matter so much, but we could write "five

metres" and more importantly, we will write "five chains

" on first use, where the hyperlink for an uncommon unit allows the reader to establish the magnitude of the unit as well as its abbreviation if they are unfamiliar with it. That definitely helps a reader get to grips with 63 ch when they see that at the second mention.

Thanks for the rest of your advice, but grandmas and egg-sucking come to mind. In addition, you're completely wrong about the use of |abbr= for the reasons already rehearsed. When you've actually used Template:Convert, you'll find that it does a really good job of dealing with precision by default and {{convert|0.5|km|ft}} produces 0.5 kilometres (1,600 ft), which is as good a conversion as anyone will want most of the time. There are edge cases where the default precision isn't optimal, but the fixed decimal places option and rounding to a given number of significant figures functionality are available to improve the display in those cases. --RexxS (talk) 13:02, 28 November 2020 (UTC)

Johnuniq)

@Johnuniq: I agree with you that the template in most cases does a great job in convert and makes it at the right significant numbers. A lot of converts have |0 added or sometimes the intent of the statement is missed because of convert (e.g., the thing is about 500 m (1,640 ft) away. The conversion introduces a bit too much significant digits. And I agree that this is user error in this case)

On you ch example, I also agree. That should be introduced. My point is normal SI units should not be introduced. The meter being prime among them. This is what REUTERS has to say about it:

kilogram

Use kg (no full stop, same singular and plural) at all references. To convert to pounds multiply by 2.205.

kilometre

Use km (no full stop, same singular and plural) at all references, except in a phrase such as hundreds of kilometres.

km per hour

First reference, kph on second and subsequent references.

/quote Obviously I have problems with the last statements (the kph part). But I included it to get part of your point in, too. Again, I completely agree to introduce 5 feet and then followed by 10 ft (or even 10') later. or 63 chain and then 60 ch. My contentions was for the basic SI units (And I admit I added basic here for the first time), they should not be spelled out. Introducing 100 kilometer per hour is just a painful read. It also introduces at least two issues: Should it be: 100 kilometer per hour 100 kilometers per hour 100 kilometre per hour 100 kilometres per hour All these four variations get resolved by making it 100 km/h. Again, I agree with most of what you are saying. The above on Si unit L, m, km and kg we have different opinions. I would also like to point out that "15,000 pounds per square inch (100,000 kilopascals)" (An actual copy from a paste from a Wiki page) is a painful read that does not help (Americans know that PSI ha something to do with their tire pressure, it is never spelled out. The 100,000 kilopascals is too much. Both also have the problem of the added s. I realize we will never get on exactly the same page. So here is the summary of my advice (incorporating your feedback):

• Don't introduce commonly known basic SI units (kg, m, km, L)
• Introduce most non-SI units (feet, pound, etc.)
• Don't introduce non-SI units that are solely used in their abbreviated form (PSI, ...)
• for All SI Units, make sure they conform to the ISO standard (No plurals, no period(.) unless it is the end of a sentence)
• If you use SI prefixes, stick to the multiples of 1000, unless strong convention makes the unit still viable (cm).
• Few people will understand / know prefixes beyond giga or below micro

I hope this helps and also creates some reasonable guidelines that can help. — Preceding unsigned comment added by Frankk20168 (talk • contribs) 06:09, 30 November 2020 (UTC)

This is now at WT:Manual of Style/Dates and numbers#Exception for SI Weight and Length. Johnuniq (talk) 08:44, 30 November 2020 (UTC)

Not really about the template itself, but I was reverted at

You mean the source contained both, and one differed from the converted value? Gah4 (talk) 16:53, 8 December 2020 (UTC)

Normally it should be

WP:CALC, but maybe not in every case. Gah4 (talk

) 17:51, 8 December 2020 (UTC)

In a carefully written document, especially a technical document, the number of significant figures is meaningful. If the source gives both systems of measurement, the Wikipedia article should match not only the value, but the number of significant figures. In the case at hand, giving the principal length as 224.0 in (5689.6 mm) would be correct. Giving it as 5689.6 mm (224.0 in) also be correct, if the article is placing metric units first. Giving the length as 5689.6 mm (224 in) would be wrong because it would be a misrepresentation of what the source says. By the way, the OP totally bungled the invocation of the convert template. Jc3s5h (talk) 18:25, 8 December 2020 (UTC)

Assuming it is a carefully written document ... One should not give the convert value with excessive sigfigs compared to the original, though sometimes one more is needed. As above, sometimes the conversion gives too many digits. It would be usual in a technical document to get the number if digits right in the first value given, not necessarily in converted values. I didn't look at what the OP did, though. Better documents give uncertainties instead of depending on the number of digits. (Which is a somewhat rough indicator of precision.) Gah4 (talk) 18:45, 8 December 2020 (UTC)

As I noted in

~300 mainspace uses (with some obvious false positives). It will be practically impossible to find cases split between a template page (as in an infobox). --Izno (talk) 14:14, 8 December 2020 (UTC)

It even found converted to maintenance and machine. Some have the word Mach after an actual template, so maybe should use the template. Gah4 (talk) 17:31, 8 December 2020 (UTC)

@Gah4: That was a lazy search up there. This one is probably more representative. About 200 cases. --Izno (talk) 19:32, 8 December 2020 (UTC)

This template/module uses the visualhide class. It has a TemplateStyles solution and will accordingly be removed from Common.css soon. Your feedback regarding the timeline is requested at MediaWiki talk:Common.css § visualhide removal. Izno (talk) 17:10, 2 December 2020 (UTC)

The usage might be a code copy/paste from {{

frac}}. -DePiep (talk

) 18:09, 2 December 2020 (UTC)

Should the 3 million convert usages output a template style that is used by only 0.4% of them? Where would that templatestyles be placed? Johnuniq (talk) 23:25, 2 December 2020 (UTC)

And what about |disp=table usages and possibly others? Would they work painlessly? Johnuniq (talk) 23:55, 2 December 2020 (UTC)

More info: the above numbers are counts of {{convert}} and {{cvt}} in article wikitext. Those templates are called many more times from infoboxes, for example for a person's height or weight. I'm hoping Izno or someone familiar with templatestyles can say whether adding around 43 bytes of output to every convert would be a problem. Can the module do something magic and only output it if needed?

The following shows a table example with the generated wikitext:

{{convert|47.5|kg|lb|disp=table}} → style="text-align:right;"|47.5\n|style="text-align:right;"|105

Johnuniq (talk) 02:18, 3 December 2020 (UTC)

I had hoped to centralize these questions to

frac

}}. I'll probably copy over this commentary to the MediaWiki talk page.

Since you are worried about the 10s of bytes, I assume you are worried about the Post‐expand include size; maybe you have a different limit in mind. AIUI, TemplateStyles comes out of the budget for Unstrip post‐expand size: N/5000000 (5.0 mega)bytes rather than the Post‐expand include size: M/2097152 (2.1 mega)bytes, which means you have a different budget you have to care about. (Anomie, am I right? Please say yes. :) You pay for emitting the classes, but that is almost always cheaper compared to the inline styles.

Secondly, what occurs with TemplateStyles is that one <style> tag is emitted with the content of the styles, and then any subsequent uses of the TemplateStyles tag emit a <link> tag indicating that the module does not need to emit the styles anymore. This is probably the second way in which it is cheaper.

Yes, the module should only add TemplateStyles for

Template:Frac

. If the expected frame:extensionTag were prepended to where <span class="visualhidesr-only"> were output, I wouldn't expect there to be any fundamental issues.

• In this regard, I have hacked the sandbox and the visual output as well as fundamental HTML of Template talk:Convert/testcases/sandbox1 looks okay; the test failures are because the module does not know how to deal with the strip tokens. I'm not sure where to go to review the other paths through the module since there seems to be a discrepancy in how fracfmt is handled between the two code paths where it is used versus its earlier definition: 1 definition has 3 replaced patterns with %s, the other three have 4; whereas the calling sites expect 4 patterns total. (And anyway, it's a hack in an unfamiliar codebase, so forgive me any sins. ;)

That said, I see opportunity in fracfmt to decrease the output regardless when displaying as a fraction by moving the inline styles there to TemplateStyles and/or from include to unstrip budgets (pending Anomie on the second part). This could either rely on {{

frac}}'s TemplateStyles, or since we're here, a new Module:Convert/styles.css

for the stuff unrelated to sr-only. (I see other places you might entertain a move as well; I count some 10-15 uses of style=.)

I don't really understand why {{

frac

}} is being forked here (frac is heavy? convert is heavy and accordingly dependency-averse? don't know how to call another template?), but this may be a good time to consider un-forking. I would suggest working on that after TemplateStyles are integrated for sronly (so I'm not blocked on removing visualhide ;).

Use in tables should be fine since it looks like Convert always emits a data-sort-value surrounding the contents when used in table form. I do not know how it will do as a naked convert in a sortable table with the style/link elements. TheDJ might have some knowledge there.

Common to the other places visualhide is used, I do not know how many uses of Convert with a fraction are internal to links. I would guess none, or sufficiently few as to be worked around if people have issues, but you probably know more than me about that.

(Aside: {{

frac

}} does not match].)

--Izno (talk) 04:20, 3 December 2020 (UTC)

Thanks, I'll chew on that. If the module can output something if it thinks it is needed, a hack can certainly be added. Re forking frac, I was never sure that convert would actually work when developing it (because it does such a massive amount of work to replace the 4,000 templates formerly used). Therefore it was easier and much more efficient to include what was needed in the module rather than expanding other templates. One of the issues at the time was that convert sometimes hit template limits, and that's years ago when there were a lot less converts than now. Johnuniq (talk) 04:36, 3 December 2020 (UTC)

I had browsed WP:TemplateStyles before but not mw:Help:TemplateStyles which it points to. The latter makes it much clearer what is going on. I'll leave that link here for me and anyone else puzzled about what triggers recognition of a template style (answer: it's the right wikitext syntax and can come from anywhere; no template or module are needed). Johnuniq (talk) 06:51, 3 December 2020 (UTC)

frac}} is being forked here" probably to save on transclusion count. Templates like convert are sometimes used hundreds of times on long pages. "Use in tables should be fine since it looks like Convert always emits a data-sort-value surrounding the contents when used in table form." yeah... probably... My biggest worry would be the extra inline tag and how some other templates/modules deal with that. But hard to know those before making a change that surfaces those. —TheDJ (talk • contribs

) 09:11, 3 December 2020 (UTC)

re "why ⁄ is being forked here" (TheDJ). Don't know about {{Convert}}, but in {{Track gauge}} I did so to remove the nowrap tag, since nowrap was needed only once enveloping all of "7+1⁄2 ft".

While I am here: {{

frac}} is in view, but please note that {{sfrac}} uses the "+" not a space. -DePiep (talk

) 14:20, 3 December 2020 (UTC)

@Izno: I did a little experimenting, it looks like TemplateStyles counts towards 42 bytes of the post-expand include size (for the strip marker). Unstripped, every use counts the whole size of the (minified) stylesheet; TemplateStyles itself emits a <style> for every use and they're then deduplicated, and apparently the unstrip size is measured before deduplication. Anomie⚔ 17:02, 3 December 2020 (UTC)

@Izno: Re Module:Convert/sandbox: Sorry that I have ignored the issue due to normal turmoil. However, I think about what should be done and I have a plan for handling styles in convert. I should get around to it in the next couple of days. Another plan I've had for years is to fix Module:Convert/tester so it changes the unique number in strip markers to be, say, all zeroes so the comparisons won't break. Johnuniq (talk) 23:40, 11 December 2020 (UTC)

Johnuniq, no worries. I was just looking at ignoring templatestyles strip markers before I was called away, like is done in module:UnitTests, since they're of trivial interest even when they are expanded from strip marker. --Izno (talk) 00:32, 12 December 2020 (UTC)

As of now though, this is the only template I'm waiting on; I spent a couple hours today moving the other templates of interest away from depending on visualhide. --Izno (talk) 00:34, 12 December 2020 (UTC)

I'll record here that I tweaked Module:Convert/tester to normalize strip markers but on checking the effect I realize that the method is broken. It probably would work as a comparison but it won't display the Expected results correctly because the strip markers have been replaced with fake ones. I'll contemplate what to do about that. Johnuniq (talk) 09:02, 12 December 2020 (UTC)

...the "calculate" template ? EOLE79 (Talk ?) 10:28, 12 December 2020 (UTC)

It would be useful if this template could be used to define the thousands separator differently for each converted unit. For instance, when using the template to convert AU to both km and mi, it would be nice to be able to specify gap for kilometers and comma for miles, as gaps are not usually used for miles but are for kilometers, especially for science-related articles like one using AU. Lexicon (talk) 19:51, 26 October 2020 (UTC)

Could you provide exemplary articles with this? -DePiep (talk) 20:02, 26 October 2020 (UTC)

The use in the third paragraph here is what got me thinking about this. There must be many uses of the template converting AU to km and mi in astronomy articles (there are two more in that one article). How many uses other than for AU there are, though, I'm unsure. Lexicon (talk) 20:15, 26 October 2020 (UTC)

The example from there (without the redundant |lk=off) is:

• {{convert|0.1|AU|km mi|abbr=on}} → 0.1 AU (15,000,000 km; 9,300,000 mi)
• {{convert|0.1|AU|km mi|abbr=on|comma=gaps}} → 0.1 AU (15000000 km; 9300000 mi)

The second convert shows how it would look with gaps, and here is how it is wanted:

0.1 AU (15000000 km; 9,300,000 mi)

I'm unsure whether that would be useful. Johnuniq (talk) 23:09, 26 October 2020 (UTC)

• I question the assertion that gaps are not usually used for miles but are for kilometers. In my experience they're independent issues, and the mixed format above looks wretched. EEng 23:42, 2 December 2020 (UTC)

The space separator is used in french !

The apos is used in calculators !

EX : 7786554443 is 77 866 554 443 (french) or 77'866'554'443 (calculators). EOLE79 (Talk ?) 10:40, 12 December 2020 (UTC)

That's one of the problems with buying cheap foreign calculators. --RexxS (talk) 22:25, 12 December 2020 (UTC)

The space separator is also used in Australian English.[1] Which shows that it is not an English vs French thing.  Stepho  talk  23:39, 12 December 2020 (UTC)

I suspect it is not really a miles uses commas vs km uses spaces thing but rather a timing thing. Many countries (such as Australia) changed thousands separators from comma to space about the same time that they change from imperial to metric. Thus, older books used miles with commas and no km at all, while newer books used km with spaces and no miles at all. So, false dichotomy.  Stepho  talk  23:49, 12 December 2020 (UTC)

Hello, I ran into this (aesthetic) problem on Brick while editing the per-country dimensions of a brick in a table, partially reproduced here:

EXAMPLE TEMPORARILY DISABLED BECAUSE IT WAS SENDING THE RENDERING SOFTWARE INTO ORBIT

Using "lk=on|disp=table|abbr=on" (first row) gives me the unit on each of the measurements. Ideally, I'd like "25 × 50 × 75 mm (1 × 2 × 3 in)", but this doesn't quite work when I try it with other flags.

• {{convert|225|×|112.5|×|75|mm|in}} → 225 by 112.5 by 75 millimetres (8.86 in × 4.43 in × 2.95 in)
• {{convert|225|×|112.5|×|75|mm|in|abbr=on}} → 225 mm × 112.5 mm × 75 mm (8.86 in × 4.43 in × 2.95 in)

It seems adding "abbr=on" forces the separation to use "×", but also displays the units on every number instead of the last one. I suspect "disp=table" hides the units altogether, but combining it with another flag like "lk=on" or "abbr=on" overrides that. Can we change "abbr=on" to only display units on the final number? This seems inconsistent.-Ich (talk) 16:04, 11 December 2020 (UTC)

• MOS:UNITNAMES has some fussy provisions on this which I'm not sure are for the best. In particular, I don't know why it's OK to write 8 by 6 by 4 millimeters but not 8 x 6 x 4 millimeters -- MOS wants you to write, instead, 8 millimeters x 6 millimeters x 4 millimeters, which seems excessive. EEng
  17:05, 11 December 2020 (UTC)

  Isn't that only with unit symbols (mm)? Johnuniq (talk) 23:11, 11 December 2020 (UTC)

  No, for some reason the guideline wants it to depend not on mm vs. millimeters but rather on x vs. by. With by you're allowed to just say the unit (whether mm or millimeters) once at the end (or every time, if you want), but with x you're supposed to append the unit to every value. Like I said, not sure why it's that way or whether it really needs to be that way. So before changing {convert} to conform (if that's what's your nimble little coding fingers are itching to do) let's be sure the guideline is really what we want. EEng 23:49, 11 December 2020 (UTC)

  Oh. It looks like convert avoids that issue by switching to "by" when the unit name is used. And I'm far too lazy to want to change code that's been stable for eras. Johnuniq (talk) 00:29, 12 December 2020 (UTC)

  FOR GOODNESS' SAKE DON'T SAY ERAS. YOU'LL HAVE THE BC/BCE WARRIORS COMING OUT OF THE WOODWORK. EEng 00:47, 12 December 2020 (UTC)

  No need to

  WP:SHOUT at us, EEng. -DePiep (talk

  ) 22:31, 12 December 2020 (UTC)

  I wasn't addressing you so please butt out. [2] EEng 01:42, 13 December 2020 (UTC)

• Why not use {{convert|230|×|110|×|76|mm|in|disp=table}} like most other tables do? The units are in the heading and should not be repeated in each row. There is no need to link mm or inches, but if really needed, there is sure to be somewhere close by in the text (not in the table) where that could be done. Or, the unit names in the heading could be linked. However, convert retains two seldom-used features that are available if really really needed. There is no repeated unit symbol with * or xx. * outputs × with no spacing, while xx outputs × with a nonbreaking space on each side. You would use one of these in a table:

  {{convert|230|*|110|*|76|mm|in|lk=on|disp=table|abbr=on}}

  {{convert|230|xx|110|xx|76|mm|in|lk=on|disp=table|abbr=on}}

You can add "mm" after each convert if really wanted.

By the way, use x not × in convert. The former is easy to type and easy for other editors to emulate. It gives the same output as ×. Johnuniq (talk) 23:11, 11 December 2020 (UTC)

In the lead for Europe, I noticed the slightly jarring juxtaposition of 10,180,000 km² (3,930,000 sq mi), where the kilometers uses "²" but the miles uses "sq". Looking at the documentation here, it seems to be a U.S. vs. UK thing, but from my experience, "²" is generally more popular in America, too. Have we considered just going to "²" for all uses? {{u|Sdkb}} ^talk 07:11, 13 December 2020 (UTC)

For a contrasting view, see Template talk:Convert/Archive 1#The unspeakable criminality of in2 by Archon 2488. Johnuniq (talk) 08:47, 13 December 2020 (UTC)

I'd also make the point that there are slight

MOS

implications, specifically,

sq or cu may be used with US customary or imperial units, but not with SI units.

This sentence is not prescriptive (or, indeed, proscriptive), but it does explicitly permit the use of "sq" and "cu", and I don't feel that it's appropriate to make changes here that would arguably de facto amount to an MOS change. The Europe article mentioned above uses the style in question, I'd presume, because it is the default convert template style – and I'd argue that making something the default convert template style will almost always ipso facto make it the normal style used in the encyclopedia. This is simply because it's the style that the vast majority of editors will default to, even if unknowingly – I presume that most editors don't know there are so many options for customising the exact output of {{convert}}, as I use it extensively and wasn't aware that it was possible to get it to output e.g. "in²" until very recently.

Obviously this is totally subjective, but I don't personally see this juxtaposition as jarring, mainly because it is the style already used in the vast majority of such cases on WP – as for the historical reasons why the template defaults to that style for presenting square and cubic units, I can't comment. In short, if Sdkb wants to formally discourage the use of "sq" and "cu" in all instances, MOSNUM is the place for them to discuss it. Archon 2488 (talk) 11:48, 13 December 2020 (UTC)

An IP user asks about a figure in an article: "Her steel hull had an overall length of 350 feet (110 m) (one source states 358 feet (109 m))" How can 350 feet be 110 m but 358 feet is 109 m? And I say, great question. I look at the article and see that it's getting those values with {{convert}}, videlicet: Her steel hull had an overall length of {{convert|350|ft|m}} (one source states {{convert|358|ft|m}}).

Now, the standard response to this is that precision can be specified when invoking the template, but I don't think this is proper, and especially it's not proper to arbitrarily and invisibly use different rounding based on if the figure ends in a zero. The obvious, and intuitive, use for this template is to do simple arithmetic and multiply feet into meters (indeed, this is how it is used in every article I've seen it). So I had a lively debate with my friend about this, and he pointed out that most uses of "350" or "300" or the like are probably approximate, and giving a precise meter conversion would mislead readers. However, I disagree with the way this has been implemented in the conversion template.

(As someone who's designed and machined parts with some dimensions measured in ten-thousandths of an inch and some dimensions measured in feet, and communicated with both PhDs and CEOs about these parts: when someone writes "350", in the vast majority of cases, it does not mean "350 ± 5" -- and if it does mean the former, they will say "about 350"; the word "about" doesn't have a standardized error bar on it, and I'd almost go so far as to call it

But for concrete suggestions: first of all, my issue with this is not the rounding: 350.00 feet is 106.68 meters, which would be a silly amount of precision to give, and I'd be fine with presenting it as 107. I'd even be fine with the template rounding to significant figures whenever precision wasn't specified. However, the current state of affairs is that the template will round to the nearest meter, unless the number ends in a zero, in which case it will silently make the number ten times less precise, in a way that is never made apparent to the editor or the reader.

Exemplis grata:

1. The building was {{convert|345|ft|m}} tall = "The building was 345 feet (105 m) tall"
2. The building was {{convert|350|ft|m}} tall = "The building was 350 feet (110 m) tall"
3. The building was {{convert|355|ft|m}} tall = "The building was 355 feet (108 m) tall"
4. The building was {{convert|360|ft|m}} tall = "The building was 360 feet (110 m) tall"

If you were an editor and hadn't read five full screens of template documentation (or if you're a Wikipedia reader, who doesn't even know what templates are), would this make sense to you if you saw it in a page? Would it be immediately apparent, if you only saw one of these examples, that every other measurement was being rounded to the nearest 10m and not the nearest 1m?

I think that this is fairly counterintuitive; if the default behavior is to perform different conversions based on the last digit of the number, it should say "approx." or in some way indicate when it's using an alternative conversion scheme. A template should not be making blanket assumptions about the precision of numbers in articles and presenting them as fact. jp×g 01:54, 10 December 2020 (UTC)

It's not an easy problem. For example,

WP:HELPDESK for assistance. Johnuniq (talk

) 03:52, 10 December 2020 (UTC)

@JPxG: You've criticised the way the template handles a problem, but your solution is even worse. Almost all conversions are approximate and scattering "approx" about written prose is very poor style. if you assert that 350 ft has three significant figures and should be treated as 350±1 ft by default, then what should be the default precision for 3500 ft? for 35000 ft? and so on. If you are willing to accept that 35,000,000 ft doesn't imply 35,000,000±1 ft by default, but you still insist that 350 ft has three significant figures, then at what point are you willing to concede that one of those decade multiples has only two significant figures? If you can find an algorithm for determining significant figures that is more robust than "trailing zeros are not significant in integer values", it would useful to hear it. Note that:

1. The building was {{convert|358|ft|m}} tall = "The building was 358 feet (109 m) tall"
2. The building was {{convert|350.|ft|m}} tall = "The building was 350 feet (107 m) tall"

Specifying a decimal value sets the full precision.

Then consider decimal fractions:

1. The model was {{convert|3.45|ft|m}} tall = "The model was 3.45 feet (1.05 m) tall"
2. The model was {{convert|3.50|ft|m}} tall = "The model was 3.50 feet (1.07 m) tall"
3. The model was {{convert|3.55|ft|m}} tall = "The model was 3.55 feet (1.08 m) tall"
4. The model was {{convert|3.60|ft|m}} tall = "The model was 3.60 feet (1.10 m) tall"
5. The model was {{convert|3.5|ft|m|sigfig=3}} tall = "The model was 3.5 feet (1.07 m) tall"
6. The model was {{convert|3.6|ft|m|sigfig=3}} tall = "The model was 3.6 feet (1.10 m) tall"

The default does a pretty good job most of the time, but it's not difficult to set the precision when the default doesn't give the result you want. --RexxS (talk) 15:39, 10 December 2020 (UTC)

I can add, re your post @

WP:HOWTO manufacture parts. That is: don't build your rockets from this webside. -DePiep (talk

) 18:06, 10 December 2020 (UTC)

For many years, if not today, the US auto industry used both. You had to have both sets of wrenches, as you didn't know which one would be needed. If I remember the story, the Chevette was the first US car to be all metric. If some president decides to convert the US to metric, we might be in better shape in not so many years. I was recently working on

sigfigs. Gah4 (talk

) 00:26, 13 December 2020 (UTC)

My preference would be #2 but really both #2 and #3 are valid solutions with similar pros and cons. We can't make everybody happy and the current solution is a very good attempt at making as many people as happy as possible. The only improvement I can think of is to make the rounding issue more prominent in the documentation.  Stepho  talk  00:56, 13 December 2020 (UTC)

But my personal use of convert is likely to be in scuba-related articles, where 350 bar means 350±5 bar and 350 feet means 350±5 feet. If we stick with the current algorithm, the conversions work well for me, and you only need write "350." to force unit precision. If we adopt an algorithm that treats 350 as 350±1 to suit your preference, the conversions work well for you, but I don't have anywhere near as simple a means of getting the precision I need. It's not a symmetrical gain-loss. --RexxS (talk) 01:27, 14 December 2020 (UTC)

This was previously request (

My comment in the linked October 2015 discussion still applies—quite a lot of confusion is possible with short/long/metric tons. A firm proposal is needed: unit codes (wikitext entered in convert); full names of units (abbr=off); symbols of units (abbr=on); links (lk=on). Is there more than one or two articles where they would be used? The references used at

Units of transportation measurement appear to be dime-a-dozen unit converter websites which are happy to make up names and symbols. Is it just short-ton-miles to tonne-kilometers that is wanted? If so, we could add a temporary unit and see if it is used, but details are needed. Johnuniq (talk

) 22:22, 17 December 2020 (UTC)

Just ton-miles to tonne-kilometres. When dealing with road, rail, air or IWT, ton miles are always short tons per statute mile. It is not used in the UK. [3] A Google search restricted to Wikipedia turned up 190 pages. All are related to railways. I got my conversion from the Bureau of Transportation Statistics. In the rare cases when one is dealing solely with shipping, they used deadweight (long) tons per nautical mile. [4] But I haven't observed any instances of this on wikipedia. Hawkeye7 (discuss) 23:17, 17 December 2020 (UTC)

OK, let's do that. But, please propose unit code, symbol, name, link for each. I can handle the kilometre/kilometer issue, and you have specified names. Should there be a symbol (abbr=on)? There does not have to be, but if one is wanted, please specify it. Same for the unit code that would be entered in convert. Is

Units of transportation measurement#Freight the link? I wouldn't try to make the section link more specific because it's title is likely to change every month. Johnuniq (talk

) 23:25, 17 December 2020 (UTC)

There is a stub article

Units of transportation measurement#Transportation quantity. Hawkeye7 (discuss)

00:59, 18 December 2020 (UTC)

I added the units at Module:Convert/documentation/conversion data#Transportation and included them in the module. If these are used in articles in the next couple of days (before the #Module version 25 release above), they will be included in the main data. Otherwise, they will be temporary. Examples (please check!):

• {{convert|1|tkm|6|abbr=on}} → 1 tkm (0.684944 ton-miles)
• {{convert|1|ton-mile|6|abbr=on}} → 1 ton-mile (1.459972 tkm)
• {{convert|1|tkm|abbr=off}} → 1 tonne-kilometre (0.68 ton-miles)
• {{convert|1|ton-mile|abbr=off}} → 1 ton-mile (1.5 tonne-kilometres)
• {{convert|2|tkm|abbr=off|lk=on|sp=us}} → 2
  ton-miles
  )
• {{convert|2|ton-mile|abbr=off|lk=on|sp=us}} → 2
  tonne-kilometers
  )

Johnuniq (talk) 02:40, 18 December 2020 (UTC)

@Hawkeye7: I'm hoping to update convert soon and would prefer to include the new unit, but first it needs to be checked, and it needs to be used in an article. Do you have time for that? Johnuniq (talk) 23:02, 18 December 2020 (UTC)

Sure. I have used it in American logistics in the Northern France campaign. It performed the conversion and the rounding correctly. Very nice. Hawkeye7 (discuss) 05:54, 19 December 2020 (UTC)

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

• Template styles (work by Izno):
  • When convert displays fractions, a certain style is used that make it easier for a screen reader to provide informative text. That style is now in Template:Screen reader-only/styles.css.
  • The implementation inserts the templatestyles 42-byte strip marker at the start of the convert output, but only if required for the fraction being displayed and only once per convert even if more than one fraction is displayed (for example, {{convert|1+1/2|by|5+3/4|in}}).
• Unit changes:
  • Remove gramme from the unit definitions. This is not a change to units as gramme is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future. MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at MOS talk July 2019 following a request here.
  • Remove 23 apparently unused energy units linking to
    Atmosphere (unit) per discussion here
    .
  • Some units from Module:Convert/extra that are used in articles have been copied to the main module.
    • mi/kWh is retained in extra; it will be removed if not found to be used in articles.
    • Occurrences of scf2 and scfoot2 in articles will be replaced with scf and scfoot which have had their link corrected to standard cubic foot. Discussion here.
• Tweaks:
  • Module:Convert/wikidata will use mw.wikibase.getLabel(X) instead of deprecated mw.wikibase.label(X).

Release notes for earlier versions are listed here. Johnuniq (talk) 06:13, 14 December 2020 (UTC)

A couple of questions: Just wondering if the 'Screen reader-only/styles.css' should be stored in a variable in Module:Convert/text to help with use on another wiki? Also, "padding" was changed to "margin" a while ago [6] in {{Sfrac}}. Should it be changed in convert as well? -- WOSlinker (talk) 08:50, 14 December 2020 (UTC)

Thanks, good points. Re convert/text, I did wonder about that and I suppose I should be less lazy. I imagine "margin" should also be used here but the html is over my head. @Izno: Any opinion on that?

Here are some results from Special:ExpandTemplates if anyone wants to compare the outputs.

{{convert/sandbox|1//2|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">1</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">2</span></span> foot (6.0&nbsp;in)

{{sfrac|1|2}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac  nowrap tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">1</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">2</span></span>

{{sfrac/sandbox|1|2}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac tion"><span class="num">1</span><span class="sr-only">/</span><span class="den">2</span></span>

{{convert/sandbox|1+2//3|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap">1<span class="sr-only">&nbsp;</span><span style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">2</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">3</span></span></span> feet (20&nbsp;in)

{{sfrac|1|2|3}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac  nowrap"><span class="int">1</span><span class="plus sr-only">+</span><span class=" tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">2</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">3</span></span></span>

{{sfrac/sandbox|1|2|3}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>

Johnuniq (talk) 09:43, 14 December 2020 (UTC)

I have updated the modules to get the templatestyles title from convert/text for localization at other Wikipedias. The style issue is tricky. The output from {{

frac}} also. Johnuniq (talk

) 23:35, 14 December 2020 (UTC)

As a result of your delay here (thanks :D) I've lately been futzing with moving the styles in frac and sfrac fully into TemplateStyles, which are combined in

Template:Frac/sandbox

. (I've coincidentally removed sub/sup in frac; their use there is not really that appropriate from an HTML perspective.)

Given the domains of the two templates seem exclusive, I have not decided if it makes sense to have one style sheet for them rather than two, but I only simplified what was there, since someone had started taking a look a year ago and seems to have given up on the point for some reason. (It was a rather complex implementation to boot since it assumed the templates were needed for more than they are.)

Consider taking a look. I am not per se minded to make them live immediately, but... I kind of am. :^) --Izno (talk) 03:40, 15 December 2020 (UTC)

I've just spent over half an hour staring in bewilderment at those pages (including your drastic pruning). Experiment found that the output from sfrac was 80 bytes longer than the corresponding output from convert and the need for all those classes is way beyond my comprehension. I decided that Edokter knew what he was doing so replaced "padding" with "margin". I couldn't see any reason for further changes in convert. I'm not sure whether you are hinting that Template:Frac/styles.css should be used by convert. I suppose there aren't that many converts using fractions (although there are a lot) so the templatestyles bloat might not be a problem. But it's extra pain for people trying to copy the current version of convert to another site. Are you wanting more changes to Module:Convert/sandbox or is what it does ok at least for now? That is, should the live convert modules be updated now? Johnuniq (talk) 04:28, 15 December 2020 (UTC)

You can save a little more space by removing the spaces after the semi-colons in the styles, so I've done that in the sandbox. -- WOSlinker (talk) 08:12, 15 December 2020 (UTC)

I'm not sure whether you are hinting that Template:Frac/styles.css should be used by convert. Yes, I'm hinting that. It is by no means required of course, but it should dramatically reduce the implementation here (+- the futzing to make sfrac act as expected because I noticed how it is coded in the frac templates and how it is coded here is marginally different).

But it's extra pain for people trying to copy the current version of convert to another site. I've never really put a lot of stock in this as a rationale for anything on en.WP, and not often do I care too often when the module of interest already has a dozen pages to copy; what's one (two?) more? So long as the documentation is clear about all the used pages (as is usual for larger modules), it's rarely an issue.

is what it does ok at least for now I have no great issues with the now. I do have some issue with the frac implementation, both live/sandbox here and at the template itself, using <sub> and <sup>, and that is why I suggested the sandbox version there to be implemented here now. If you want to play with it some more or want some help understanding what's going on, I wouldn't want to block version 25 on it. --Izno (talk) 18:44, 15 December 2020 (UTC)

As for all the classes, each of them has a reason and it can be seen in the stylesheet itself. They were added a year ago by the user aforementioned in preparation for templatestyling but the templatestyles were never implemented for whatever reason. I did remove two in the sandbox as being essentially immaterial ("plus" and "slash") and then the styles followed into the stylesheet, hence the 'dramatic' reduction. For comparison, I've added the sfrac/sandbox expansion above. --Izno (talk)

I would far prefer to get convert right before releasing a new version. Indeed, the only substantial reason for this release is to clean up fraction handling so let's take a bit more time. Currently, convert/sandbox is using Template:Screen reader-only/styles.css for class sr-only. As I understand it, that would no longer be needed. Instead, Template:Frac/styles.css would be used and much of the HTML in convert would be replaced with css. I'll have a go at that in a few hours or you may like to do it. In 1+2/3, why does convert output a hidden non-breaking space after 1, but sfrac outputs a hidden + (what should convert do)? For my curiosity, what is role="math"? Johnuniq (talk) 23:22, 15 December 2020 (UTC)

About the "+" in sfrac -- only. I don't know about screenreaders ("sr"), but the copy/paste function ("A c/p must produce the same and correct number") should be (ob)served too.

• {{
  frac
  }}:  1+11⁄19 → c/p gives: ​1 11⁄19
• {{sfrac}}: 1+11/19 → c/p gives: 1+11/19

-DePiep (talk) 00:22, 16 December 2020 (UTC)

Ping User:Izno because of [7]. -DePiep (talk) 00:33, 16 December 2020 (UTC)

CSS is not my area so I'm hoping Izno will either fix convert/sandbox or tell me what is wanted. There are three factors: (1) want reasonably short wikitext with a consistent and good displayed result; (2) want it to make sense with screen readers; (3) want copy/paste to give a sensible result. The new Template:Frac/styles.css looks good to me. The generated HTML is a bit long for the first usage on a page, but is not a problem because subsequent usages on that page are short. I can see an argument for space or plus in a copy/paste and I don't see it as a concern, although consistency would be good. Johnuniq (talk) 10:22, 16 December 2020 (UTC)

As I understand it, that would no longer be needed. Yes, that is correct.

In 1+2/3, why does convert output a hidden non-breaking space after 1, but sfrac outputs a hidden + (what should convert do)? I do not know why convert is doing that as a non-breaking space, which is superfluous with the whitespace nowrap CSS variously applied to the same. Regarding space versus plus, sfrac shifted to "+" approximately a year ago in the same edit that added the classes and role. It was noted at the talk page at

Template talk:Frac#Integrity

. I changed the frac sandbox recently to follow since I don't see a good reason for inconsistency. I could personally flip a coin on the pros and cons of + and space character, though I tend toward the semantic + rather than the unsemantic space as my decider. I generally agree with your 3 listed design criteria there.

For my curiosity, what is role="math"? An "ARIA role" is a standardized way to assign an HTML element semantics that differ from its default semantics. For example, if you have a

layout table, you can assign it role="presentation" to indicate that it is not a proper data table per the default HTML semantic assignment for <table> elements (we have a lot of unfortunate legacy on that point, so we've bolted on a lot of role="presentation"). It is primarily intended for enhanced accessibility. See also MDN. role="math" in particular is described as Content that represents a mathematical expression. See the link for more details. Whether sfrac and frac should use it is a question mark to me. Given the context of sfrac, I think it may make sense for sfrac generally. For frac, I can probably buy into it when the fraction is marked up with a hidden +. I wouldn't add it without the + in frac. --Izno (talk

) 21:34, 16 December 2020 (UTC)

Thanks for the explanation. That encouraged me to read a bit more about css and I now have an idea of what

frac/sandbox}} and {{sfrac/sandbox}}. However, I haven't tested it and need to have at least 24 hours of clear time to ponder how the new code will work with all the strange situations here and at other languages. Following is a test. Johnuniq (talk

) 09:29, 17 December 2020 (UTC)

Oh dear. EEng 14:37, 19 December 2020 (UTC)

The problem is that <sup>...</sup> and <sub>...</sub> are setting line-height to 1em (which is rendered as 10.16px on my Monobook skin). The corresponding classes .num and .den in the sandbox leave the line-height at default, which is 1.5em (rendered as 19.05px on my Monobook skin because the em is also different for the two cases). The two parts of the fraction poke above and below the line of the rest of the text, so need a smaller line-height to prevent the gaps you are seeing. I don't want to fiddle with your stylesheets, but I think that reducing the line-height for the .num and .den classes by about 50% somehow will ease the problem for you. Cheers --RexxS (talk) 20:59, 19 December 2020 (UTC)

Thanks EEng and RexxS but I can't quite interpret your responses. Let me clarify that I'm wanting to wrap this up and so was doing various tests when I noticed the spacing issue. It looks a little odd to me but perhaps it's unavoidable (or, avoiding it would introduce other problems). Do you think the vertical spacing is a problem that needs to be fixed? The point is that if the new convert is released, over a million pages will be put on the job queue. Then if Template:Frac/styles.css is tweaked a week later to fix the spacing, the same pages will be processed again which seems unkind. Johnuniq (talk) 00:55, 20 December 2020 (UTC)

Oh, dear = How unfortunate, unsightly, and best remedied if possible. EEng 05:28, 20 December 2020 (UTC)

The Reading Eye is very sensitive to lineheight. It can and will surely notice the height diff in running lines when one has this fraction applied. The demo provided says it is a notable (visible) enheightening. So IMO, it is worth improving (e.g., using Rexx's post) over early rollout. -DePiep (talk) 01:16, 20 December 2020 (UTC)

I've created

piece-work rates, so it's not going to hurt if you put an extra job in the queue once in a while. --RexxS (talk

) 01:33, 20 December 2020 (UTC)

• User:Johnuniq/sandbox2 uses Template:Frac/styles.css
• User:Johnuniq/sandbox uses Template:Frac/sandbox/styles.css

Please compare these two pages. The latter is working perfectly, thanks RexxS. Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst. Another weirdness is that I see a small vertical gap after the first "It's a long way to the next town." (that gap was always there but I couldn't see a reason for it). Johnuniq (talk) 02:54, 20 December 2020 (UTC)

Hmm, obviously the latter will overrule the former because the styles have the same name. I'm beginning to understand... Johnuniq (talk) 03:09, 20 December 2020 (UTC)

The gap between the first and second items in any table cell occurs because the MediaWiki software renders the first item as a bare span inside the td, but then wraps the rest of the content of the td inside a paragraph. The spans have no margin, but the paragraph has a top and bottom margin of a few pixels; hence the gap. That's exactly right about the styles (they are cascading, i.e. later definitions override earlier ones). Cheers --RexxS (talk) 09:59, 20 December 2020 (UTC)

Ah, ye old paragraph wrapping. --Izno (talk) 17:13, 20 December 2020 (UTC)

Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst. Indeed, this is expected; see Rexx. There is a way to work around it that is kind of a pain (setting the sandbox templatestyles invocation to add the attribute wrapper=".sandbox" as in <templatestyles src="Example/sandbox/styles.css" wrapper=".sandbox"/> and then wrapping some content in the same page as your other case with the sandbox class). See mw:Extension:TemplateStyles#Usage. --Izno (talk) 17:13, 20 December 2020 (UTC)

I was away from a PC yesterday. I'm not surprised this was a line height issue; I was seeing it in some of the default style sheets out there for browsers for sub/sup and wasn't strictly certain why. Thank you for testing!

I am still thinking I'd like to break up the frac and sfrac stylesheets into two since I do not anticipate it often being the case that someone will use them both on a page, given the use instructions for both. The costs for two sheets where they are used on the same page are negligible, and there will be a savings in the relevant budget for the vast majority where they are not.

RexxS, it is in use nowhere else at this time, so no sandbox page was required. :) It is nice for comparison by multiple people though. --Izno (talk) 17:13, 20 December 2020 (UTC)

It now becomes a splitter vs. lumper debate. Splitting gives a smaller style sheet focused on a single issue (frac or sfrac, not both). There would be duplication with .sr-only in each (if that was split out as well, each fraction usage would need to output two strip markers). Someone editing one split page might not get around to making corresponding adjustments in the other. On the other hand, lumping puts everything together with the cognitive load of staring at a page trying to do two different things and the slightly increased HTML output if only one is needed (a frac-only style would be around 300 bytes, while a frac-and-sfrac style would be about 560). Johnuniq (talk) 02:49, 21 December 2020 (UTC)

How may I combine conversion, range, and adjective? For example, I am attempting to write "300-by-500-foot-wide (984 to 1641 m)." CapeVerdeWave (talk) 17:26, 19 December 2020 (UTC)

Do you really want by...to? Convert can do this:

• {{convert|300|by|500|ft|m|adj=on}} → 300-by-500-foot (91 by 152 m)

Johnuniq (talk) 22:30, 19 December 2020 (UTC)

• I'm trying to imagine what 300-by-500-foot-wide even means, much less how by + wide somehow become to. EEng 05:32, 20 December 2020 (UTC)

I apologize. I meant 300-to-500-foot-wide (984 to 1641 m), with "-wide" attached to the end. CapeVerdeWave (talk) 08:35, 20 December 2020 (UTC)

(984 m?). Then:

{{convert|300|to|500|ft|m|adj=on}} → 300-to-500-foot (91 to 152 m)

{{convert|300|to|500|ft|m|adj=mid|-wide}} → 300-to-500-foot-wide (91 to 152 m)

from doc: A_10-foot-long_corridor. -DePiep (talk) 09:35, 20 December 2020 (UTC)

• FTR I wonder if the example was meant to be 300-to-500-metre (980 to 1,640 ft) (and here we encounter the rounding conundrum once again). EEng 18:04, 20 December 2020 (UTC)

Would explain the numbers :-). Who's gonna build the demo? -DePiep (talk) 18:31, 20 December 2020 (UTC)

@CapeVerdeWave: in case you have swapped the units inadvertedly, as your numbers indicate (manual input), here is the reverse version:

{{convert|300|to|500|m|ft|adj=on}} → 300-to-500-metre (980 to 1,640 ft)

{{convert|300|to|500|m|ft|adj=mid|-wide}} → 300-to-500-metre-wide (980 to 1,640 ft)

-DePiep (talk) 06:59, 24 December 2020 (UTC)

Module:Convert/helper does some pre-Convert input cleanups. For this it also replaces, for example, ⁄ with /: good. This simplifies later string handling jobs like search&replace, etc. See this code:

text = text:gsub(' ', ' '):gsub(' +', ' '):gsub(' *%+ *', '+'):gsub('⁄', '/'):gsub('⁄', '/'). All fine so far.

Now Lua has a function that replaces these &...; html entities (character id's), all in one go: mw.text.decode. (which is available through Module:DecodeEncode; by me; pre-alpha).

So I'd ask you to consider: could this be an improvement? Sure it's only efficiency & systematic completeness, not squashing a bug. And maybe the pre-apha status is to be looked at. -DePiep (talk) 23:44, 25 December 2020 (UTC)

If something is needed it can be added. However I'm not sure mw.text.decode would give good results. It changes   to   and does not change ⁄. I put a test at Module:Sandbox/Johnuniq/temp—see results at its talk where a mid dot (·) is used to replace each space. Johnuniq (talk) 01:29, 26 December 2020 (UTC)

(removed, my bad text) -DePiep (talk) 01:36, 26 December 2020 (UTC)

Very strange, & does not fit with mw:doc AFAIK. More research needed. Later more. -DePiep (talk) 02:10, 26 December 2020 (UTC)

With most large areas, I'm used to seeing acres "traditionally" paired with hectares. Lately, however, I've been seeing more and more instances paired with square kilometers instead. Has there been a consensus reached (or changed) regarding which unit acres should be paired with? I just wondered; I'm not sure if this is the best place to ask, but I also don't know where else that would be.

Are there situations where one unit or the other is preferred? Or are hectares now considered "archaic"? :)

Thanks! 1980fast (talk) 02:19, 24 December 2020 (UTC)

The default output unit for acre is ha. For example, {{convert|123|acre}} shows 123 acres (50 ha). Where do you see km2 (square kilometers)? There is no preference or consensus adjustment at this page, but it's possible that people in one region are used to ha while those somewhere else see km2. Johnuniq (talk) 02:55, 24 December 2020 (UTC)

@Johnuniq: To answer your question, and to provide context for others as to what prompted me to ask the question, an example of what I'm talking about can be seen here, in the "Notable wildfires" subsection (I'm not sure why I can't link directly to it, but that's a question for somewhere else). There are several uses of km2, where I would have expected hectares. 1980fast (talk) 03:42, 28 December 2020 (UTC)

Santa Barbara, California#Notable wildfires contains four converts, three of which concern areas and are like {{convert|67000|acre|km2}} with different numbers. An editor has chosen to specify that the output should show the km² value by specifying km2 as the output unit. That choice is an editorial matter which is outside convert's scope. If the area is wanted in hectares, replace km2 with ha or omit |km2. People have outlined the factors involved in making a choice in this section. All converts concerning area in that article (there are seven of them) show the output in km². Johnuniq (talk) 03:59, 28 December 2020 (UTC)

Seems to me that one might use square kilometers for larger areas, at least double digit square kilometers. But some large farms might be that big. For areas of countries, I think US would use square miles not acres. Gah4 (talk) 03:54, 24 December 2020 (UTC)

The proper counterpart of the acre is the hectare. Hawkeye7 (discuss) 04:13, 24 December 2020 (UTC)

The hectare is not an SI unit, of course; the SI unit of area is the square metre. However, SI units of length don't favour decametre and hectometre, so the jump from square metres to square kilometres is a factor of 1,000,000 to 1. That means that common parcels of land are either a tiny fraction of a square kilometre or a large multiple of square metres. So there is a need for a simple unit for those sort of sizes of area and the acre in imperial or hectare in metric found common use (the same reason why we commonly use the litre for volume). Since they are about the same order of magnitude – compare: 1 square kilometre (100 ha; 250 acres; 1,000,000 m²) – it makes sense to pair acre with hectare because they will find common usage for the same sort of area. Any SI pedants will naturally prefer to restrict conversions to SI units, and that may be the effect seen by 1980fast. Cheers --RexxS (talk) 20:13, 24 December 2020 (UTC)

Speaking only for my own personal experience (as a middle age, city born, Australian), we either use m² for the small stuff (eg, my house and immediate surroundings of 700 m²) or km² for the big stuff (eg, an entire city, a cattle station or a country). Middle stuff chooses whichever looks more manageable. I can never remember how big a hectare is because I never see anything listed that way.  Stepho  talk  21:54, 24 December 2020 (UTC)

A 15-acre (0.061 km²; 61,000 m²) farm must be awkward to deal with (extreme middle aged, urban, English). --RexxS (talk) 23:52, 24 December 2020 (UTC)

True, that's an awkward size for me. I can only say that us city-slickers rarely deal with small farms. Or if we do then we drop back to ancient units like acres.  Stepho  talk  00:45, 25 December 2020 (UTC)

The question is what is the preferred default counterpart for 'acre'?. Full stop. (not: what unit are you familiar with?). AFAIK, 'acre' is used in the very same circumstances as 'hectare' is: farming and real estate, and not geography. Anyway: similar in most cultural regions.

We are to *falsify* this by naming situations (culture, professions, habits, ...) where acre is used, but not hectare in parallel culture—and vice versa. And then again: even if these situations exist, meaningful & convincingly, it's just a default so what's the problem? IOW, if in profession X 'acre' translates to 'm2', then skip the default by entering m2. -DePiep (talk) 00:31, 26 December 2020 (UTC)

The Commonwealth Style Guide says to use hectares, and we always do. It is very common. As DePiep says, it is used for real estate like farms. eg [8] It is a metric unit but not an SI unit. Note that square kilometres is not an SI unit either. We use hectares to describe a 15-acre (6.1 ha) property. The acre was a measurement of area equal to a furlong times a chain; hence 640 acres to the square mile. It has not been used in Australia for half a century. Hawkeye7 (discuss)

If it matters, editors may add "km2" when the occasion demands: compare {{convert|10000|acre}} = 10,000 acres (4,000 ha) v {{convert|10000|acre|km2}} = 10,000 acres (40 km²). Retain the current behaviour as being the most common requirement for the template (outside Texas, of course). --

talk

) 12:02, 26 December 2020 (UTC)

@

SI prefix. --RexxS (talk

) 21:23, 26 December 2020 (UTC)

Exactly! And that's why the SI pedants insist that it is all wrong. A km² is not a thousand square metres as is implied by the notation (k always being 1,000) but a million. Hawkeye7 (discuss) 23:05, 26 December 2020 (UTC)

But all SI units of area (or volume) work like that consistently, without exception. A km² is a thousand metres by a thousand metres, and nobody has ever claimed it was anything else. --RexxS (talk) 01:13, 27 December 2020 (UTC)

When I was a kid, the fields were typically measured in Morgen (2500 m²; unit symbol Mg); I reckon this is what the metric (not SI!) counterpart of an acre would be. However, everyone understands what a hectare is, and Morgen is only used in rural areas nowadays. Best regards, --Johannes (Talk) (Contribs) (Articles) 22:00, 26 December 2020 (UTC)

"everyone understands what a hectare is", don't make assumptions. I cannot visualise what a hectare is, and either mentally dismiss it as "several acres" or else go and look for a conversion. A square kilometer on the other hand is slightly larger than 1⁄4 square mile which is good enough. In passing it does rather amuse me that the SI enthusiasts react with horror at any mention of non-metric customary units and yet plead intensely for metric but non-SI customary units! Think of a sentance including "sauce", "goose" and "gander". :-) Martin of Sheffield (talk) 22:32, 26 December 2020 (UTC)

A hectare is 100 metres x 100 metres. That's easy to visualise. A cricket oval like the MCG is two hectares. A square kilometre is much larger. I visualise it as 100 hectares. In the case of the acre (because I'm a military historian, I often come across the old measurements) I remember that a chain is a cricket pitch and that a furlong is ten of them. An acre is then easy to visualise. In the UK they still measure road distances in miles, which is probably why you can remember them but here the mile has become a figurative term for an immense distance. Hawkeye7 (discuss) 23:05, 26 December 2020 (UTC)

…I meant where I was raised everyone understands what a hectare is, and people typically use it. The "core message" though was that I believe that a Morgen is the "metric equivalent" to an acre if used for a field, but that people usually don't use it. But to answer the initial question: Where I live, as a rule of thumb, a hectare or square hectometre (hm²) is used for areas the size of a typical field, and anything larger than a typical field is expressed in square kilometres (km²). For example, fields, airfields, football fields, small woods and so on are expressed in hm², whereas large forests, settlements, huge areas of land, countries, continents, and planet surfaces are expressed in km². Best regards, --Johannes (Talk) (Contribs) (Articles) 03:43, 27 December 2020 (UTC)

@Hawkeye7: and interestingly, in the UK, distances along railway lines are measured in miles and chains. Convenient units still find a use. --RexxS (talk) 17:27, 27 December 2020 (UTC)

... and even more interestingly, all railway engineering in the UK for at least the past 20 years, probably nearer 50, measures everything in km, metres, tonnes, cubic metres etc. --

talk

) 19:54, 27 December 2020 (UTC)

When I was a kid, railway track was measured in miles and chains. However, where I live now, people don't know chains, and the mile is used exactly as Hawkeye7 described. In German-speaking countries, railway track is measured in hectometres (hm); this way, the train drivers can see very conveniently where they are (there is a hectometre post every hectometre). Howver, in the signaller language (both written and spoken), kilometres (km) with three digits after the decimal separator are used. Track length in stations (for shunting etc.) may also be given in metres (m). Best regards, --Johannes (Talk) (Contribs) (Articles) 23:57, 27 December 2020 (UTC)

How about the priority of SI units and non-SI units?
What to do if a existing table uses the non-SI values and calculates them into SI units? --Angerdan (talk) 14:53, 1 January 2021 (UTC)

As I understand it, the order displayed by this template depends on how the editor writes the template invocation. What the order should be is a matter for Wikipedia:Manual of Style/Dates and numbers. Jc3s5h (talk) 15:05, 1 January 2021 (UTC)

The input value and unit should always match that given in the reference, in order to help verification. But the order in which they are displayed can be changed using |order=flip or |order=out.

WP:UNITS says SI first is used for most articles, with exceptions for some US and UK articles.  Stepho  talk

  22:53, 1 January 2021 (UTC)

In the US modern engine volumes are often in liters or cubic centimeters, which are often converted to cubic inches, but it does not appear that either is a allowed conversion. Can this be added to the template?--Sturmvogel 66 (talk) 14:05, 26 December 2020 (UTC)

From Help:Convert units#Volume: cuin, cc, L. Will this do?

{{convert|1300|cc|cuin}} → 1,300 cubic centimetres (79 cu in)

{{convert|95|cuin|L}} → 95 cubic inches (1.56 L)

-DePiep (talk) 14:14, 26 December 2020 (UTC)

I should have been more specific in that I need a liters to cubic inches conversion as WWII-era propeller engines have volumes up to 40-odd liters and nobody uses cc for them.--Sturmvogel 66 (talk) 14:55, 26 December 2020 (UTC)

Litres to cubic inches then would be, by basic {{Convert}} workings:

{{convert|44|L|cuin}} → 44 litres (2,700 cu in)

OK? (or else, linking to an article would help). -DePiep (talk) 16:29, 26 December 2020 (UTC)

And add |sp=us for "liter" spelling if appropriate for article. Johnuniq (talk) 22:16, 26 December 2020 (UTC)

Right, IIRC, the chart listing the various units spelled it cu in with a space between. Of course, it's entirely possible that I misread the format ;-) Sturmvogel 66 (talk) 05:29, 27 December 2020 (UTC)

The text actually output from {{convert}} has a space in cu in, of course. It might be best to think about the units used in convert as having three forms: the "unit name", the "unit symbol", and what you might consider a "unit code" that is used as a parameter in the template to represent that unit. These unit codes generally don't have spaces in them, even if the unit name or symbol does, because the space is used to separate multiple outputs. The three forms may be identical, similar, or different:

For example, {{convert|2500|cm3|cuin L|abbr=on}} → 2,500 cm³ (150 cu in; 2.5 L) and {{convert|2500|cm3|cuin L|abbr=off}} → 2,500 cubic centimetres (150 cubic inches; 2.5 litres). The unit codes in those don't have spaces, even though the unit names and symbols may do. If your guess at the unit code produces an error, then removing any spaces often fixes it. --RexxS (talk) 00:31, 2 January 2021 (UTC)

…but why does a unit code even exist? I guess this only causes confusion (this is a perfect example) – I'd recommend making all possible unit symbols work as "unit codes" Johannes (Talk) (Contribs) (Articles) 02:56, 2 January 2021 (UTC)

Unit code is editor-friendly (think: writing the input). It solves these situations:

m2, impoz, C, C-change (no symbol for this at all), t (is metric or long?), mpg_‑US

Given this, {{convert}} uses the space with different meaning (as unit-separator): {{convert|10|km|mi nm nmi}} → 10 kilometres (6.2 mi; 1.0×10¹³ nm; 5.4 nmi). -DePiep (talk) 13:12, 2 January 2021 (UTC)

Can the template handle such conversions? I saw an option for multiple dimensions, but it doesn't seem to go beyond two dimensions, so I can't quite visualize how to do it. Thanks! 1980fast (talk) 03:20, 7 January 2021 (UTC)

Here are two examples:

• {{convert|3|x|4|x|24|in}} → 3 by 4 by 24 inches (76 mm × 102 mm × 610 mm)
• {{convert|3|x|4|to|6+1/2|x|8+3/4|in}} → 3 by 4 to 6+1⁄2 by 8+3⁄4 inches (76 mm × 102 mm to 165 mm × 222 mm)

More than three is supported, just keep adding numbers and range symbols. 03:52, 7 January 2021 (UTC)

Thank you! 1980fast (talk) 04:22, 7 January 2021 (UTC)

Is there a way to convert scientific notation with a confidence interval using this template? What I would like to get is

• (5.4 ± 0.5)×10¹⁷ kg [(1.2 ± 0.1)×10¹⁸ lb]

but the template gives me either

• 5.4×10¹⁷ ± 0.5 kg (1.1904962157983×10¹⁸ ± 1.1 lb)

or

• 5.4×10¹⁷ ± 0.5×10¹⁷ kg (1.19×10¹⁸ ± 1.1×10¹⁷ lb)

Perhaps it's just a bad idea to do unit conversion in this case, even the "right" answer is rather cumbersome. Tercer (talk) 07:38, 21 January 2021 (UTC)

No, you would have to use {{val}} for confidence intervals and could not have an automatic conversion. You could use convert to kludge the output number but you may as well do it all manually because there is no template that handles conversion of the confidence level. I think your suspicion that a conversion might not be desirable is correct. Anyone who understands what an error interval is will want kg, and the conversion doesn't really add anything—the point is that it is a very large number of pounds. Johnuniq (talk) 08:34, 21 January 2021 (UTC)

Is it possible to format the conversion such that there are no extra parentheses added? A use case for this would be a conversion done within an existing parenthetical statement.

For example, say that someone has just mentioned a mountain, followed by "(elev. xxxx feet)". What if you wanted the conversion to read "(elev. xxxx feet; xxx meters)" in order to avoid the messiness that comes with nested parentheses? Thanks! 1980fast (talk) 21:45, 22 January 2021 (UTC)

@1980fast: Sure – see Template:Convert #Output manipulation. For example:

• (elev. {{convert|10|m|ft|disp=comma}}) → (elev. 10 metres, 33 ft)

The documentation is lengthy, but pretty comprehensive. --RexxS (talk) 22:10, 22 January 2021 (UTC)

Thanks! I'm not sure how I missed that, but I clearly did. :) 1980fast (talk) 22:20, 22 January 2021 (UTC)

There is also (elev. {{convert|10|m|ft|disp=sqbr}}) → (elev. 10 metres [33 ft]) MB 02:11, 23 January 2021 (UTC)

That's even better! Thanks! 1980fast (talk) 07:27, 26 January 2021 (UTC)

I was looking at the page for Darigold, a dairy cooperative, and it mentions their annual production of milk – a staggering 8.6 billion pounds a year. The template used is a simple conversion to kilograms, however, the metric output is given in scientific notation, which isn't exactly accessible for the average reader. Is there any way to make both values output a conversion that is more directly comparable, perhaps with the numbers reformatted, like "8.6 billion pounds (3.9 billion kg)" ?

If that's not possible, is it at least possible to suppress the scientific notation? I'm not even sure how it came into play, since the input value is displayed without problem. Thanks! 1980fast (talk) 07:25, 26 January 2021 (UTC)

Use engineering notation and abbr=unit or abbr=off. You need one of these to get the word million/billion for the output. Unfortunately you can't have "pounds" (name) and "kg" (symbol) and number words.

• {{convert|8,600|e6lb|e6kg|abbr=unit}} → 8,600 million lb (3,900 million kg)
• {{convert|8,600|e6lb|e6kg|abbr=off}} → 8,600 million pounds (3,900 million kilograms)
• {{convert|8.6|e9lb|e9kg|abbr=unit}} → 8.6 billion lb (3.9 billion kg)
• {{convert|8.6|e9lb|e9kg|abbr=off}} → 8.6 billion pounds (3.9 billion kilograms)

Johnuniq (talk) 08:14, 26 January 2021 (UTC)

For Iztapalapa#Elevation and climate could we have disp=/ and/or disp=s? eg ({{cvt|2,400|m|ft|disp=/}} asl) (2,400 m (7,900 ft)^{[convert: invalid option]} asl) instead of ({{cvt|2,400|m|ft|disp=or}} asl) (2,400 m or 7,900 ft asl) Peter Horn User talk 22:08, 4 February 2021 (UTC)

Sorry, disp=slash (and its equivalents disp=s and disp=/) was removed in January 2018. Johnuniq (talk) 22:51, 4 February 2021 (UTC)

And the reasons or pretexts were? I'm sure this caused a mess in many articles. Peter Horn User talk 23:28, 4 February 2021 (UTC)

Sorry but I have driven out memory of the very long and tedious discussions which can be traced in the archives. Perhaps some MOS page deprecated slash? There was no mess as the deprecated options were removed from articles before removing them from convert. Johnuniq (talk) 02:26, 5 February 2021 (UTC)

MOS:SLASH, no doubt. --Izno (talk

) 02:39, 5 February 2021 (UTC)

I was wondering if there should be "earth pounds" which can be useful on pages such as moon. Cause pound and kilograms are different. Pound is weight and kilograms is mass. Pound per kilogram depends on the gravity force. The Channel of Random (talk) 00:45, 13 February 2021 (UTC)

Pound (mass) has the symbol lb (lb_m is an alternative) and pound (force) has the symbol lb_f. It is easy to confuse the two but pound (lb) without a qualifier is always mass, same as kg.  Stepho  talk  01:11, 13 February 2021 (UTC)

@Stepho-wrs: In what context do you claim the symbol lb always means pound mass? In the context of the convert template, or some other context? Jc3s5h (talk) 01:29, 13 February 2021 (UTC)

In the context of the UK, the Weights and Measures Act 1963 defines the pound like this: "… the pound or the kilogram shall be the unit of measurement of mass by reference to which any measurement involving a measurement of … mass shall be made in the United Kingdom; and … the pound shall be 0.45359237 kilogram exactly." See Pound (mass) #Current use.

I'm pretty certain nobody is debating whether the kilogram is a unit of mass, and the pound is defined as an exact fraction of a kilogram, so it makes it pretty much impossible for the pound to be a unit of force in the UK. It may be different in other jurisdictions. --RexxS (talk) 01:51, 13 February 2021 (UTC)

In the US the same definition applies, although the federal and state laws enacting it are different. So the context is commerce. The definition only applies to places where weights and measures inspectors can raid and seize scales that do not conform. It does necessarily apply in, for example, physics classes or physics textbooks. Jc3s5h (talk) 01:57, 13 February 2021 (UTC)

My claim was based on information from the 2 articles I linked. International yard and pound also backs up that the pound (unqualified) is a defined in terms of the kg. If I am wrong then those articles will need updating. Perhaps I should have said "correct usage of pound without a qualifier is always mass". Of course, incorrect usage can claim anything from it being a unit of force to a unit of self esteem.  Stepho  talk  02:12, 13 February 2021 (UTC)

Pound (mass) and pound (force) acknowledge that various definitions exist. For the symbols they make reference to various non-goverment publications. Such publications can disagree. And as I indicated, governments are usually interested in enforcing their definitions in commerce (including the government acquiring goods). I just am nit convinced we can rely on "lb" always referring to the unit of mass. Jc3s5h (talk) 02:42, 13 February 2021 (UTC)

Perhaps so, but convert cannot help. There is no conventional way of writing "earth pound" ("Earth pound"?) that would be understood by someone unfamiliar with the concept, and there certainly is no symbol. Moon has no mention of "pound" but has text like "100 kg (220 lb) of water". That is referring to a certain amount of water specified with its mass, as defined in the way RexxS described above. Johnuniq (talk) 03:08, 13 February 2021 (UTC)

For Low Light of the Hook of Holland#History and elsewhere would it be possible to have (a) conversion(s)? say for example {{convert|2,000|cp|lm}}. Peter Horn User talk 16:58, 19 February 2021 (UTC)

The situation is not very clear. There are no related units in convert. Template talk:Convert/Archive 1#Photometry units is the only previous discussion. The candela is the SI unit for Luminous intensity, while lumen is the SI unit for Luminous flux. There are also Lux and Foot-candle, units for Illuminance. Candlepower is an "obsolete unit of measurement for luminous intensity" but apparently also has a modern definition measuring "the intensity of the light on a target". @Archon 2488 and GliderMaven: and anyone else with thoughts: Is there a useful and unambiguous conversion for candlepower? Johnuniq (talk) 23:34, 19 February 2021 (UTC)

11:32, 7 May 2019‎ Anthony Appleyard moved page Millimeter of mercury to Millimetre of mercury: Requested by Getsnoopy at WP:RM/TR: WP:COMMONALITY and because "metre" is standardised across WP — Preceding unsigned comment added by 2001:8a0:5e58:9a00:e992:745b:11c:c2cd (talk • contribs) 20:43, 3 March 2021 (UTC)

The problem being reported is that the following links to

Millimeter of mercury whereas for consistency and in accord with the current article name, it shold be Millimetre of mercury

. I made a note to do that for the next release.

• {{convert|12|mmHg|abbr=off|lk=on}} → 12 millimetres of mercury (1.6 kilopascals)

Johnuniq (talk) 03:04, 9 March 2021 (UTC)

For

Convert has an interesting way of handling Hz (see March 2015). I added rpm as a trial to see how it goes and whether there are any bad side effects.

• {{convert|1|rpm}} → 1 revolution per minute (0.017 Hz)
• {{convert|12|rpm|Hz|abbr=on}} → 12 rpm (0.20 Hz)
• {{convert|12|rpm|Hz|abbr=off}} → 12 revolutions per minute (0.20 hertz)

Johnuniq (talk) 02:54, 9 March 2021 (UTC)

• {{convert|6000|rpm|furlong}}6,000 revolutions per minute (15,000 furlongs)

(It's treating it like a radio wave. I don't think it's a problem exactly it's just strange looking.) GliderMaven (talk) 03:15, 9 March 2021 (UTC)

I was trying to avoid mentioning that, groan. Given the definition for Hz, it would be challenging to convert Hz to rpm without allowing other unlikely conversions. Johnuniq (talk) 03:33, 9 March 2021 (UTC)

I think with these kinds of dimensional conversion systems, stopping people doing weird conversions is much, much, much less of an issue than allowing people do the kinds of conversions they need to. GliderMaven (talk) 03:58, 9 March 2021 (UTC)

Surprise! the Hz values given now are totally different from those originally given in the article, showing the original figures to be wild guesses. Peter Horn User talk 21:30, 10 March 2021 (UTC)

@Peter Horn: you are chaotic. Could you just post:

1. "Expected: abc" (because: ...)

2. "But it shows: xyz"

Thanks. -DePiep (talk) 22:17, 10 March 2021 (UTC)

@DePiep: What was shown is 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz) the conversions became 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz). The original conversions were confirmed. Peter Horn User talk 05:28, 11 March 2021 (UTC)

Folks, we're too trusting! My first example above gave "1 revolution per minute (60 Hz)" which is total junk! Ouch. I'll look at whether this is due to my blunder with the scale or whether the tricky invert stuff actually doesn't work. Johnuniq (talk) 01:13, 11 March 2021 (UTC)

Um. Something's wrong: {{cvt|6000|rpm|Hz|lk=on}} is currently giving me: 6,000 rpm (360,000 Hz) GliderMaven (talk) 01:16, 11 March 2021 (UTC)

I think I've fixed it—the problem was just my confusion over the rpm scale. The relevant two converts from the article are:

• {{cvt|6,000|rpm|Hz|lk=on}} → 6,000 rpm (100 Hz)
• {{cvt|2,750|rpm|Hz|lk=on}} → 2,750 rpm (45.8 Hz)

Johnuniq (talk) 02:28, 11 March 2021 (UTC)

Looks much better, thanks! GliderMaven (talk) 04:40, 11 March 2021 (UTC)

@Peter Horn: Thanks for reporting the discrepancy but it was convert that was wrong—now corrected. By the way, when you see |disp=flip it would be good if you were to change that to |order=flip. One of the edits you made changed the first of the following to the second:

• {{Convert|9120|cc|cuin|0|disp=flip}} → 557 cubic inches (9,120 cc)
• {{Convert|9120|cc|cuin L|0|disp=flip}} → 557 cubic inches; 9 litres (9,120 cc)

You probably don't want to flip it like that. If you want both cuin and L with L as the input, you need:

• {{cvt|9120|cc|L cc cuin|0|order=out}} → 9 L (9,120 cc; 557 cu in)

Also, please have a look at Straight-six engine#Displacement range which is showing L as the second paragraph. It looks like a stray character was inserted. Johnuniq (talk) 02:28, 11 March 2021 (UTC)

@Johnuniq: I removed the stray L. Peter Horn User talk 05:37, 11 March 2021 (UTC)

Can the same conversion be mentioned twice or more in an article, or should this generally be avoided? Kind regards,

@

WP:LEAD and then again later in the body of the article. If the page is short, repeating the conversion becomes less desirable but ultimately it is a matter of judgment. If you want an opinion on a particular article, you might mention it here or at WP:Teahouse. Johnuniq (talk

) 01:00, 11 March 2021 (UTC)

Okay, thanks. The article is

ping

}} me in replies) 09:01, 11 March 2021 (UTC)

That is a bit repetitive but it could be argued that someone familiar only with km would want every instance converted. Ultimately it's a matter for discussion on the talk page of the article concerned, or perhaps at a related WikiProject. Here (at talk convert) we don't really have an opinion—the guideline is

MOS:CONVERSIONS but it doesn't have a clear statement on that point. You could ask for opinions there but people generally say that the MOS can't cover every detail and it's up to common sense with discussion. Johnuniq (talk

) 09:27, 11 March 2021 (UTC)

Thanks for the reply. I don't think it does anyone harm to leave it how it is and, as you say, it helps to clarify even if repeated. Kind regards,

ping

}} me in replies) 17:10, 11 March 2021 (UTC)

touchtennis#Court originally had the sentence

However, variances of up to a metre are tolerated…

The convert template let me change it to

However, variances of up to 1 metre (3 ft 3 in) are tolerated…

but I think the original (with conversion) reads better:

However, variances of up to a metre (3 ft 3 in) are tolerated…

Is there an option to use "a"?

Thanks,
cmɢʟee⎆τaʟκ 21:48, 17 March 2021 (UTC)

There is no good way to do that. For one thing, there are too many variations (although I can't think of them at the moment), and the syntax for specifying what is wanted would be clumsy. You can kludge it:

However, variances of up to a metre ({{convert|1|m|ftin|disp=out}}) are tolerated

However, variances of up to a metre (3 ft 3 in) are tolerated

Johnuniq (talk) 22:59, 17 March 2021 (UTC)

Alternatively, you could encase it with a wrapper using the one2a template and put: "However, variances of up to {{one2a|{{convert|1|m|ftin|spell=in}}}} are tolerated". Giving you: "However, variances of up to a metre (3 ft 3 in) are tolerated". --Voello _talk 00:05, 18 March 2021 (UTC)

Very nice. I must have seen that but had forgotten. Johnuniq (talk) 01:06, 18 March 2021 (UTC)

That's brilliant. Thank you very much, Johnuniq and Voello. cmɢʟee⎆τaʟκ 12:28, 18 March 2021 (UTC)

Editing this talk is now showing a ghastly edit notice from Template:Editnotices/Page/Template talk:Convert which contains {{Wikipedia information pages talk page editnotice}}. The previous version was also not very helpful. Any suggestions on wording to fix it? Johnuniq (talk) 08:51, 18 March 2021 (UTC)

I have replaced the standard notice (which looked like this) with something shorter and more appropriate. I contemplated deleting the edit notice and wouldn't mind that as a solution as I don't recall any off-topic posts in several years. Johnuniq (talk) 06:16, 20 March 2021 (UTC)

It's just straight up wrong. I have noticed it in an article, Joe Biden may well be 6" tall but that is not 2 metres. I'm just under 6" 2" and I'm 1.85m.

The example given is also wrong, 124" is 37.7m, not 40m. If this has been standardised across all articles then all these conversions are wrong, plain and simple.

Who does one get this rectified? Stefanzi (talk) 07:29, 18 March 2021 (UTC)

Joe Biden is six inches tall? He looks bigger on TV. Beyond that I can't tell what you're talking about. What example? Where? EEng 07:39, 18 March 2021 (UTC)

I reverted the recent edits at Heights of presidents and presidential candidates of the United States and the height is now:

• {{convert|5|ft|11+1/2|in|abbr=off|sp=us|cm|0}} → 5 feet 11+1⁄2 inches (182 centimeters)

It had been recently changed to:

• {{convert|6|ft|0|in|abbr=off|sp=us||0}} → 6 feet 0 inches (2 meters)

The "0" in |0}} tells convert to round the result to zero decimal places. No output unit was given (because the recent edits removed cm) and convert used its default for that which is m. The result was bad rounding due to bad parameters. Johnuniq (talk) 08:45, 18 March 2021 (UTC)

Meaning that it should have been written as {{convert|6|ft|abbr=off|sp=us||2}} (giving 6 feet (1.83 meters) or not removed the "cm". --

talk

) 12:38, 20 March 2021 (UTC)

I found an article that said a plant's density is "commonly 30 species/m2".

I changed that to :*{{cvt|30|/sqm}} which results in "commonly 30/m² (2.8/sq ft)"

It would be clearer if it could still include "species", similar to the way PD/sqkm generates "inhabitants". What about a parameter to override "inhabitants" with another name? I'm sure the text could be just be rewritten in this case, but the existing language seems most succinct. (There is currently no pd/sqm, so that would need to be added also).

On more thing, although /sqm works, I don't see it in the documentation (/sqcm, /sqkm, /sqha, /sqin, /sqacre, /sqmi are all there). MB 16:28, 21 March 2021 (UTC)

The following should be ok.

• {{cvt|30|/m2||disp=preunit|species}} → 30 species/m² (2.8 species/sq ft)

Re the documentation: there are many hundreds of units and only some of them are listed for users. The full list (including sqm) is Module:Convert/documentation/conversion data. The reason that /sqm works is that the unit sqm is an alias for m2 and convert automatically handles "per" units if it can. Johnuniq (talk) 23:08, 21 March 2021 (UTC)

Great, I was unaware of disp=preunit. It worked fine. Regarding the documentation, I was looking at the full list - Module:Convert/documentation/conversion data#Per unit area is where /sqm and m2 seem to be missing. I'm not clear if you mean that this list is supposed to be complete or not. MB 23:36, 21 March 2021 (UTC)

The full list only includes the defined units. Convert can handle certain cases automatically even though no unit is defined. The "per" units (x/y meaning x units per y units) are part of that. Johnuniq (talk) 02:03, 22 March 2021 (UTC)

Parameter list for |abbr values in and out should list in the description that they are used for "input" and "output" units, respectively, for clarity (i.e. "Use symbol for first (left-hand side) unit (input unit)"). Any other parameters using these identical values should likewise be updated as well. Kehkou (talk) 06:04, 29 March 2021 (UTC)

Do you want to try editing that? On the template page, at the top next to "Template documentation", you can click "View" to see the documentation page, or "Edit" to directly edit it. Or, you can edit the "Parameter list" section with its edit link. Johnuniq (talk) 06:22, 29 March 2021 (UTC)

Beware that it also changes when |order=flip and |order=out is used

So, |abbr=in really means abbreviate the first displayed value, rather than the input value.  Stepho  talk  21:53, 29 March 2021 (UTC)

Thanks, that reminds me as to why the documentation uses its current language. We could think about adding some explanation like displayed input, but more words might mean more confusion. Johnuniq (talk) 22:27, 29 March 2021 (UTC)

For Nevada Northern Railway, how would one convert 40 million net ton-miles to net tonne-kilometers? Peter Horn User talk 13:28, 13 April 2021 (UTC)

${\displaystyle y=x\cdot m\cdot L}$
With:
${\displaystyle x\land y\in \mathbb {N} }$
${\displaystyle x=40}$ (million net ton-miles)
${\displaystyle y...}$ (million net tonne-kilometres)
${\displaystyle m=0.90718474}$ (Mass of a ton in 10³ kg)
${\displaystyle L=1.609344}$ (Length of a mile in 10³ m)
Then:
${\displaystyle 40\cdot 0.90718474\cdot 1.609344=58.4\rightarrow y=58}$

Best regards, --Johannes (Talk) (Contribs) (Articles) 15:42, 13 April 2021 (UTC)

Much to my surprise, convert has that unit:

• {{convert|40|e6ton-mile|e6tkm}} → 40 million ton-miles (58×10^⁶ tkm)
• {{convert|40|e6ton-mile|e6tkm|abbr=off}} → 40 million ton-miles (58 million tonne-kilometres)

Johnuniq (talk) 00:01, 14 April 2021 (UTC)

"Learning" editor here! I am pretty sure the "adj" parameter is missing from the parameter list and that all its possible values are incorrectly included in the "abbr" section. I am pretty sure I know how to fix it (I messed around in my sandbox), but I've never edited a template doc or done much work with a wikitable before. Can someone more experienced either tell me it's ok to attempt a fix, fix it themselves, or tell me I'm wrong? Thanks in advance! Firefangledfeathers (talk) 02:46, 12 April 2021 (UTC)

@Firefangledfeathers: Thanks for pointing that out. Often inspecting the history of a page with a problem can throw light on what happened. I reverted a recent edit (diff) at that page and I believe it is back to normal. Johnuniq (talk) 05:10, 12 April 2021 (UTC)

Parameter value

@DePiep: Just a question – why would anybody want to sort the table by parameter value? And it doesn't effect the reader's ability to search for whatever they like, unless your web browser's search function is stuck in 'whole words only' mode. WT79 ^{(speak to me | editing patterns | what I been doing)} 18:17, 13 April 2021 (UTC)

Because: when an editor wants to learn what an existing (used in-article) {{Convert}} setup is. Say, reverse-editing. IOW, what does an input value do? Seeing this talkpage with recurring questions, Convert is complicated. I do not understand "'whole words only' mode". -DePiep (talk) 18:36, 13 April 2021 (UTC)

You'd want to look up which parameter is used just as much you want to look up its value. If, for example, I come across {{convert|100|ft|m|adj=mid|-deep}}, then I want to look up what "|adj=mid|-deep" means. I can see it is two parameters, and can guess what the final one is for because I saw it rendered in the article, Therefore what I'd search for would be "|adj=mid". Since the parameter column includes both parameter and value (due to a recent edit linked above) it doesn't make sense to have the values listed separately as well. WT79 ^{(speak to me | editing patterns | what I been doing)} 16:37, 14 April 2021 (UTC)

There was

Is it already possible to use lboz/ as a per unit? Or is that easily added? For example instead of {{convert|235|kg/ha|lb/acre|frac=16}} in [9]. Invasive Spices (talk) 17:47, 29 April 2021 (UTC)

No, sorry. Convert gives up if given a combination like lb + oz. For one thing, the output (209 lb 11 oz/acre) would look strange. Also, it's unlikely that the resulting number of ounces is meaningful; that is, the output should be rounded to the number of pounds to avoid false precision. Johnuniq (talk) 01:15, 30 April 2021 (UTC)

• That's unfortunate. I think it's needed. 1) In the case I just used it - "(209 ¹¹⁄₁₆ lb/acre)" - the alternative is strange looking also. 2) Although in that case I'm not sure such precision is needed either, certainly if we were outputting the text Total pounds of Atrazine applied must not exceed 2lb 8oz/acre per year., the ounces are vital. Invasive Spices (talk) 19:10, 30 April 2021 (UTC)

This is unusual and rarely comes up, but I just saw something where PD/kg would be needed. I wanted to use {{convert||PD/kg|PD/lb}}, but no such units. You can see it by my <!--- ---> comment in this edit. Thanks for working on this stuff. Invasive Spices (talk) 21:03, 3 May 2021 (UTC)

What unit does PD stand for? Convert without PD works: "The density of spat varies from 200 to 2,000,000 per kilogram (91 to 907,185 per pound) of seaweed." -- WOSlinker (talk) 21:38, 3 May 2021 (UTC)

• Thanks WOSlinker. That's perfect. (PD is "population density" for humans/living things. Just /kg by itself wasn't listed in
  Module:Convert/documentation/conversion data/doc so I never thought to try it.) Invasive Spices (talk
  ) 15:28, 4 May 2021 (UTC)

• This version was discussed in December 2020 but the release was stalled while the template styles were finalized.

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

• Template styles (by Izno and RexxS):
  • Fractions are displayed using Template:Fraction/styles.css (fractions with a slash) or Template:Sfrac/styles.css (stacked fractions with a horizontal bar).
  • The implementation inserts the templatestyles 42-byte strip marker at the start of the convert output, but only if required for the fraction being displayed and only once per convert even if more than one fraction is displayed (for example, {{convert|1+1/2|by|5+3/4|in}}).
  • For localization, the template styles are in Module:Convert/text which now exports the titles table.
• Unit changes:
  • Remove gramme from the unit definitions. This is not a change to units as gramme is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future. MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at MOS talk July 2019 following a request here.
  • Remove 23 apparently unused energy units linking to
    Atmosphere (unit) per discussion here
    .
  • New unit g0-force added and unit g0 has symbol g₀ with the 0 no longer in italics (discussion).
  • Some units from Module:Convert/extra that are used in articles have been copied to the main module.
    • mi/kWh is retained in extra; it will be removed if not found to be used in articles.
    • Occurrences of scf2 and scfoot2 in articles will be replaced with scf and scfoot which have had their link corrected to standard cubic foot (discussion).
  • Link for unit mmHg changed to Millimetre of mercury with re not er spelling (discussion).
  • New unit rpm (discussion).
  • New units tkm and ton-mile (discussion).
• Tweaks:
  • Module:Convert/wikidata will use mw.wikibase.getLabel(X) instead of deprecated mw.wikibase.label(X).

Release notes for earlier versions are listed here. Johnuniq (talk) 01:16, 4 May 2021 (UTC)

Done, the new version is live. Johnuniq (talk) 05:21, 6 May 2021 (UTC)

@Izno: Having convert use {{fraction}} and {{sfrac}} templatestyles was discussed in December 2020:

• Template talk:Convert/Archive 2#visualhide removal
• Template talk:Convert/Archive 2#Module version 25 (see May 2021 for release)
• Template talk:Convert/Archive 2#Vertical spacing

Part of that involved a demonstration that the vertical spacing was a problem:

• User:Johnuniq/sandbox2 uses Template:Fraction/styles.css
• User:Johnuniq/sandbox uses Template:Fraction/sandbox/styles.css
• {{convert/sandbox|1+2/3|ft|in}} → 1+2⁄3 feet (20 in) (uses Template:Fraction/styles.css)
• {{convert/sandbox|1+2/3|ft|in|test=stylesandbox}} → 1+2⁄3 feet (20 in) (uses Template:Fraction/sandbox/styles.css)

The vertical spacing problem was fixed by RexxS in Template:Fraction/sandbox/styles.css. However the fix was not used for {{fraction}}. What should convert do? That is, should convert not use templatestyles? Or, should it use the fraction style and ignore the vertical spacing problem? Or, should the style be tweaked somehow? Johnuniq (talk) 04:38, 14 April 2021 (UTC)

I removed the temporary test=stylesandbox code so the above no longer applies. Johnuniq (talk) 10:09, 28 April 2021 (UTC)

Just now (thank you for continuing to poke me), I moved RexxS's changes to the main fraction styles, moved sfrac's styles out to its own sheet (per related discussion), and made Template:Frac's sandbox live. I'll be moving stuff live for Sfrac shortly.

I did get lost in your implementation here in convert when I went to look at it the first time, but I think I get the gist of what it is doing now. (I am not a fan of the string processing that I can see that selects whether to add the templatestyles, but I'm not going to hassle about it.) I think the remaining effort in the convert module is to remove some temporary code in the sandbox regarding style sandboxing in add_style, and to add an implementation for Sfrac having separate styles, where necessary. Izno (talk) 20:37, 27 April 2021 (UTC)

While on the subject of fans, I'm not a fan of splitting everything into micro-files (Template:Fraction/styles.css and Template:Sfrac/styles.css) but purism has its place. I updated convert/sandbox so both styles work. I'll need to check what I've done and slowly test it later.

• {{convert/sandbox|1+2/3|ft|in}} → 1+2⁄3 feet (20 in) (fraction style)
• {{convert/sandbox|1+2//3|ft|in}} → 1+2/3 feet (20 in) (sfrac style)
• {{convert/sandbox|18+1/2|in|ft|frac=-2}} → 18+1⁄2 inches (1+1/2 ft) (both!)

Johnuniq (talk) 10:09, 28 April 2021 (UTC)

I am not per se a fan of micro-files either but made the decision that on the greater proportion of pages (probably much larger proportion) one should expect that only one or the other will be used rather than both given both documented template use and documented number of transclusions (24k use fraction, 4k use sfrac).

If your implementation works for you, just ping me when you merge so I know to start the clock on removal of visualhide in Common.css (the original reason for all this :^). Izno (talk) 19:20, 28 April 2021 (UTC)

@Izno: The new version is now live. Johnuniq (talk) 05:24, 6 May 2021 (UTC)

Hi all, After a conversation last month with @Colonies Chris:, I have started to use the convert template for windspeeds with the following configuration: {{convert|125|kn|km/h mph|round=5|disp=out}} , however, I noticed earlier that the template is not putting the output in brackets 230 km/h; 145 mph. Is there a way to ensure that the output goes into brackets? If so then I strongly suspect that the long running issues that the tropical cyclone project, has had with using the template for windspeeds might be over.Jason Rees (talk) 02:41, 6 May 2021 (UTC)

@Jason Rees: I think you want the second of these:

• {{convert|125|kn|km/h mph|round=5|disp=out}} → 230 km/h; 145 mph
• {{convert|125|kn|km/h mph|round=5|abbr=on|order=out}} → 230 km/h (145 mph)

Johnuniq (talk) 03:26, 6 May 2021 (UTC)

Thanks @Johnuniq:.Jason Rees (talk) 13:20, 6 May 2021 (UTC)

Why, when using disp=or, is unit abbreviation an all-or-nothing proposition?

If I want the otherwise default behavior of "x inches or y mm", it seems that's not currently possible.

Instead, either both units are spelled, or both units are abbreviated, with the addition of abbr=on. That behavior seems incredibly inconsistent. Thanks for any clarification! 1980fast (talk) 04:04, 7 May 2021 (UTC)

@1980fast: With disp=or, the default is abbr=off. However abbr can also be specified as in or out.

• {{convert|7|in|mm|abbr=out|disp=or}} → 7 inches or 180 mm

Johnuniq (talk) 07:18, 7 May 2021 (UTC)

@Johnuniq: Thanks! Because the out option is not mentioned at all in the section on abbr, it never even crossed my mind that it would be possible. Now I know: check the tables! 1980fast (talk) 22:57, 9 May 2021 (UTC)

Sacramento, California#2010 census 4,660.0 people per square mile (1,799.2/km²) How was this calculated? It does not appear to be done by template convert. {{convert|4,660.0|people/square mile}} 4,660.0 people/square mile^{[convert: unknown unit]} {{convert|4,660.0|density/square mile}} 4,660.0 density/square mile^{[convert: unknown unit]} Peter Horn User talk 23:38, 15 May 2021 (UTC)

{{convert|4,660.0|/sqmi}} → 4,660.0 per square mile (1,799.2/km²)  Stepho  talk  00:09, 16 May 2021 (UTC)

Convert options:

• {{convert|4,660.0|/sqmi}} → 4,660.0 per square mile (1,799.2/km²)
• {{convert|4,660.0|PD/sqmi}} → 4,660.0 inhabitants per square mile (1,799.2/km²)
• {{convert|4,660.0|/sqmi||adj=pre|people}} → 4,660.0 people per square mile (1,799.2/km²)

Johnuniq (talk) 00:22, 16 May 2021 (UTC)

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

• Unit changes:
  • Link and name have been hyphenated for units: acre foot + acre feet + Nm + mN.m.
  • Link changed to Units of textile measurement#Units for unit: dtex.
  • Link changed to
    Ampere per metre which redirects to Magnetic field#The H-field
    for units: A/m + kA/m + MA/m.
  • Link changed to
    Pound-mole which redirects to Mole (unit)#Similar units
    for units: lb-mol + lbmol + lb-mol/d + lb-mol/h + lb-mol/min + lb-mol/s + lbmol/d + lbmol/h + lbmol/min + lbmol/s.
  • Link changed to
    Avoirdupois system#long quarter
    for units: qtr + long qtr.
  • Link changed to
    Avoirdupois system#short quarter
    for unit: short qtr.
  • Link changed to Rod (unit)#Area and volume for unit: sqperch.
  • Link changed to
    Cubic foot per minute which redirects to Cubic foot#Cubic foot per minute
    for unit: cuft/min.
  • Link changed to
    Cubic yard per second which redirects to Cubic yard#Cubic yard per second
    for unit: cuyd/h.
  • Link changed to Pound per square inch for units: ksi + psf + psi.
  • Link changed to
    Pound-force per square inch which redirects to Pound per square inch
    for unit: lbf/in2.
• Module:Convert/wikidata/data updated to match some changes to units on Wikidata (comparison of sandbox units with those in Wikidata is here).

Release notes for earlier versions are listed here. Johnuniq (talk) 03:27, 3 June 2021 (UTC)

Done, the new version is live. Johnuniq (talk) 03:21, 6 June 2021 (UTC)

Acre-feet vs. acre feet

Resolved

I've come across a little grammar/definition problem while updating streamflow data in a river article.

The way I understand it, the unit acre-foot is spelled with a hyphen because it's defined by the product of an acre and a foot of thickness, just as the kilowatt-hour is the energy produced by one kilowatt of power for one hour.

So shouldn't {{convert}} display acre-feet rather than acre feet?

Let me add that I found a relevant discussion on this talk page from 2011, Template_talk:Convert/Archive_September_2011#acre_foot. It appears that either no change was made to {{convert}} following that discussion, or that some possible helpful feature was eliminated.

Please forgive me if I am wrong or there already is some feature to display acre-feet. If so, I would like to know. --Jsayre64 (talk) 02:35, 18 May 2021 (UTC)

You seem to be the first to note here that

acre-feet has had a hyphen for a long time, apart from the 2011 discussion you linked which focused on what had to be typed as the unit code for convert's input. The current situation seems wrong and needs fixing but we'd better take some time to check other units as well. I'll have to remind myself whether Module talk:Convert/show still works but it probably does. That page lists all the unique links that convert can generate. And maybe examine the full list of units

.

The current situation is that these unit codes (input to convert) exist:

acre.foot = acre foot

acre feet = acre-feet = acre ft

They all have acre⋅ft as the symbol and acre foot as the unit link and singular name. The two "foot" units have acre foot as the plural name while the other units give acre feet. What's needed is that the link and names are hyphenated. Thanks for reporting. The change will happen in due course but some thought about any other unit adjustments is needed first. Johnuniq (talk) 03:42, 18 May 2021 (UTC)

Ok, hopefully someone who knows more about the intricacies of {{convert}} will come along and help. Those documentation pages usually confuse me, and I know very, very little about how to change the template code.

In the meantime, however, I've tested different ways of using {{convert}} for acre-feet and for kilowatt-hours, mostly for reference, I guess. Have a look. It appears that setting |abbr=on}} is an okay workaround method in the case of acre-feet, but even so, that dot indicating multiplication looks quite small to me. Jsayre64 (talk) 20:41, 18 May 2021 (UTC)

I have fixed many unit links in the sandbox (and have more to do). The fixed units include these:

• {{convert/sandbox|1|acre-foot|lk=in}} → 1 acre-foot (1,200 m³)
• {{convert/sandbox|1|acre-ft|lk=in}} → 1 acre-foot (1,200 m³)
• {{convert/sandbox|2|acre-foot|lk=in}} → 2 acre-foot (2,500 m³)
• {{convert/sandbox|2|acre-ft|lk=in}} → 2 acre-feet (2,500 m³)

These are aliases for acre-foot: acre foot + acre.foot

These are aliases for acre-ft: acre feet + acre-feet + acre ft + acre.ft + acre·ft
Johnuniq (talk) 10:19, 19 May 2021 (UTC)

Those look great! Is it okay to use {{convert/sandbox in an article though? Jsayre64 (talk) 17:41, 19 May 2021 (UTC)

Yes, you can use it but one of us has to remember to remove it later when the main template is updated. Frankly I would just leave it alone. Lots of articles use this unit and they have been displaying the unhyphenated text for years so a few more weeks won't be a problem. Johnuniq (talk) 01:55, 20 May 2021 (UTC)

Agreed. Jsayre64 (talk) 20:28, 20 May 2021 (UTC)

Angstrom

Convert defines symbol Å and name ångström and link

Please add a conversion for Lakh, which is used in many citations from India. -Guy Macon (talk) 12:18, 24 May 2021 (UTC)

@Guy Macon: I moved the above from the module talk page because this is where proposed changes are discussed. A lakh is not a unit in the sense used by convert (which is designed for converting between, say, kilograms and pounds). I think a specialty template would be more appropriate for lakhs—someone here might know if there already is one. Johnuniq (talk) 23:55, 24 May 2021 (UTC)

I see some info at Template talk:Convert/Archive December 2018#Lakh and crore which points to {{lakh}} and {{crore}}. Johnuniq (talk) 00:00, 25 May 2021 (UTC)

Testing...

• 400 [[lakh]] ({{lakh|400}}) = 400 lakh (40,000,000)
• 400 [[crore]] ({{crore|400}}) = 400 crore (4,000,000,000)
• 400 [[lakh crore]] ({{lakh crore|400}}) = 400
  lakh crore
  ({{lakh crore|400}})
• {{cvt|400|mi|ft}} = 400 mi (2,100,000 ft)

Not really useful. The miles are automatically converted to feet, which is good; they never get out of sync. I have to enter the number twice for lakhs; I might as well just add "(40,000,000)" at the end. :(

Example of a reference that is confusing to non-Indian readers: second paragraph of [10], cited at Unani medicine. --Guy Macon (talk) 04:10, 25 May 2021 (UTC)

I can't interpret

WP:CALC, I think, although the lakh template would be used to allow easy verification. Johnuniq (talk

) 05:02, 25 May 2021 (UTC)

That's a good solution. I would hope that anyone in India would be able to read 40,000,000 or forty million and know that it is the same as 400 lakh, 4 crore, or 4,00,00,000 (See Indian numbering system#Use of separators). --Guy Macon (talk) 06:15, 25 May 2021 (UTC)

In conversions such as {{convert|30|lt|MT}}, which renders as 30 long tons (30 t), I would like to have "tonnes" displayed instead of t: 30 long tons (30 tonnes). Can this be done? Cheers, Simon – SCHolar44 🇦🇺 💬 at 02:04, 9 June 2021 (UTC)

MT is metric ton so if you want tonne, use t or tonne and use abbr=off. The second of the following displays 2 decimal places to show the values are different but they round to the same number.

• {{convert|30|lt|tonne|abbr=off}} → 30 long tons (30 tonnes)
• {{convert|30|lt|tonne|2|abbr=off}} → 30 long tons (30.48 tonnes)

For all units, see here. Johnuniq (talk) 04:02, 9 June 2021 (UTC)

Many thanks, Johnuniq! SCHolar44 🇦🇺 💬 at 07:32, 9 June 2021 (UTC)

Johnuniq, what's needed, please, to include hundredweights and quarters? I've only succeeded with whole numbers of long tons so far. SCHolar44 🇦🇺 💬 at 05:55, 11 June 2021 (UTC)

Use Lcwt (long hundredweight) which can optionally be followed with qtr (quarter).

• {{convert|30|lt|18|Lcwt|2|qtr|tonne|abbr=off}} → 30 long tons 18 hundredweight 2 quarters (31.42 tonnes)

I fixed the timestamp in your signature. Please use four tildes to sign so a new signature is created. For example, the copy/pasted signature you used did not ping me. Johnuniq (talk) 06:57, 11 June 2021 (UTC)

Many thanks again, Johnuniq. (Probably I pasted the previous signature. I thought you would be pinged by [[User:Johnuniq|Johnuniq]] -- no?) SCHolar44 (talk) 05:59, 12 June 2021 (UTC)

@SCHolar44: The ping occurs in the process of Wiki translating the tildes into a signature. If you pasted a signature rather than the tildes, the paragraph would not have been searched for pingable constructs, and thus no ping would have occurred. Tarl N. (discuss) 06:49, 12 June 2021 (UTC)

Ah! The scales fall from my eyes! Many thanks for taking the time to educate me, @Tarl N.: SCHolar44 (talk) 12:40, 14 June 2021 (UTC)

A way to convert

unitcode    scale          link         default    symbol        name1        name1_us
metric ton  1000           Tonne        long ton   ~metric ton   metric ton
MT          1000           Tonne        LT ST      t             metric ton
t           1000           Tonne        LT ST      t             tonne        metric ton
tonne       1000           Tonne        shton      t             tonne        metric ton
ST          907.18474      Short ton    t          ~short ton    short ton
shtn        907.18474      Short ton    t          sh tn    short ton
shton       907.18474      Ton          t          ~ton          ton
LT          1016.0469088   Long ton     t          ~long ton     long ton
lt          1016.0469088   Long ton     t          LT            long ton

| elevation_m = {{PH wikidata|elevation_m}}