Template talk:Convert/Archive November 2019

Litres per square metre

Is there a way to add litres per square metre for rain fallen in a certain amount of time? It is equivalent to millimetres/inches of rain, but doublets exist such as millibar and hectopascal.--Carnby (talk) 16:05, 4 November 2019 (UTC)

Is this ok? {{convert|1|l/m2/h|impgal/sqft/h|abbr=off}} 1 litre per square metre per hour (0.020 imperial gallons per square foot per hour) -- WOSlinker (talk) 16:24, 4 November 2019 (UTC)

Is it possible to skip the amount of time? The source I read says (in German) "60 Liter pro Quadratmeter".--Carnby (talk) 16:41, 4 November 2019 (UTC)

How about {{convert|60|l/m2|impgal/sqft|abbr=off}} → 60 litres per square metre (1.2 imperial gallons per square foot) Or, try abbr=on. Johnuniq (talk) 23:13, 4 November 2019 (UTC)

Thank you.--Carnby (talk) 09:25, 5 November 2019 (UTC)

Canonical unit code for square kilometres

Any thoughts about Getsnoopy's edits to convert's documentation?

• Template:Convert/doc • diff
• Template:Convert/list of units/extra • diff

I reverted a third change at Module:Convert/documentation/conversion data for technical reasons but the above two are a matter of taste that I don't have a strong feeling about. The issue concerns whether the documentation should encourage use of km2 or sqkm for square kilometres. For lengths areas, the defined unit is km2 and sqkm is an alias for km2. However, for "per unit area", the situation has traditionally been reversed with PD/sqkm as the defined and documented unit, and PD/km2 being an alias. It's one of those cases where consistency is not quite consistent—the "per unit area" units have traditionally used sqcm + sqin + sqkm + sqmi and changing sqkm to km2 reduces that consistency. Also, mi2 works as an alias for sqmi (by analogy with km2), but PD/mi2 is not defined. What should happen? Johnuniq (talk) 06:59, 23 October 2019 (UTC)

@Johnuniq: as the unit codes km2 and sqkm are aliases of each other, then in practice, it shouldn't really matter which is used in the documentation. From that point of view, the edits are what I think of as "twiddling", because somebody else with a different personal taste could come along and quite legitimately change them back to the other version ("to match the sources / common practice", etc.). Nevertheless, I suppose that folks who habitually use SI units, particularly non-native English speakers, might find km2 more natural, so I have some sympathy for the change. Anyway, unless it turns into a back-and-forth, my inclination would be to let it be and don't sweat the small stuff (it's all small stuff). Cheers --RexxS (talk) 12:50, 23 October 2019 (UTC)

I think it should be consistent with other parts of the template / usage. For SI units, since it's expressed mathematically (with exponents), that should be the case for all square and cubic units (km2, cm2). For imperial/US customary units, use the abbreviated words (sqmi, sqin). Getsnoopy (talk) 17:43, 23 October 2019 (UTC)

@Getsnoopy: yes we know you think that. But that's your personal preference, and if somebody else's personal preference is to follow the sources that they have read, it would carry as much weight as your preference. How should that be resolved? --RexxS (talk) 18:16, 23 October 2019 (UTC)

@RexxS: It's not my preference, it's the pre-existing preference of the template and its documentation: mathematical for SI units, and word abbreviations for imperial/USC. The case of density measurements obviously seems like an anomaly, so we should bring it in line with the rest. I'm merely reaffirming that whatever logic was used to decide the pre-existing preference makes sense: since the output of the template is always mathematical for SI units and word abbreviations for imperial/USC, it would be logical to mirror that for the unit codes as well. Others following sources they've read is irrelevant, since that would have to do with the output of the template. Unless you're referring to sources about which unit code to use specifically for the {{convert}} template? Getsnoopy (talk) 22:34, 23 October 2019 (UTC)

Any chance of responding to the points in my comment? Given that no one has raised a problem it's likely your changes will stand but it would be nice to think my comment had at least been read. Johnuniq (talk) 00:13, 24 October 2019 (UTC)

All native English speakers will use km² and mi² as these are the standard abbreviations in their countries. This includes the old imperial measurements; word abbreviations are not customary. cf. [1] km2 and sqkm are just Wikipedia constructs used by the template. The former must always be output by the template. The use of the sqkm etc in the templates, and which one is the alias means little, but the km2 would be more consistent, if consistency is desired. Hawkeye7 (discuss) 03:02, 24 October 2019 (UTC)

I don't know what the issue-in-chief is here, but if Hawkeye's saying that native English speakers never write sq mi, that's just plain untrue. I would certainly predict that sq km is never seen, however. EEng 03:31, 24 October 2019 (UTC)

Of course km2 is the preferred unit code for an area: that's not the issue. Knowing how coders work, I can guess that when population per area units were added, the person doing that strove for consistency with sqin matching sqcm, and sqmi matching sqkm. See my opening post above. As mentioned, it's not a big deal to me but I was asking what people think about the consistency of occurrences per sqin/sqcm and sqmi/sqkm, as opposed to promoting the use of km2 everywhere. It doesn't matter so let's forget it. Johnuniq (talk) 04:38, 24 October 2019 (UTC)

@Johnuniq: Yes, I was responding in sort of a general statement which applied to your comment as well: consistency should be maintained throughout. So that would mean creating PD/mi2. Then, set the canonical codes to /cm2, /in2, /km2, PD/km2, /sqmi, and PD/sqmi. Finally, set their corresponding counterparts as aliases. As per @Hawkeye7, almost everything is aliased, so I too thought that it wasn't a big deal, which is why I made the change in the first place. If technical correctness is the issue, we should just change it so that it becomes correct. Getsnoopy (talk) 06:47, 25 October 2019 (UTC)

@Johnuniq: Any update on this? Should I revert your revert? Getsnoopy (talk) 22:03, 6 November 2019 (UTC)

No, why would you want to revert an edit which corrected an error? The way to get action at this page is to provide an example where there is a problem in an article. Johnuniq (talk) 00:02, 7 November 2019 (UTC)

@Johnuniq: You said it doesn't matter either way (and so did the others), so my changes stand. But you didn't say anything further regarding my reply. Getsnoopy (talk) 23:51, 8 November 2019 (UTC)

I don't have the patience for twenty questions at the moment. If there is something needed, please provide an example of a convert in an article and explain why it is a problem. Johnuniq (talk) 00:41, 9 November 2019 (UTC)

Edit request

Please edit TemplateData, and remove the deprecated for disp. As disp=flip is deprecated but disp=or for example is not (and neither are: disp=preunit, disp=sqbr, disp=comma, disp=number, etc. ). comrade waddie96 ★ (talk) 08:42, 18 November 2019 (UTC)

That looks desirable: I'm not sure how it came to be marked that way. However, I'll leave it for others. The wikitext is in the template documentation (Template:Convert/doc) which is not protected. Johnuniq (talk) 08:50, 18 November 2019 (UTC)

Adj parameter

Would it be possible to allow "adj=yes" as well as "adj=on"? I have trouble remembering all of the variations amongst templates, and it would be useful if some of these settings could conform to others. Laterthanyouthink (talk) 07:47, 29 November 2019 (UTC)

I can see arguments for and against. The history is that convert uses on and off consistently and has done for many years—probably from before many other templates thought it desirable to accept anything that might mean "on". Module:Yesno accepts yes/y/true/t/1 and variations such as YES/yEs/TruE—that's from a somewhat old school of thought known as Postel's law. A benefit of the current situation is that the wikitext for converts is very consistent with on/off being used for several parameters. The good news is that convert tells you if it doesn't like a parameter. Johnuniq (talk) 08:49, 29 November 2019 (UTC)