Template talk:Convert/Archive March 2018

Thank you for this wonderful template

Just wanted to say thank you for the "Convert" template. I use it extensively and I appreciate its simplicity, its flexibility, and its accuracy. I'm grateful that you took the time to create it and that you're taking the time to maintain and expand it. It has an astonishing range of capability and you are to be commended for this great service to Wikipedia. Huzzah! Timbuk-2 (talk) 00:56, 8 March 2018 (UTC)

Thanks, and excellent timing since I'm currently investigating the bug reported in the previous section! An astonishing amount of work was done in planning and implementing the vast array of templates that were used for convert prior to December 2013 when it was switched to use Module:Convert. The module uses much of the design from the templates, translated to module code. Johnuniq (talk) 01:30, 8 March 2018 (UTC)

Cost per area is producing errors

{{convert|4|$/acre|$/km2|$=£}} produces an error: £4 per acre (£990/km²). However:

• {{convert|4|$/acre|$/ha|$=£}} is fine: £4 per acre (£9.9/ha)
• {{convert|4|$/sqmi|$/km2|$=£}} is fine: £4 per square mile (£1.5/km²)
• {{convert|4|$/acre|$/km2}} is fine: $4 per acre ($990/km²)

The error seems to only occur when converting between a "pure" area unit and a squared length unit, when the currency symbol is also being substituted.

(In the article I was editing, Toowoomba, I've changed the original author's km² to hectares to prevent the error.) 86.130.177.64 (talk) 20:27, 7 March 2018 (UTC)

Thanks for the report. As you indicate, the problem is due to the fact that the unit $/acre is defined in convert, whereas $/km2 is not. The latter is therefore handled as an automatic per unit. To make it compatible with some other defined units such as £/acre, the automatic unit type for $/km2 (when $=£ is used) is "cost £ per unit area". Then convert says there is a unit mismatch because the first unit ($/acre) has unit type "cost $ per unit area" which is different. I can't investigate any further at the moment because a recent software update on my computer is causing great irritation, but I'll look at the details later. Johnuniq (talk) 07:43, 8 March 2018 (UTC)

As a work around, no need to use $ at all {{convert|4|£/acre|£/km2}} works fine: £4 per acre (£990/km²) -- WOSlinker (talk) 12:37, 8 March 2018 (UTC)

Good point! I was too lost in the code to notice that. Johnuniq (talk) 23:00, 8 March 2018 (UTC)

The other way around:

{{convert|4|£/km2|£/acre}} → £4 per square kilometre (£0.016/acre) Y

Testing: Does not work for €, ¥, or x (use preview):

{{convert|4|€/km2|€/acre}} → €4 per square kilometre (€0.016/acre)

{{convert|4|€/acre|€/km2}} → €4 per acre (€990/km²)

{{convert|4|¥/acre|¥/km2}} → ¥4 per acre (¥990/km²)

{{convert|4|x/acre|x/km2}} → 4 x/acre

Anything for /documentation or Help from this? - DePiep (talk) 10:40, 12 March 2018 (UTC)

This is the first report of the issue so I wouldn't worry about putting a note in the documentation at the moment. I will get around to either fixing it or concluding it's too difficult. Either way I'll post here, but not for a couple of weeks. It works for £/km2 because that is a defined unit. Johnuniq (talk) 23:41, 12 March 2018 (UTC)

I put a fix for this problem in the sandbox. The fix sounds bizarre but it works well. The changes involve removing all $ and £ definitions. That means converts using currency will use automatic per units, and never a mixture of auto-per and defined units. The result is that all conversions using currency will be done in a consistent manner.

The omitted units are those with "$" or "£", namely:

$/acre    Cost $ per unit area      ==$/acre     default = $/ha
$/ha                                ==$/ha       default = $/acre
$/m2                                ==$/m2       default = $/sqft
$/sqft                              ==$/sqft     default = $/m2

$/km      Cost $ per unit length    ==$/km       default = $/mi
$/mi                                ==$/mi       default = $/km

$/kg      Cost $ per unit mass      ==$/kg       default = $/lb
$/g                                 ==$/g        default = $/lb
$/lb                                ==$/lb       default = $/kg
$/oz                                ==$/oz       default = $/g
$/ozt     Cost $ per unit mass      ==$/ozt      default = $/kg

$/m3      Cost $ per unit volume    ==$/m3       default = $/oilbbl
$/oilbbl                            ==$/oilbbl   default = $/m3

£/acre    Cost £ per unit area      ==£/acre     default = £/ha
£/ha                                ==£/ha       default = £/acre

local per_unit_fixups = {
    ["$/area"] = "cost $ per unit area",
    ["$/length"] = "cost $ per unit length",
    ["$/mass"] = "cost $ per unit mass",
    ["$/volume"] = "cost $ per unit volume",
    ["£/area"] = "cost £ per unit area",
}

Some units will be slightly changed in behavior; none of the converts currently in articles will be affected. An example of the change is that the unit $/g was defined to have a default output of $/lb. As an automatic per unit, that changes to $/oz because the default for g is oz.

In addition, the euro and yen currency symbols are recognized. Examples:

• {{convert/sandbox|4|$/acre|$/ha|$=£}} → £4 per acre (£9.9/ha)
• {{convert/sandbox|4|$/acre|$/km2|$=£}} → £4 per acre (£990/km²)
• {{convert/sandbox|4|$/acre|$/km2}} → $4 per acre ($990/km²)
• {{convert/sandbox|4|$/sqmi|$/km2|$=£}} → £4 per square mile (£1.5/km²)
• {{convert/sandbox|4|£/acre|£/km2}} → £4 per acre (£990/km²)
• {{convert/sandbox|4|£/km2|£/acre}} → £4 per square kilometre (£0.016/acre)
• {{convert/sandbox|4|¥/acre|¥/km2}} → ¥4 per acre (¥990/km²)
• {{convert/sandbox|4|€/acre|€/km2}} → €4 per acre (€990/km²)
• {{convert/sandbox|4|€/km2|€/acre}} → €4 per square kilometre (€0.016/acre)

Johnuniq (talk) 07:00, 22 March 2018 (UTC)

Narrow non-breaking spaces?

I'd like to request using narrow non-breaking spaces (as in {{nnbsp}}) before unit symbols—for example, so that {{convert|21|C|F}} outputs something like 21 °C (70 °F). This is because when the text is justified, there are often unusually large spaces between the figure and unit symbols (I'm seeing this in the lead to Hachijō-jima, for example). Curly "JFC" Turkey 🍁 ¡gobble! 23:13, 14 March 2018 (UTC)

Can you be sure that these characters are universally supported and won't display as tofu? This tofu display is what happens to some Unicode characters (such as the "🍁" used in your signature and the "🌹" used in mine), when this page is viewed using certain browsers such as Opera 36. Opera 36, btw, displays the " " character correctly (I think). --Redrose64 🌹 (talk) 00:23, 15 March 2018 (UTC)

Redrose64: if the character isn't universally supported, then we have a problem with the {{nnbsp}} template as well. I'm assuming it's not an issue. Curly "JFC" Turkey 🍁 ¡gobble! 02:50, 15 March 2018 (UTC)

(ec) The place to start would be at MOS:UNITSYMBOLS which currently says "though with certain symbols no space is used", giving ° as an example.

The following two lines show an extract from Hachijō-jima. The first line uses the standard nbsp as output by convert; the second uses the narrow nbsp.

The island enjoys a humid subtropical climate, with average high temperatures staying around 21 °C (70 °F). Hachijō-jima receives about 3,000 millimetres (120 in) of precipitation annually.

The island enjoys a humid subtropical climate, with average high temperatures staying around 21 °C (70 °F). Hachijō-jima receives about 3,000 millimetres (120 in) of precipitation annually.

Johnuniq (talk) 00:24, 15 March 2018 (UTC)

(J, I do not see that the comment about unspaced symbols applies here.) If the non-breaking space (as produced by convert) is in general expected to be stretched in the same way as a normal space, e.g. when justified, the OP's concern would make sense. As an example, in MSWord it does not stretch in this way, but Unicode seems to be silent on this. I would guess that a stretching NBSP might be a quirk of one browser, but if it is a more general phenomenon, the point will have merit. It will need to be characterized on many browsers and systems first, and reducing the width to a narrow space would also not be ideal, and may not solve the problem anyway. —Quondum 01:02, 15 March 2018 (UTC)

re MOSNUM "though with certain symbols no space is used": this pertains to degree as an angle unit: 23° 47′ 22″. However, this is not the case with temperature units °F and °C. - DePiep (talk) 01:38, 15 March 2018 (UTC)

OP says when the text is justified. Shouldn't this read "rendered"? Or else, how does the justifying (left-aligned with me) actually change the space width? - DePiep (talk) 01:42, 15 March 2018 (UTC)

"justified" normally means both left- and right-aligned, through stretching of spacing. I do not understand which browser contexts would result in this happening, though; my browser left-justifies with no stretching, and I find no setting to alter this. The OP would have to provide more context. —Quondum 01:56, 15 March 2018 (UTC)

"Justify paragraphs" is an option at Special:Preferences#mw-input-wpgadgets-edittop. Sorry to have jumped the gun on the MOS stuff—I'm probably too used to giving that kind of reply for proposals to alter the kind of space for unit names/symbols. Johnuniq (talk) 02:33, 15 March 2018 (UTC)

Thanks—I meant to mention that when I opened this discussion, but couldn't find the option. Curly "JFC" Turkey 🍁 ¡gobble! 02:51, 15 March 2018 (UTC)

Thanks, J. I confirm that my browser (Mozilla Firefox) also stretches   when justification is enabled, but leaves   and   with unchanged width. IMO, this scaling behaviour is not great (a fixed full-width space such as   would have been better), but there is a debate to be had about the status of this "gadget", how undesirable the scaling is, how much of an issue this is, and whether a workaround for a browser quirk with a non-default setting is appropriate. Other opinions would be appropriate, and other forums might be a good place to raise this if we feel it is worth pursuing. —Quondum 03:42, 15 March 2018 (UTC)

Stretching/squeezing spaces is a very graphical, typographic, font-designing issue that should be designed by font designers etcetera. Because changing some spaces, and not changing other spaces in-line makes the line view (glance) irregular. The human eye notices that uneven spacing, as a subconscious distraction; this is why designers have opinions on this. Let's ask WP:TYP about this, and have the conclusion put into relevant MOSes (MOSNUM I guess). It should also cover other units than these degrees (why not K btw?).- DePiep (talk) 09:23, 15 March 2018 (UTC)

DePiep: "(why not K btw?)": I said "before unit symbols", not "before °C and °F"—that was only an example. Curly "JFC" Turkey 🍁 ¡gobble! 21:47, 15 March 2018 (UTC)

Come to think of it: this change would also affect my, left-aligned, pages. - DePiep (talk) 09:26, 15 March 2018 (UTC)

I don't see it as a problem with left-aligned pages (English being written ltr) since with left-alignment (and indeed with right-alignment) the spacing between words is constant. See Typographic alignment#Basic variations. The perceived problem that we have here is with justified text - that is, where both left and right margins are aligned, which leads to variable spacing between words and consequently an inconstant width for supposedly "narrow" non-breaking spaces. --Redrose64 🌹 (talk) 11:05, 15 March 2018 (UTC)

The "perceived problem" aka proposed change works both ways: it also alters that space when left-aligned (that is: for everyone). So I want an expert opinion, the expertise being in typography design. And what with tables & infoboxes (not-inline)? - DePiep (talk) 12:35, 15 March 2018 (UTC)

What I meant was that when there is no justification, spacing is predictable: normal spaces are of constant width, as are non-breaking spaces (which need not be the same width as normal spaces). When justification is enabled, spacing is no longer predictable - "narrow" non-breaking spaces may be rendered wider than a normal space on the line above or below. --Redrose64 🌹 (talk) 19:43, 15 March 2018 (UTC)

I think there is an other reason to introduce this NNBSP: visually, the small ° symbol by itself adds white area (below it) to the line. Therefor it might be a more pleasant look when the space is reduced. (And, as has been described above, it prevents even bigger spacing space when the line is justified). To get the idea: fine typography moves letters "AT" into one another, to reduce white area (compare: next to each other: A​T <-> AT into each other). Any more small symbols in use that should have the same? - DePiep (talk) 15:43, 15 March 2018 (UTC)

Woooow this {{NNBSP}} looks innocent, but actually a) it is a redirect to actual code template {{Narrow no-break space}}, and b) that template takes parameter |1 then envelopes that input between two NNBSP's. - DePiep (talk) 22:36, 15 March 2018 (UTC)

I wasn't proposing to use the template itself—I said "as in {{nnbsp}}". Curly "JFC" Turkey 🍁 ¡gobble! 23:03, 15 March 2018 (UTC)

Yes I know I know. This thread shows I am thinking along. How could we write a refined proposal? - DePiep (talk) 23:27, 15 March 2018 (UTC)

I actually don't see any Unicode character encodings that will not create more issues than they resolve. All quantities formatted by {{convert}} (and by inference, eventually also by {{val}}) would be affected. Multiple characters (e.g. two thin spaces) would be unsuitable due to considerations of copying of text from the page. The non-breaking, width and expanding properties would have to be suitable and nearly uniformly implemented across all fonts, browsers, etc. No Unicode character appears to meet all these criteria (see Whitespace character). This leaves us to consider HTML styles to address the unfortunate expanding property instead of Unicode. Is there a span style that "protects" a piece of text from being justified (stretched)? —Quondum 23:53, 15 March 2018 (UTC)

I tried say: forget the justfication issue. Let's go {{NNBSP}} always, when between number–unit. WP:MOSNUM. {{Convert}}, {{Val}}. - DePiep (talk) 00:01, 16 March 2018 (UTC)

Ignoring the justification quirk, what is the motivation to make the change? To reduce the space between a number and the units? This is a completely different intent/topic from what has been discussed in this thread thusfar. —Quondum 00:52, 16 March 2018 (UTC)

The OP re justification is served still. Just with an other reasoning. - DePiep (talk) 20:11, 19 March 2018 (UTC)

While I agree with at least the idea of preventing the space stretching, do not agree with reducing the width of the space between the numeric part and the units from a that of a standard space. And a thin space for its own sake does not seem to have spoken of at all, other than for before the ° symbol. The far-reaching impacts of changing the space character from a standard non-breaking space would require a solid motivation. —Quondum 01:01, 20 March 2018 (UTC)

On second thought: only apply with ° units (and after °R, there are no other units with a similar sup-like symbol). Then, for this reason (as a reply to Quondum): not to satisfy obscure justify-situations (as OP claims), but because typographically the °-unit starts with extra whitespace (below the degreee-symbol), and so typographically improves by reducing the space width. In all alignment situations (including the justifications as OP). This being a more generic, and so better than only for the special situation reasoning. - DePiep (talk) 07:26, 20 March 2018 (UTC)

I disagree. The stretching looks just as awful with other units, such as 22 cm or 19 kg. Curly "JFC" Turkey 🍁 ¡gobble! 11:08, 21 March 2018 (UTC)

A summary might be useful:

• When a user's preferences are set to 'justify', in at least several browsers the non-breaking space between the number and the unit symbol stretches like any other space, whereas this use would look better not stretching. The 'justify' option is not the default, so it is unlikely that this would affect many people.
• DePiep has expressed a preference to reduce the space between the number and a unit symbol starting with ° due to the perceived additonial space.
• Any changes that impact the display or the effect of a copy-paste from the article of the majority of people must be treated with utmost care, with testing needed across a wide array of platforms and browsers.
• I have looked at the available Unicode spaces, and have not found anything that would not produce disproportionate impacts. No-one appears to have investigated HTML solutions (e.g. using <span> tags).

—Quondum 12:55, 21 March 2018 (UTC)

Thanks for the recap. My thoughts reordered: I could agree with using the NNBSP before the degree sign (today: °C, °F, °R), but for other reason that the OP mentions. IOM acceptable to improve between-character distancing wrt their whitespace. Would be OK in all line showing, not only justification. With other units (alphabetic first character), justification issues should not govern or dictate this spacing at all. It is the browser's rendering, not our spacing, that causes the problem. (Font designers could ask for a "fixed width space", breaking an non-breaking?). -DePiep (talk) 07:34, 24 March 2018 (UTC)

But if all browsers render it this way, how is it a browser issue? Curly "JFC" Turkey 🍁 ¡gobble! 02:33, 29 March 2018 (UTC)

Whether all browsers are consistent in this regard is merely a hypothetical. Since there is no standard in this regard, and we have known non-browser counterexamples (such as MSWord), it is a crapshoot as to whether the next version of any given browser will retain the same behaviour. On the impact side, any Unicode-based possibility is likely to render inconsistently in different browsers. For example, the thin space does not render with a consistent width on different browsers and fonts. —Quondum 11:43, 29 March 2018 (UTC)

Convert extension at Phabricator

The idea of having a centralized extension to implement convert has been raised at phab:T190813. That idea was floated years ago but I don't think any work was done. A universal convert is appealing but it would be complex! People may like to follow the discussion. Johnuniq (talk) 08:04, 28 March 2018 (UTC)

Anyone can calculate 1 horsepower into x kW's (or kWh's, J/km, psi/s/kg or whatever). But let us be clear: {{Convert}} by Johnuniq already does this, both for input and output(!). And also: 1. Apply 2013-legacy issues; 2. Apply English grammar, punctuation & spelling quirks and questions; 4. enwiki:MOS; 5. Apply rounding both scientific and communal, and 6. don't forget: the "ft-in" unit set is a problem by itself (German, dewiki, does not even care about). 7. Also, {{Convert}} already has the table sorting sorted out all right, conceptually & correctly (by Jimp). Now let Wikidata and mw chew on this. Yes they can start anew -- hope they can make use of that. A world all metric & decimal, without ft/in! :-) -DePiep (talk) 03:39, 29 March 2018 (UTC)

Yes, convert has more corners than first meets the eye. I don't think dewiki would even want a convert template/extension except for specialized (and simple) uses. They are very sensibly SI. Johnuniq (talk) 04:12, 29 March 2018 (UTC)

You cannot convert horsepower into kWh - one has a time factor, the other does not. You can convert horsepower-hours into kWh very easily - the conversion factor is exactly the same as for converting horsepower into kW. Similarly, converting horsepower into J/km or psi/s/kg is meaningless. It's like converting pounds into inches. --Redrose64 🌹 (talk) 20:23, 29 March 2018 (UTC)

Redrose64, here you missed the point. - DePiep (talk) 20:41, 29 March 2018 (UTC)

Idea for a new range value

Hello fellow Wikipedians! As another user said above, thanks to all the users who have maintained this fantastic template, everyone appreciates your work! I did come across something that might be good to add. I was updating an article which needed more instances of this template, and came across this sentence: "...26 out of 27 miles..." I looked in the ranges section of the documentation, but couldn't find anything that could help display this. I also searched the talk page's archive, but couldn't find anything relevant. Is this something that would be useful to others? For now, I just wrote the conversion in manually, with the kilometer value in parentheses. Let me know what you think. Thanks! –Daybeers (talk) 07:04, 23 March 2018 (UTC)

We've got a whole page full of range separators to choose from, but no way I know of to use arbitrary text like we do with disp=x for measurement separators. I have never had use for such a feature myself. You could use two separate conversions with disp=number and disp=out.

"26 out of 27 miles ({{convert|26|mi|disp=number}} out of {{convert|27|mi|disp=out}})": 26 out of 27 miles (42 out of 43 km). Kendall-K1 (talk) 11:35, 23 March 2018 (UTC)

That's a good solution which will do because the issue has not arisen before. However, it might be reasonably straightforward to support the following syntax:

{{convert|26|range|27|mi|range=out of}}

That is, the word "range" would be recognized as a placeholder that would be replaced with the value of the parameter (or "to" if no non-empty range parameter given). Convert would insert a space before and after the given range text. I can't think of a clean way to allow ranges with no space (other than requiring something like &#32;). I would like to see some examples where this would be used to get confidence that a new parameter would work and be worthwhile. Johnuniq (talk) 02:56, 24 March 2018 (UTC)

Subtopic: adding spaces

On the addition of prefixed and suffixed spaces. As Johnuniq noted, it is hardly imaginable that the proposed |range= parameter would require its injection unspaced. However, I'd like to consider a general approach to this issue for all grammatical and punctuation issues. The question would be: "How to govern and control whether spaces before and after are added?". As {{Convert}} has now, most situations are predefined to have one or none added, and there is a special occasion where it is read from editor's input. Some examples of word & punctuation adding:

• {{convert|1/8|imppt|mL|spell=in|adj=pre|of an}} → one-eighth of an imperial pint (71 mL)
• {{convert|10|ft|m|adj=on}} → 10-foot (3.0 m)
• {{convert|10|to|20|ft|m|adj=on}} → 10-to-20-foot (3.0 to 6.1 m)

• {{convert|10|ft|m|adj=mid|-long}} → 10-foot-long (3.0 m)
• {{convert|4|acre||disp=preunit|planted}} → 4 plantedacres (1.6 plantedha) -- note spacing
• {{convert|4|acre||disp=preunit|planted }} → 4 planted acres (1.6 planted ha) -- note spacing
• {{convert|4|acre||disp=preunit|planted |reforested-}} → 4 planted acres (1.6 reforested-ha)

• {{convert|26|range|27|mi|range=out of}} → 26 out of 27 miles (42 out of 43 km) -- proposal

Proposal: adapt the principle: "For user-optional input: underscore "_" before or after is shown (kept) as a space".

Thoughts: would reverse the default in many cases (where space adding is more obvious/natural). And what to do when NBSP is needed? This is of conceptual approach, I have no examples of where it is needed (though we did meet some spacing/nonspacing issues IIRC; re $-signs for example when the unit is unspaced). Also, introduction would be a long-term shot, if accepted at all. -DePiep (talk) 07:23, 24 March 2018 (UTC)

Add "... for all user-defined words"? Looks like this would cover most cases, and not interfere with regular adjective forming. - DePiep (talk) 07:42, 24 March 2018 (UTC)

Using underscore is a good idea. As a matter of fact, I did that recently in a new module (Module:Particles). The simplest for the module would be to replace all underscores with a space, so range=_out_of_ would generate " out of " with three spaces. Changing a default is awkward but it would be best to have a simple rule, namely that convert always replaces underscores with spaces and never adds an extra space. I would need to investigate how many existing converts would be affected. Johnuniq (talk) 08:17, 24 March 2018 (UTC)

Due to inconsistent WP template behaviour wrt spaces, some workaround such as mentioned by Johnuniq sensible. It may not be a universal solution for adoption by all templates, but would probably work well here.

I suggest stripping leading and trailing spaces, then replacing only a leading or trailing underscore with a space (as per DePiep's proposal), but not replacing other where they are not the first or last character of the parameter value. This leaves flexibility for the editor to include arbitrary text, including underscores (the only difficult instance is when the editor wants a leading or trailing underscore in the output without also getting a space). Automatic substitutions create future headaches, so they should be kept to a minimum. —Quondum 17:15, 24 March 2018 (UTC)

inconsistent WP template behaviour: no, not inconsistent. Consistent yes, complicated: yes too. In this it is not about template behaviour, but about the editor being able to command the output. I am still in favor of "_" for maintaining pre/suf-fix spaces showing. DePiep (talk) 20:48, 29 March 2018 (UTC)

I fail to understand this as a response to my comment. I was agreeing with your (DePiep's) suggestion of replacing a leading or trailing underscore with a space, but suggest leave any other underscores, contrary to what Johnuniq said. That is, "range=__out_of_" would generate " _out_of " (note two leading underscores in this example). —Quondum 22:14, 29 March 2018 (UTC)

I replied to your post, as quoted. Anyway, I leave this thread. Johnuniq will have seen what is useful and not. -DePiep (talk) 22:20, 29 March 2018 (UTC)