Template talk:Convert

Template:Convert

... in conception

... and in reality

How far are we from being able to add a unit user preferences option?

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)

  @Frankk20168:, we've been around this loop before. See Template talk:Convert/Archive 1#Inconsistent abbreviation. Looks like you have to remember to use abbr=on, I'm afraid. --John Maynard Friedman (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)

Thanks

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)

More than one thousands separator

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)

Long ton template

{{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)

visualhide removal

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)

Yes, I'm too lazy to have thought of that myself, and it was copied. Nothing about convert is simple. Examining an enwiki dump of articles from June 2020 shows:

Template	Total	Fractions	Percentage
convert	3,145,551	13,182	0.4
cvt	107,257	421	0.4

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 MediaWiki talk:Common.css, especially since, from what I could tell, every use of the class was for someone copy-pasting {{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:sronly where it is needed (probably hooking in to Template:Screen reader-only/styles.css directly rather than the template, unless you want to add the full template as a dependency), which, from what I can see, is only in the context of the copy-paste from 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}} and any copies should probably use TemplateStyles rather than hackish <sub> and <sup> [which have a semantic meaning that {{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)

Izno, "I don't really understand why {{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)

Mach

As I noted in Help talk:Convert, it seems that {{convert|1.6|Mach}} Mach 1.6 (1,960 km/h; 1,220 mph) doesn't set sigfig based on the input value. It was suggested to ask here about it. I don't know if this is specific to Mach, though. I put sigfig=2 in the one case I found, and don't know how many others there might be. Is there a regexp search good enough to search for them? Gah4 (talk) 14:04, 8 December 2020 (UTC)

~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)

Usage question

Not really about the template itself, but I was reverted at General Electric GE9X when adding the template because "the source contained both values". WP:Integrity was cited, which doesn't say anything about this. Is there really a valid reason to not use the template? MB 16:31, 8 December 2020 (UTC)

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)

Significant figures, opaque template behavior, and simple arithmetic

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 WP:OR to imply so.)

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, Oklahoma#Transportation uses {{convert|12000|mi}} in the second paragraph which starts with "More than 12,000 miles (19,000 km) of roads". Rounding to the nearest km would give "More than 12,000 miles (19,312 km) of roads". While there are examples of convert's default behavior giving bad results, there are plenty more where the results are good. If someone unfamiliar with the template wonders why silly numbers are being shown (such as in the above), they can ask here or at WP:HELPDESK for assistance. Johnuniq (talk) 03:52, 10 December 2020 (UTC)

{{re|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 @JPxG: "designed and machined parts" -- yes, basically but a) why would your shop use two unit sets (metric and ft,in) at all? Isn't that installing Murphy's law? (warn your CEO, now). And b) this is an encyclopedia, not a WP:HOWTO manufacture parts. That is: don't build your rockets from this webside. -DePiep (talk) 18:06, 10 December 2020 (UTC)

"abbr=on" adds units to each number.

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)

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

And...

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