Jump to content

Template talk:Convert/Archive August 2017

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Section on spelling of unit name

The section Template:Convert#Spelling of unit name: UK metre or US meter? is misleading (or at least seriously incomplete). Spellings such as "metre" or "litre" are not just en-UK, they are the correct SI spellings. It happens that en-UK, like many other variants of English, uses the correct spelling of SI units, unlike en-US. I attempted to correct this, but was reverted. I don't care about the exact wording, but I do care that editors are told that the default spelling for SI units is the SI spelling, not specifically en-UK. The section title should be "Spelling of unit name: SI metre or US meter?". Peter coxhead (talk) 21:04, 21 August 2017 (UTC)

ISO and CGPM are not the ultimate arbiters of US English spelling, even for the units that they standardize. Kendall-K1 (talk) 21:10, 21 August 2017 (UTC)
My understanding is that only the symbols are standardized in all languages. When units are spelled out, the spelling varies from language to language. Jc3s5h (talk) 21:32, 21 August 2017 (UTC)
(ec) I did the revert [1]. First of all, the option |sp=US is not to allow "follow SI spelling" versus "deviate from SI spelling". It is to allow an article to be consistently written in en-UK or in en-US language, both inside and outside of {{Convert}}. This is an WP:ENGVAR policy. The documentation text reflects this by showing "UK" and "US" next to each other. Which one is SI is not relevant for this.
Secondly, I doubt whether SI prescibes (defines) words in one of the spellings (eg, en-UK metre as Peter coxhead states). First of all, in general there might be units not in SI at all that take variant spellings. These too would be set using |sp=, clearly without any SI definition at all (because of this parameter generality, I don't see a need to supply examples). Second, SI does not define the name of a unit[1]. It just uses an English name (and a French name). While OTOH, the symbol is strictly prescibed, including capitalisation, roman/italic?, font variants allowed?, etc. (to compare, the name's formatting & writing is governed by grammar and editorial style like typefont freedom!, pluralisation). A name can also be in Russian/Cyrillic, a symbol does not change. In short: SI does not interfere with language (names), and concentrates on the algebraic format of quantity values (measurements), numbers & unit symbols.
ISO/IEC 80000[2] says (7.2.1; bolding added): The rule for writing unit symbols with a capital initial is not applicable for unit names, which differ from language to language. For this issue, I dare saying that en-UK and en-US may be considered different languages.

References

  1. ^ International Bureau of Weights and Measures (2006), The International System of Units (SI) (PDF) (8th ed.), ISBN 92-822-2213-6, archived (PDF) from the original on 2021-06-04, retrieved 2021-12-16
  2. ^ Standards Catalogue TC/12 Quantities and Units
TL;DR: The option that |sp=US/UK introduces is to support WP:ENGVAR per article. SI does prescribe symbol writing, not name writing (which is guided by language, grammar, editorial style, and then ENGVAR style). Unit names are language-dependent, and en-UK vs. en-US may be considered different languages in this issue. Omitting SI name-writing in this section is not "misleading" nor "seriously incomplete". SI is not relevant in there. -DePiep (talk) 22:25, 21 August 2017 (UTC)

Module version 19

Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

The examples use fixed wikitext for the output to show what the new version would produce so they will not change in the future.

  • Units
    • Add unit Rd (rutherford) as it was added to Module:Convert/extra and is used in articles. Discussed here.
      • {{convert|12,300|Rd|abbr=off}} → 12,300 rutherfords (12,300 megabecquerels)
      • {{convert|12,300|Rd|abbr=on|lk=in}} → 12,300 Rd (12,300 MBq)
    • Add unit chlk (chain) which is always linked (use ch for chain with no link); with abbr=on, "ch" is displayed. Discussed here.
    • Add unit chainlk (chain) which is always linked (use chain for chain with no link); with abbr=on, "chain" is displayed.
    • Add units michlk and michainlk which can be used as output units to display miles and chains, where "chains" is linked.
    • Units chlk and chainlk can be used as combination input units with miles.
      • {{convert|12.3|km|chlk}} → 12.3 kilometres (610 ch)
      • {{convert|12.3|km|chainlk}} → 12.3 kilometres (610 chains)
      • {{convert|50|mi|49|chlk}} → 50 miles 49 chains (81.5 km)
      • {{convert|50|mi|49|chainlk}} → 50 miles 49 chains (81.5 km)
      • {{convert|3652|yd|michlk}} → 3,652 yards (2 mi 6.0 ch)
      • {{convert|3652|yd|michlk|abbr=off}} → 3,652 yards (2 miles 6.0 chains)
      • {{convert|3652|yd|michainlk}} → 3,652 yards (2 mi 6.0 chain)
  • Errors can be detected
    • Error messages include <span class="error"></span> so {{#iferror}} can detect when convert generates an error. Discussed here.
  • input=...
    • As a special case for infoboxes, a length can be specified in feet and inches. When valid input is given, a conversion occurs. Otherwise, the output is a copy of the input. Discussed here.
      • {{convert|input=5 ft 10+1/2 in}} → 5 feet 10 1⁄2 inches (1.791 m)
      • {{convert|input=five ft ten in}} → five ft ten in
    • A new tracking parameter can be used to track articles using convert with |input=... where the input was not interpreted by convert. The category is Category:Convert tracking and the tracking parameter specifies the category sort key.
      • {{convert|input=five ft ten in|tracking=ftin}} → five ft ten in[[Category:Convert tracking|ftin]]

Release notes for earlier versions are listed here. My motivation for adding the new chain units was that during the earlier discussion I had a feeling that convert had a method to always link a unit, and which would not double-link the unit with lk=on. I found the method and thought it worth trying. Johnuniq (talk) 05:57, 15 August 2017 (UTC)

So when "input was not interpreted by convert" category Category:Convert tracking is added. Is this also an #iserror status? And, more in general, is each and every 'warning/issue' situation classified as error? (Would be irrespective of categories and[maintenance tag] addings I understand) -DePiep (talk) 18:52, 16 August 2017 (UTC)
No, "input was not interpreted by convert" is not regarded as an error. That is the fundamental point of input=..., namely that it can be used in an infobox and it will never be an error—it will either work or will show the input as given. An exception is that if a Wikidata property like |input=P1234 is used, an error fetching the property causes convert to display nothing, and it is not an error. That allows an infobox to display a property if it exists for the current page, but to show nothing if it doesn't.
The tracking category allows a template designer to choose to add a tracking category if convert fails to interpret the input.
Whenever convert shows a warning or error, class="error" is used in the message and #iferror will detect it. Examples:
  • {{convert|1.5|m|disp=/|test=nopreview}} → 1.5 metres (4 ft 11 in)*
  • {{convert|1.5|m|disp=or|test=nopreview}} → 1.5 metres or 4 feet 11 inches
  • {{#iferror:{{convert|1.5|m|disp=/|test=nopreview}}|bad|good}} → bad
  • {{#iferror:{{convert|1.5|m|disp=or|test=nopreview}}|bad|good}} → good
Johnuniq (talk) 01:31, 17 August 2017 (UTC)

Something has been left out

To abbreviate both:

  • {{convert|1|lb|kg|abbr=on}} → 1 lb (0.45 kg)
  • {{convert|1|lb|kg|abbr=off}} → 1 pound (0.45 kilograms)

There should be a "To spell out both:" header between these two lines of code. --Khajidha (talk) 16:46, 23 August 2017 (UTC)

Thanks. That refers to Template:Convert/doc#Unit name or symbol (abbreviation): 1 pound or 1 lb?. I'm hoping someone will check that. Johnuniq (talk) 01:47, 24 August 2017 (UTC)

Displaying a formatted value?

Is there a way that this template could be used to show (fetched from Wikidata) as 56°18', without including any conversion factors? Or is there another template that could do that? Thanks. Mike Peel (talk) 01:27, 11 August 2017 (UTC)

This was discussed at Template talk:Convert/Archive September 2015#Angle conversions but didn't go anywhere. Can you give us some examples of where this would be useful? Kendall-K1 (talk) 02:13, 11 August 2017 (UTC)
I do not know of any such templates although I have recently been patching some modules at bnwiki and noticed some code that deals with such things. Rather than further complicate their enwiki equivalents, it might be better to add something to {{val}} which would need code similar to convert's to access Wikidata (or call it), and code to convert a decimal angle to DM or DMS and display it. I would prefer that rather than adding more gumph to convert. I can guess what you're up to, but per Kendall-K1, please give a couple of examples to focus my mind. Johnuniq (talk) 04:15, 11 August 2017 (UTC)
@Kendall-K1 and Johnuniq: The motivation for my request is the 'slope' parameter in the infobox at Pyramid of Unas, where spelling out 'degrees' doesn't look great, and the other articles that use {{Infobox pyramid}} (which I'm currently converting to use Wikidata). Another example I just came across where this is useful is from lvwiki, where they only use metric units, so for infoboxes ported there it would be useful to still keep the formatting that convert shows but not to do the conversion from metric to imperial. Thanks. Mike Peel (talk) 10:54, 11 August 2017 (UTC)
That has typical Wikidata nonsense where anything can be used in a field: Snowdon Mountain Railway (Q1798093) has 0.1272±0 for average gradient (P2198) whereas Pyramid of Unas (Q1478801) has 56.3 degree. It will be a few days before I can think about this.
For lvwiki, it may be possible to provide convert modules with the units removed, then rely on defining units in Module:Convert/wikidata/data such as is done for things like: {{convert|input=12.3 kV}} → 12.3 kilovolts Johnuniq (talk) 11:15, 11 August 2017 (UTC)
I couldn't find the right property on Wikidata, so I slightly misused an existing one as a temporary measure, sorry. ;-) I've already proposed a new property to use for angles, at d:Wikidata:Property proposal/angle, hopefully that will be implemented soon and I can use that more consistently. Thanks. Mike Peel (talk) 11:43, 11 August 2017 (UTC)
My snark was directed at the underlying design which puts all the work and responsibility of interpreting results in each of the hundred modules that try to access Wikidata, in each of the hundred Wikipedias that use it. Sorry if it looked like I was being pointy about an editor! Johnuniq (talk) 23:42, 11 August 2017 (UTC)
Hear, hear. I can add: Wikidata is available to outside websites too. (Anyone can read WD data and show it). That means those interpretations are outside of any Wiki control even. Meanwhile, we can not add the iconic standard atomic weight as a mass (P2067), nor specify it unambiguously otherwise. -DePiep (talk) 09:27, 12 August 2017 (UTC)
No worries, I just want to get things to work right. Interpretation is always subjective, and Wikidata does just present the facts rather than the context, but that's both a pro and a con. Have you seen the constraints on property values that try to keep the values they contain consistent with each other? I think there's a background to the atomic weight point that I'm not aware of? Thanks. Mike Peel (talk) 22:37, 13 August 2017 (UTC)
I mentioned the atomic weight only to illustrate the Wikidata issue Johnuniq mentioned, outside of the question you asked. That said, this is not about 'context' that Wikidata does not include. Wikidata omits (essential) properties of its data. -DePiep (talk) 18:56, 16 August 2017 (UTC)
Aah, I see that atomic weights are complicated... Thanks. Mike Peel (talk) 21:42, 16 August 2017 (UTC)

As a thought with the metric-only measurements, maybe the converted value could be hidden if the input and output units are the same. E.g. {{convert|input=P2044|km|abbr=on}} at South Pole Telescope currently returns "2.8 km (2.8 km)", maybe it could just return "2.8 km" in that case. I think that would also work OK on other language Wikipedias. Thanks. Mike Peel (talk) 00:38, 29 August 2017 (UTC)

That is a problem. I put it at the top of my convert to-do. Johnuniq (talk) 00:55, 29 August 2017 (UTC)
Thank you. Mike Peel (talk) 00:57, 29 August 2017 (UTC)

input = value1 value2 ftin

  • Update: I substituted the ftin examples because I'm planning to replace that with something possibly better. That is, ftin will not work. See below. Johnuniq (talk) 05:55, 30 July 2017 (UTC)

I have updated the sandbox to test the proposal to allow ftin with |input=.... There is also a new |tracking=X parameter to append a tracking category with sort key X if 'input=...' does not result in a conversion. X can be any non-empty text. In that case, Category:Convert tracking is appended, but only in articles. I will create the category if we agree it is useful. Examples:

  • {{convert/sandbox|input=5 9+1/2 ftin}} → 5 feet 9 1⁄2 inches (1.765 m)
  • {{convert/sandbox|input=5 9+1/2 ftin|cm|abbr=on}} → 5 ft 9 1⁄2 in (176.5 cm)
  • {{convert/sandbox|input=2&nbsp;6&nbsp;ftin|in|abbr=off}} → 2 feet 6 inches (30 inches)
  • {{convert/sand3/8box|input=5 9½ ftin}} → 5 9½ ftin
  • {{convert/sandbox|input=5 9½ ftin|tracking=NFL}} → 5 9½ ftin (in an article, this would add [[Category:Convert tracking|NFL]])
  • {{convert/sandbox|input=5 V}} → 5 V
  • {{convert/sandbox|input=5 V|tracking=VOLT}} → 5 V (in an article, this would add [[Category:Convert tracking|VOLT]])
The third example shows that &nbsp; is translated to a space. Multiple spaces are the same as a single space.
The 5 V example would make more sense if the input were from a Wikidata property.

This needs to be tested to see if it works and is useful. I also need to slowly check the changes I made because it's a bit rushed at the moment. Johnuniq (talk) 09:43, 29 July 2017 (UTC)

Looks great, a fine setup. Will be testing later on. Initial question:
  • With fractions, {{Convert}} requires a "+" be added. However, this is not the RL formatting. Since we can expect fractions in the sources correctly being used as "9 1/2" (/ or ⁄), it would be great if this input format adds that "+" sign internally. The other option is to pre-process the input value, or by documentation add the requirement (or outlawing fractions). -DePiep (talk) 11:39, 29 July 2017 (UTC)
  • I plan to put that in another module. I will probably use Module:Biglist to experiment. We can later decide whether it is useful, and where to put it. I'm still not sure people will want conversions in that template, but we'll see. Johnuniq (talk) 06:04, 30 July 2017 (UTC)
OK. Other preprocessing (= edit input in MyTemplate before entering it into this {{Convert}} option): what if |ft= is 0 or blank? |in= is 0 or blank? However, this is easy to check and/or can be outlawed in MyTemplate documentation (when not realistic situations). Just mentioning this in case you're interested.
wrt Template:NFL predraft: When the current layout changes are accepted & live, I'll testcase and promote the {{Convert}} adding, using this new option. BTW, the option could also simplify & enhance {{Convinfobox}}. -DePiep (talk) 09:44, 30 July 2017 (UTC)

New plan It occurred to me that there is no need to use a fake ftin because it is just as easy for the extra code to process separate ft and in.

  • {{convert/sandbox|input=5 ft 9+1/2 in}} → 5 feet 9+1⁄2 inches (1.765 m)
  • {{convert/sandbox|input=5 ft 9+1/2 in|cm|abbr=on}} → 5 ft 9+1⁄2 in (176.5 cm)
  • {{convert/sandbox|input=2&nbsp;ft&nbsp;6&nbsp;in|in|abbr=off}} → 2 feet 6 inches (30 inches)
  • {{convert/sandbox|input=5 ft 9½ in}} → 5 ft 9½ in
  • {{convert/sandbox|input=5 ft 9½ in|tracking=NFL}} → 5 ft 9½ in (in an article, this would add [[Category:Convert tracking|NFL]])

I assume this is better and I should forget about the earlier ftin? Johnuniq (talk) 05:55, 30 July 2017 (UTC)

Yes. -DePiep (talk) 09:44, 30 July 2017 (UTC)

Preprocess fraction input

About pre-processing fractional input for {{convert}}, resulting in module:Convert/helper

I have done a quick experiment for a preprocessor to pass parameters to convert. I parked it in Module:Biglist but it can be moved later if needed. I have not tried it apart from what follows and I expect it will need tweaking.

  • {{#invoke:convert/helper|number|12 3/8}} → 12+3/8
  • {{#invoke:convert/helper|number|{{frac|12|3|8}}}} → 12+3/8
  • {{#invoke:convert/helper|number|12{{frac|3|8}}}} → 123/8
  • {{#invoke:convert/helper|number|12⅜}} → 12+3/8

Johnuniq (talk) 11:10, 30 July 2017 (UTC)

Allow me:
  • {{#invoke:convert/helper|number|3/8}} → 3/8
  • {{#invoke:convert/helper|number|12 3&frasl;8}} → 12+3/8
  • {{#invoke:convert/helper|number|12 3⁄8}} → 12+3/8
  • {{#invoke:convert/helper|number|12½}} → 12+1/2
  • {{#invoke:convert/helper|number|12¼}} → 12+1/4
  • {{#invoke:convert/helper|number|12¾}} → 12+3/4
  • {{#invoke:convert/helper|number|12⅛}} → 12+1/8
  • {{#invoke:convert/helper|number|12⅜}} → 12+3/8
  • {{#invoke:convert/helper|number|12⅝}} → 12+5/8
  • {{#invoke:convert/helper|number|12⅞}} → 12+7/8
Input like "½" as a character is not expected from keyboard, but might occur by: copy-pasting, accepted usage in article titles, other lang-wikis (where it might be accepted in text).
  • {{#invoke:convert/helper|number|½}} → 1/2
  • {{#invoke:convert/helper|number|½}} → 1/2
  • {{#invoke:convert/helper|number|⅞}} → 7/8
  • {{#invoke:convert/helper|number|12}} → 12
  • {{#invoke:convert/helper|number|12.5}} → 12.5
-DePiep (talk) 12:43, 30 July 2017 (UTC)
Thanks for the testcases. I fixed some problems. I agree with "not expected" but articles use fractions, for example Eric Berry has "height in = 11⅝". Johnuniq (talk) 23:05, 30 July 2017 (UTC)
Yes it's good these are covered. It all looks good & smart. BTW, how is module:Biglist a logical place to add this? And, maybe "preprocess" is too generic, while it is quite specific: "normaliseInputForConvertWhenFractionsAreUsed" or so. -DePiep (talk) 10:51, 31 July 2017 (UTC)
I've added two testcases (bare ½, ⅞), late, to the list. They test OK. -DePiep (talk) 21:28, 31 July 2017 (UTC)
When a sandbox NFL template has been accepted, or at least not rejected, we can work out the details. Do you have a suggestion about where preprocess could go, or what better name could be used? Self-explanatory names are good, but normaliseInputForConvertWhenFractionsAreUsed is too long. There could be a Module:Convert/helper which was not used by the main module but which held functions related to convert, starting with preprocess. Or, I was thinking of Module:Sport at one time when I noticed some very convoluted templates causing articles to run into template limits. I forget where that was, but I could find it in a tracking category. Johnuniq (talk) 02:30, 1 August 2017 (UTC)
I was doing some computer clean-up and noticed something that made me think the article that might need Module:Sport is List of Olympic medalists in athletics (men). That's not relevant here, but I'm noting it for my future reference. Johnuniq (talk) 04:39, 1 August 2017 (UTC)
If you find module:Convert/helper acceptable, that's OK then. Function then could be named "formatfrac" or "normalisefrac". Name "preprocess" might be too generic (later other preprocess jobs could be added). -DePiep (talk) 10:22, 1 August 2017 (UTC)
What about just "number" or "fraction" which would make sense in {{#invoke:convert/helper|number|12¾}}? Johnuniq (talk) 10:55, 1 August 2017 (UTC)
I myself would add a hint to the formatting/normalisation process (a verb). But go as you think best, too much detail. -DePiep (talk) 11:15, 1 August 2017 (UTC)
OK, in 24 hours should do. Let's not debate the name much more but to explain my opinion, there is no simple phrase that would describe the function, so just using an English word related to the function makes it easy to remember and use. For example, formatfrac suggests an equivalent of {{frac}}, and normalisefrac might suggest reducing 4⁄16 to 1⁄4. Johnuniq (talk) 11:28, 1 August 2017 (UTC)
module:Convert/helper name is good. I'll see what happens and then adjust the sandbox into the new name. I'm off for now. btw, could you check {{#invoke:convert/helper|number|12{{frac|3|8}}}} → 123/8 (expect 12+3/8 right? was OK above). -DePiep (talk) 11:53, 1 August 2017 (UTC)
That was a blunder which I have now fixed, thanks. My comment at 11:10, 30 July 2017 above shows I thought it worked. In fact it did work for a while but I tweaked the module and broke it. I'll look at convert/helper soonish. Johnuniq (talk) 05:31, 2 August 2017 (UTC)
(Not a blunder, thing happen when you're working -DePiep (talk) 10:34, 2 August 2017 (UTC)
  • Johnuniq I suggest adding ⅓ and ⅔ to module:convert/helper for completeness. I'm not sure if there are more fraction characters (the 1/8 series is complete).
{{#invoke:convert/helper|number|12⅓}} → 12+1/3
{{#invoke:convert/helper|number|12⅔}} → 12+2/3
-DePiep (talk) 08:51, 29 August 2017 (UTC)

Tests & implementations

Using [[:module:convert/helper|number]] to normalise fraction input for {{Convert}}.
Using the "class=error" (now added in general in {{Convert/sandbox}}).
Not used: option |input=5 ft 9 in. Since the template has ft and in input separated over 2 parameters, it can control more ("no ft input, inch only"). So it uses classic {{Convert|x|ft|y|in|m}} with/without the ft parameters.
Not done: check time values "5.44 s" for numeric input.
Pro tip: a {{Convert}} result is calculated only once, then a subtemplate tests that value for {{#iserror:value|bad|good}} output. In this template, case bad = return raw input+maintenance category (this will evade any further {{Convert}} error handling: no tagging, no convert-categorisation).
Todo: Keep testing; at Template talk:NFL predraft, find support to add the metric values; completify in-template error handling (add maintenance category); wait for both new features to go live.
Long term: Check {{convinfobox}} in templates that could benefit from the new options (check for elaborate error checking, accept easier frac input). Note that the |input=ft in option is not thoroughly tested any more.
-DePiep (talk) 10:34, 2 August 2017 (UTC)
Sounds good. I set up the module so this should work:
  • {{#invoke:convert/helper|number|12¾}} → 12+3/4
Johnuniq (talk) 11:39, 2 August 2017 (UTC)
Works in testcases. -DePiep (talk) 12:04, 2 August 2017 (UTC)

Could be wrapper Convert/pre

Not all rare features need to be added into Convert but, instead, could use a wp:wrapper template such as {convert/pre}. For example, some infoboxes need range +/- as the parameter 1 input value; example mountain elevation:

  • {convert|5,610-5,650|m|ft} → 5,610–5,650 metres (18,410–18,540 ft)
  • {convert|5,630+/-20|m|ft} → [convert: invalid number]

Many mountain articles could use plus/minus in parameter 1, but ftin also could be in a wrapper {convert/pre} to not impact {convert}. We have trouble in Italian Wikipedia, where "e" means both "and" or unit "e" or exponent-notation. Example:

  • {convert|5 and 6|m|ft} → 5 and 6 metres (16 and 20 ft)
  • {convert|5e6|m|ft} → 5×106 metres (1.6×107 ft)

So there are issues. -Wikid77 (talk) 07:52, 1 August 2017 (UTC)

A wrapper could be useful but I'm not sure how it would work with the NFL template.
The 1e5 issue at itwiki is a bit odd—it:Special:ExpandTemplate shows:
  • {{convert|5e6|m|ft}} → 5×106 metri (1,6×107 ft)
  • {{convert|5 e 6|m|ft}} → 5 e 6 metri (16 e 20 ft)
However, "5 and 6" (with spaces) or "5|and|6" (with pipes) are required at enwiki, and "5and6" would be an error. Similarly, "5,630 +/- 20' (with spaces or pipes) are needed to avoid an error. Johnuniq (talk) 10:55, 1 August 2017 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_August_2017&oldid=802586374"