Jump to content

Template talk:Convert/Archive May 2017

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


Wikidata qualifiers

From a discussion at my talk (permalink), an enhancement for how convert handles |input=X (which accesses Wikidata when X is a property) has been requested. I'm posting this to alert others, and for a record to refer to in the future.

Taking South Pole Telescope as an example, if the following converts were on that page, it is hoped the output would be as shown (the output here is fixed wikitext).

  • {{convert|input=P2386|ft|abbr=on}} → 10 m (33 ft)
  • {{convert|input=P2386|qual=Q1395645|ft|abbr=on}} → 1 m (3.3 ft)

That telescope has a primary mirror (diameter 10 m) and a secondary mirror (diameter 1 m). P2386 is the diameter property, and qualifier Q1395645 identifies the secondary mirror.

Problem: There is no reason for the first convert to assume the primary diameter is wanted, so if qualifiers are present, I think every convert would need to specify which diameter to use. That means the first convert would have to be (Q613628 = primary mirror):

  • {{convert|input=P2386|qual=Q613628|ft|abbr=on}} → 10 m (33 ft)

Convert could be coded to use the first diameter property (with highest rank) if no qualifier is specified. That is what convert does now, and it is only a happy coincidence that it works with qualifiers as far as I can see. It works because for the example article, Wikidata presents the diameter for the primary mirror before that of the secondary mirror. Given how Wikidata bounces around, using the first diameter when qualifiers are present is not satisfactory—it will lead to hard-to-spot bugs in articles. It might be better for convert to give an error if qualifiers are present but no qual parameter has been used.

Searching this dump of Q1513315 (permalink) for "P2386" (diameter) shows how Wikidata presents the data to a module. Q1513315 = South Pole Telescope. The following is my translation of the dump:

P2386 diameter for Q1513315 South Pole Telescope

  • Statement:
    • value: +10.0 Q11573 metre
    • qualifiers: applies to Q613628 primary mirror
    • rank: normal
  • Statement:
    • value: +1 Q11573 metre
    • qualifiers: applies to Q1395645 secondary mirror
    • rank: normal

If the two statements are in the order shown, using the first would choose the primary mirror. However, if something shuffled them, the qualifier would need to be specified. I'm going to look at how to implement this soon. Johnuniq (talk) 04:09, 10 April 2017 (UTC)

@Mike Peel: What do you think? Are you happy to use qual=Q613628 for the primary mirror when qualifiers are present? Johnuniq (talk) 04:11, 10 April 2017 (UTC)

Thanks for working on this @Johnuniq! Ideally, when there are multiple values present, then all of those values would be used and converted. Take for example, Nançay radio telescope, where at Nançay Radio Telescope (Q1671656) we have three values for the wavelength that the telescope works at - it would be nice if those could all be passed through Convert to show both the wavelengths and the frequencies for all three. Then if we want to pick out individual values, we can switch to using qualifiers to distinguish between them. So for diameters, I'd like to be able to use {{convert|input=P2386|ft|abbr=on}} by default, using an if statement to check to see if one has the "primary mirror" qualifier and showing that instead if it does, and then separately showing the secondary mirror diameter if there is a value with the appropriate qualifier. Sorry if that's a bit complex! Thanks. Mike Peel (talk) 09:11, 10 April 2017 (UTC)
The problem with that is that convert would need to hold magic information to the effect that the default qualifier for P2386 diameter is Q613628 primary mirror. That is, if no qualifier is specified in the convert but the property P2386 has qualifiers, convert should use Q613628. In that case, what should convert do if Q613628 is not present but some other qualifier is? In principle, there could be lots of properties used with input=Pxxx, and each would need a default qualifier built-in to convert. Currently, P2386 diameter is (I think) only used with telescopes where Q613628 primary mirror applies. However, P2386 could be used for the diameter of a planet or a football, and they would need a different default qualifier.

Re Nançay radio telescope: How would the convert be written, and what output should it give? Johnuniq (talk) 09:56, 10 April 2017 (UTC)

The qualifier info should be held in the infobox template, not convert - so I was thinking about doing some sort of if statement check on whether qualifiers are present, and then select the appropriate convert call to run. So some sort of behaviour for convert like this would be good:
  1. Nançay Radio Telescope (Q1671656): {{convert|input=P2808|MHz|abbr=on}} → 9 cm (3,300 MHz), 18 cm (1,700 MHz), 21 cm (1,400 MHz)
  2. South Pole Telescope (Q1513315): {{convert|input=P2386|ft|abbr=on}} → 10 m (33 ft), 1 m (3.3 ft)
  3. South Pole Telescope (Q1513315): {{convert|input=P2386|qual=Q613628|ft|abbr=on}} → 10 m (33 ft)
  4. South Pole Telescope (Q1513315): {{convert|input=P2386|qual=Q1395645|ft|abbr=on}} → 1 m (3.3 ft)
  5. Nançay Radio Telescope (Q1671656): {{convert|input=P2386|ft|abbr=on}} → (Empty, as this property hasn't been set)
  6. Nançay Radio Telescope (Q1671656): {{convert|input=P2386|qual=Q613628|ft|abbr=on}} → (Empty, as there is no such qualifier for this property here)
  7. Nançay Radio Telescope (Q1671656): {{convert|input=P2386|qual=Q1395645|ft|abbr=on}} → (Empty, as there is no such qualifier for this property here)
Then I could run something like "if(3) then(3) else(2)" for the primary diameter, and "(4)" for the secondary diameter within {{Infobox Telescope}}. Thanks. Mike Peel (talk) 21:34, 10 April 2017 (UTC)
OK, I'm chewing that over. Some of it looks difficult, but you never know. I'll ping when I have something to say. Johnuniq (talk) 03:50, 11 April 2017 (UTC)

@Mike Peel: The first item on the wishlist above shows that {{convert|input=P2808|MHz|abbr=on}} at Nançay Radio Telescope should produce:

9 cm (3,300 MHz), 18 cm (1,700 MHz), 21 cm (1,400 MHz)

That is essentially three converts joined with commas and would require significant changes. I could think about it later, but now I would prefer to get the Wikidata side of it reasonably robust and tested. Therefore I'm wondering if either of the two following alternatives would be ok:

9, 18, 21 cm (3,300, 1,700, 1,400 MHz)
9 cm, 18 cm, 21 cm (3,300 MHz, 1,700 MHz, 1,400 MHz)

Here is the wikitext for the above to show the non-breaking spaces in case some alternative is wanted.

9, 18, 21 cm (3,300, 1,700, 1,400 MHz)
9 cm, 18 cm, 21 cm (3,300 MHz, 1,700 MHz, 1,400 MHz)

Johnuniq (talk) 02:39, 13 April 2017 (UTC)

@Johnuniq: Either of those would be great - the only reason I didn't include them in my suggestion was because I thought they would be more difficult to do than the first suggestion! I particularly like the first one's condensed form (not repeating units), although I guess the second one would be better at coping with cases like "1m, 10cm". Thanks. Mike Peel (talk) 10:09, 13 April 2017 (UTC)
OK that's good, either is easy. However, unfortunately convert cannot handle a mixture of units. I was planning to output nothing for a case like "1 m, 10 cm". Have to leave something to do next year! Johnuniq (talk) 11:43, 13 April 2017 (UTC)

Wikidata qualifiers: testing

@Mike Peel: I put some large changes in the sandbox. Please give it a workout on a few articles because Wikidata is very strange and my guess as to how the data should be processed may not always be satisfactory.

  • {{convert/sandbox|input=P2386|ft|abbr=on|qid=Q1513315}} → 10.0, 1 m (32.8, 3.3 ft)
  • {{convert/sandbox|input=P2386|ft|abbr=on|qid=Q1513315|test=#}} → 10.0, 1 m (32.8, 3.3 ft)
  • {{convert/sandbox|input=P2386|ft|abbr=on|qual=Q613628|qid=Q1513315}} → 10.0 m (32.8 ft)
  • {{convert/sandbox|input=P2386|ft|abbr=on|qual=Q1395645|qid=Q1513315}} → 1 m (3.3 ft)
  • {{convert/sandbox|input=P2808|MHz|abbr=on|qid=Q1671656}} → 9, 18, 21 cm (3,300, 1,700, 1,400 MHz)
  • {{convert/sandbox|input=P2808|MHz|abbr=on|qid=Q1671656|test=#}} → 9, 18, 21 cm (3,300, 1,700, 1,400 MHz)
  • {{convert/sandbox|input=P2386|ft|abbr=on|qid=Q1671656}} →
  • {{convert/sandbox|input=P2386|ft|abbr=on|qual=Q613628|qid=Q1671656}} →
  • {{convert/sandbox|input=P2386|ft|abbr=on|qual=Q1395645|qid=Q1671656}} →

The test=# parameter is temporary and is so you can decide which style is wanted. It is only effective when abbr=on. Johnuniq (talk) 11:11, 14 April 2017 (UTC)

Thanks @Johnuniq, it looks good to me! Mike Peel (talk) 17:51, 14 April 2017 (UTC)
Is there an ETA for the deployment of this? I'm keen to put it into action in {{Infobox Telescope}}! :-) Thanks. Mike Peel (talk) 00:06, 20 April 2017 (UTC)
I'm looking at cleaning up loose ends for what else needs to be included in the next update to convert, and will post a new section about the update by next Monday, I hope. I would feel happier if I knew {{convert/sandbox}} had been tested in a few articles because Wikidata is weird and testing is needed. I would recommend putting sandbox convert in a sandbox infobox, and putting the latter in a variety of articles. Later, use "what links here" to find and replace the sandbox infobox. Have you decided that what the test=# parameter outputs is not wanted? Johnuniq (talk) 01:46, 20 April 2017 (UTC)
I've been WP:BOLD and am now using the sandbox in {{Infobox Telescope}} (with ~230 transclusions this is quite a nice test set to use). I haven't spotted any problems so far. Personally, I prefer the option without setting test=#, but that might just be me. Thanks. Mike Peel (talk) 01:40, 22 April 2017 (UTC)
Good, thanks. I decided to keep test=# for now as it is harmless (it will be in the next release, I hope next week), but I will remove it in the release after that, assuming it is unused. Johnuniq (talk) 02:16, 22 April 2017 (UTC)
If that format can be used for different input units, that would be fantastic. If not, then I'm not sure it's needed. Thanks. Mike Peel (talk) 02:27, 22 April 2017 (UTC)
I'm afraid that handling different input units is way beyond what is possible at the moment. I had a look at it, but it's too hard. Convert will display nothing if values have different units, but it will do the right thing if qual is used to identify a wanted item because convert takes the first value (with highest rank) in that case, so there would only be one unit. Johnuniq (talk) 02:47, 22 April 2017 (UTC)
Fair enough. :-) On a slightly different topic, is there a way to configure this so that if the input unit is metres, the unit is converted to MHz; centimetres and it's GHz; kilometers and it's Hz; and so forth? At the moment I'm converting everything to MHz, but that doesn't work so well over at GEO600! Thanks. Mike Peel (talk) 23:46, 24 April 2017 (UTC)

In general terms, no. For example, P2386 diameter often gives a value like 10 m and that should not be converted to MHz. Convert would need magic knowledge that P2808 wavelength has a special set of rules for the default output unit. If that's all there is to it, a fix may be achievable soon, and the infobox could use P2808 with no output unit, and convert would pick one output unit from its magic knowledge. In an article where the wavelength is 10 m it would output MHz. In another article where the wavelength is 10 cm it would output GHz. Would that be sufficient for now? If so, I need a list of input/output units. Anything more than the following (I'm looking at "and so forth"?

cm, GHz
m, MHz
km, Hz

I'll look at the issue in the next day or two and will post something when I've worked out what is involved. Johnuniq (talk) 04:07, 25 April 2017 (UTC)

I was wondering about something more like {{convert|10cm|frequency}} and {{convert|10MHz|wavelength}}, so that the special knowledge that the unit should be converted to a wavelength/freq rather than a distance can be encoded in the infobox rather than in the convert template. If the call was asking for "frequency" as the output, then the appropriate conversion to Hz/kHz/MHz/GHz/THz would be good, using the most appropriate one (i.e., rather than saying 1000MHz, then it would say 1GHz). I suspect the range of Hz-THz is sufficient, as beyond that frequency doesn't tend to be used (at very short wavelengths, it switches to eV, which is a bit more complicated). Thanks. Mike Peel (talk) 19:58, 25 April 2017 (UTC)

Wikidata qualifiers: automatic default output

@Mike Peel: I have done some work on implementing this feature and it looks achievable with a limitation:

  • If the output is "frequency", the input unit must be m or an SI multiple of m.
  • Otherwise (say if the input is 12 feet), the output would be in Hz.
  • If the output is "wavelength", the input unit must be Hz or an SI multiple of Hz.
  • Otherwise (should never happen), the output would be in m.

Is this limitation ok?

GEO600 has fixed wikitext in the infobox: wavelength = 43–10,000 km (30–7000 Hz)

  • Is that a range, or is it two values (43 km and 10,000 km)?
  • How do you hope convert would display that? Like the following?
    43, 10,000 km (30, 7,000 Hz)

Johnuniq (talk) 10:28, 26 April 2017 (UTC)

    • Hi @Johnuniq: That limitation looks fine for me, as wavelengths are rarely specified in miles/feet, they are nearly always in metres.
    • With the GEO600 example, ideally that should be a range, so it should appear as "43-10,000 km (30-7,000 Hz)". However, I don't know how to input ranges on Wikidata at the moment! I've been using the lower and upper values separately instead... I'll ask on Wikidata about ranges. Thanks. Mike Peel (talk) 15:07, 26 April 2017 (UTC)
    • Now asked at d:Wikidata:Project_chat#Ranges.3F. Thanks. Mike Peel (talk) 15:10, 26 April 2017 (UTC)
      • The answer you got is undoubtedly correct per the way Wikidata works, but the result is nonsense from a programmer's point of view. See mw:Wikibase/DataModel#Quantities for the documentation which includes Wikidata's typical weasel words "The exact interpretation of the uncertainty interval provided with lowerBound and upperBound is unspecified." In other words, a program cannot rely on anything—magic is needed to interpret the data. If the infobox knew when the telescope had a range of wavelengths/frequencies, instead of "frequency" it could use, say, "frequencyrange". That would tell convert that if upperBound and lowerBound are present, they represent a range. Is that feasible from the infobox's point of view? I'm not sure whether it would be feasible to add that for this release, but if you tell me that frequencyrange would work, I will look at implementing it. Would wavelengthrange be needed as well (that is, the input is a range of frequencies)? Johnuniq (talk) 00:37, 27 April 2017 (UTC)

The way frequencyrange could be implemented without a major restructure of convert would involve translating {{convert|input=P2808|frequencyrange|abbr=on}} to the following:

  • {{convert|43|-|10000|km|Hz|abbr=on}} → 43–10,000 km (6,972–30 Hz)

The result is not pretty! We might live with the fact that the frequencies are in descending order, but convert cannot round 6,972 to 7000 without also rounding 30 to 0. We might have to leave implementing this to a much later time. Johnuniq (talk) 02:30, 27 April 2017 (UTC)

Wikidata qualifiers: frequency et al. done

I updated the sandbox modules to implement the following changes, as discussed above:

  • When using input=x the output unit can be a special word to invoke extra processing:
    • frequency converts the input (which should have unit m or an SI multiple of m) from a wavelength to a frequency. The output unit is chosen as the "best" from Hz, kHz, MHz, GHz, THz using the first or only value.
    • wavelength converts the input (which should have unit Hz or an SI multiple of Hz) from a frequency to a wavelength. The output unit is chosen as the "best" from µm, mm, cm, m, km, Mm using the first or only value.
    • frequencyrange displays the same values as frequency, but multiple values are shown as a range.
    • wavelengthrange displays the same values as wavelength, but multiple values are shown as a range.

Examples:

  • {{convert/sandbox|input=100 Mm|frequency|abbr=on}} → 100 Mm (3.0 Hz)
  • {{convert/sandbox|input=100 km|frequency|abbr=on}} → 100 km (3.0 kHz)
  • {{convert/sandbox|input=100 m|frequency|abbr=on}} → 100 m (3.0 MHz)
  • {{convert/sandbox|input= 1 cm|frequency|abbr=on}} → 1 cm (30 GHz)
  • {{convert/sandbox|input=100 mm|frequency|abbr=on}} → 100 mm (3.0 GHz)
  • {{convert/sandbox|input=100 um|frequency|abbr=on}} → 100 μm (3.0 THz)
  • {{convert/sandbox|input=300 THz|wavelength|abbr=on}} → 300 THz (1.00 μm)
  • {{convert/sandbox|input=300 GHz|wavelength|abbr=on}} → 300 GHz (1.00 mm)
  • {{convert/sandbox|input= 30 GHz|wavelength|abbr=on}} → 30 GHz (1.00 cm)
  • {{convert/sandbox|input=300 MHz|wavelength|abbr=on}} → 300 MHz (1.00 m)
  • {{convert/sandbox|input=300 kHz|wavelength|abbr=on}} → 300 kHz (1.00 km)
  • {{convert/sandbox|input=300 Hz|wavelength|abbr=on}} → 300 Hz (1.00 Mm)

Unfortunately the results are often poor (non-optimal choice of unit or precision), particularly with a range. That is illustrated in the following. The article concerned does not currently define wavelength in Wikidata so the following is a simulation of what would be displayed if it did.

  • GEO600 has wavelength = 43–10,000 km (30–7000 Hz).
  • GEO600 (Q697906)
  • wavelength (P2808)
  • {{convert/sandbox|input=P2808|qid=Q697906|abbr=on}} → 43, 10,000 km (27, 6,214 mi)
  • {{convert/sandbox|input=P2808|Hz|qid=Q697906|abbr=on}} → 43, 10,000 km (6,972, 30 Hz)
  • {{convert/sandbox|input=P2808|frequency|qid=Q697906|abbr=on}} → 43, 10,000 km (6.972, 0.030 kHz)
  • {{convert/sandbox|input=P2808|frequencyrange|qid=Q697906|abbr=on}} → 43–10,000 km (6.972–0.030 kHz)

I will rest on that for a while. I suspect there is no feasible way to clean it up to do what a human would want but if an algorithm can be suggested I could look at implementing it. Testing is needed! Johnuniq (talk) 11:32, 27 April 2017 (UTC)

@Mike Peel: Above I made three comments dated 27 April 2017. Would you please let me know if you think the module is ready for release. I don't know if frequencyrange and wavelengthrange would be useful, but I'm inclined to leave them in the module at least on an experimental basis despite the shortcomings I mentioned. I should spell out that those "range" identifiers expect two or more separate values—convert ignores the lower and upper bound values because it is unbearably klunky to assume ± error limits actually refer to a range. Johnuniq (talk) 02:59, 29 April 2017 (UTC)

Hi @Johnuniq: sorry for not replying quicker, I didn't notice your message until you pinged me. The frequency/wavelength conversion looks good! With ranges, it seems that the best way to record values as a range on Wikidata at the moment is how I've set the 'wavelength' property up at GEO600 (Q697906) - i.e. with qualifiers of instance of (P31) = minimum (Q21067468) or maximum (Q21067467). Rather than having a separate 'frequencyrange', do you think you can detect this setup and show a range automatically when using 'frequency' or 'wavelength'? If not, I'll see if I can figure out an if statement to determine whether to use 'frequency' or 'frequencyrange'. Thanks. Mike Peel (talk) 21:08, 29 April 2017 (UTC)
BTW, {{convert/sandbox|input=P2808|frequency|abbr=on|}} didn't work in {{Infobox telescope}} in Nançay radio telescope, so I guess the Wikidata version of this hasn't been implemented yet. :-) Thanks. Mike Peel (talk) 23:34, 29 April 2017 (UTC)
I've just discovered that maximum wavelength of sensitivity (P3737) and minimum wavelength of sensitivity (P3738) exist! I've modified {{Infobox telescope}} to use those parameters for wavelength when they are present, so it outputs "1 m (300 MHz)-3 cm (10,000 MHz)" for Arecibo Observatory, which I think is good enough. So if you can implement 'frequency' and 'wavelength' as options for Wikidata values, then I think we're good to go. :-) Thanks. Mike Peel (talk) 23:49, 29 April 2017 (UTC)
@Mike Peel: It is the empty parameter in your "didn't work" example above that causes it to behave like that. These examples use fixed wikitext so it won't change:
  • {{convert|input=P2808|frequency|qid=Q1671656|abbr=on}} → 9, 18, 21 cm (3.3, 1.7, 1.4 GHz) (This is the expected result.)
  • {{convert|input=P2808|frequency|yd|qid=Q1671656|abbr=on}} → 9, 18, 21 cm (0.098, 0.197, 0.230 yd)
  • {{convert|input=P2808|frequency||qid=Q1671656|abbr=on}} → 9, 18, 21 cm (3.5, 7.1, 8.3 in)
The second example shows that yd converts the values to yards. That is because input=x inserts parameters before the rest of the convert. The yd overwrites what frequency does. The empty parameter in the third example means to use the default output (inches). That is sometimes needed, for example with adj=mid. I can easily change the module so any specified output units are ignored after frequency or wavelength. I thought it was kind of cute that specifying a unit in a particular convert would change what happens, but on reflection ignoring any additional units would be better.
I believe you are saying to fix the frequency issue, and remove frequencyrange and wavelengthrange. Is that correct?
Some RL issues mean I won't get around to looking at this for another 24 hours or so. Johnuniq (talk) 07:51, 1 May 2017 (UTC)
Ah, thanks, it works perfectly without that extra |. :-) At the moment I won't use frequencyrange/wavelengthrange, I'd say it's up to you if you want to keep it as extra functionality or not. Thanks. Mike Peel (talk) 19:31, 1 May 2017 (UTC)

Module version 17

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

The changes are:

  • Units:
    • Change default output unit for Mach from mph km/h to km/h mph (SI unit first; discussed here).
    • Remove units msw and fsw (discussed here) from Module:Convert/extra because they are not used; they can be restored if needed in articles.
    • Remove unit cda (cuerda) because it is ambiguous and an unqualified "cuerda" could refer to different customary units, some of which have changed over time; discussed here.
    • Add unit cda to Module:Convert/extra where its usage can be tracked (what links here) with a view to removing it from articles, and possible eventual removal from convert.
  • For plwiki, handle varname = 'pl' in the translation_table for Polish variable names so a unit can have different names depending on the value.
  • Add # range. This is experimental for possible use with Wikidata values; it will be removed if not needed. Using # gives the same results as , when units are not abbreviated. Using # repeats the units when abbr=on applies, in a manner similar to x.
    • {{convert|1|,|5|m|ft}} → 1, 5 metres (3.3, 16.4 ft)
    • {{convert|1|#|5|m|ft}} → 1, 5 metres (3.3 ft, 16.4 ft)
    • {{convert|1|,|5|m|ft|abbr=on}} → 1, 5 m (3.3, 16.4 ft)
    • {{convert|1|#|5|m|ft|abbr=on}} → 1 m, 5 m (3.3 ft, 16.4 ft)
  • Handling of |input=Pnnn for values from Wikidata has been enhanced; Pnnn is a Wikidata property identifier. Discussed here
    • If no qualifier is given and a specified property has multiple values, each value is shown and converted. However, if there are values with preferred rank, any values with normal rank are ignored.
    • If a qualifier is given, the first value matching the qualifier is used; any value with preferred rank is used first.
    • Parameter qual has been added to define a Wikidata qualifier (a Qnnn item identifier) to specify which applies to part, aspect, or form (P518) item should be used by convert.
    • Parameter qualifier is an alias for qual. That is, |qualifier=x has the same effect as |qual=x.
    • As in earlier versions, when |input=Pnnn is used, any error is ignored and no output occurs. For troubleshooting, |debug=yes can be used to report any unexpected errors that occur while accessing Wikidata, for example due to a bug that causes Lua to terminate the script.
  • When using input=Pnnn the output unit can be a special word to invoke extra processing ("automatic default output"):
    • frequency converts the input (which should have unit m or an SI multiple of m) from a wavelength to a frequency. The output unit is chosen as the "best" from Hz, kHz, MHz, GHz, THz using the first or only value.
    If the input is, say, 12 feet, the output would be in Hz.
    • wavelength converts the input (which should have unit Hz or an SI multiple of Hz) from a frequency to a wavelength. The output unit is chosen as the "best" from µm, mm, cm, m, km, Mm using the first or only value.
    If the input is not in Hz (should never happen), the output would be in m.
    • {{convert|input=100 Mm|frequency|abbr=on}} → 100 Mm (3.0 Hz)
    • {{convert|input=100 km|frequency|abbr=on}} → 100 km (3.0 kHz)
    • {{convert|input=100 m|frequency|abbr=on}} → 100 m (3.0 MHz)
    • {{convert|input= 1 cm|frequency|abbr=on}} → 1 cm (30 GHz)
    • {{convert|input=100 mm|frequency|abbr=on}} → 100 mm (3.0 GHz)
    • {{convert|input=100 um|frequency|abbr=on}} → 100 µm (3.0 THz)
    • {{convert|input=300 THz|wavelength|abbr=on}} → 300 THz (1.00 µm)
    • {{convert|input=300 GHz|wavelength|abbr=on}} → 300 GHz (1.00 mm)
    • {{convert|input= 30 GHz|wavelength|abbr=on}} → 30 GHz (1.00 cm)
    • {{convert|input=300 MHz|wavelength|abbr=on}} → 300 MHz (1.00 m)
    • {{convert|input=300 kHz|wavelength|abbr=on}} → 300 kHz (1.00 km)
    • {{convert|input=300 Hz|wavelength|abbr=on}} → 300 Hz (1.00 Mm)

The examples shown above use fixed wikitext so they will not change in the future. Release notes for earlier versions are listed here. Johnuniq (talk) 08:11, 24 April 2017 (UTC)

The sandbox modules have been updated to incorporate recent changes following the #Wikidata qualifiers discussion above, and notes on frequency and wavelength have been merged into the above. Johnuniq (talk) 06:33, 6 May 2017 (UTC)
Excellent work again, many thanks Johnuniq! — JFG talk 17:25, 6 May 2017 (UTC)

Cubic centimetres

I see the abbreviation "cc" for "cubic centimetres" sometimes, however, some abbreviations, such as cc or ccm must not be used:

It is not permissible to use abbreviations for unit symbols or unit names, such as sec (for either s or second), sq. mm (for either mm2 or square millimetre), cc (for either cm3 or cubic centimetre), or mps (for either m/s or metre per second). The use of the correct symbols for SI units, and for units in general, as listed in earlier chapters of this Brochure, is mandatory. In this way ambiguities and misunderstandings in the values of quantities are avoided. (See The International System of Units (SI), chapter 5.1 [page 130].)

Therefore I suggest that the use of "cc" in the template automatically generates "cm3" like this:
{{convert|2993|cc|cuin|1|abbr=on}} = 2,993 cm3 (182.6 cu in)

Also, I would recommend that "cm3" used in the template together with litres like this: {{convert|2993|cm3|L|1|abbr=on}} would not generate any output in litres at all, since a litre equals 1000 cm3 and displaying "2993 cm3 (2.993 l)", which is basically the same twice, does not make so much sense. --Jojhnjoy (talk) 11:53, 5 May 2017 (UTC)

Oppose both. WP:UNIT does not demand SI compliance. Editors should be allowed to choose the common terminology of the field, e.g. cc for engine displacement. And we are a general encyclopedia for lay people. I'm sure lots of readers don't know how to convert between cm3 and l. Both units are uncommon to many readers. If an editor finds it suitable to make the conversion in a given context then don't ignore it. PrimeHunter (talk) 12:16, 5 May 2017 (UTC)
Also oppose. Some fields use non-SI units because they are easier to manage for practical reasons and using unfamiliar units will be more likely to confuse the reader who is familiar with the customary units of the field. • • • Peter (Southwood) (talk): 15:29, 5 May 2017 (UTC)
As far as I can tell, only Americans use cc for engine displacement. I don't think that lay people would not understand cm3 since it is the most common and default abbreviation for cubic centimetres. Outside Wikipedia I never encountered anyone using cc, literature usually uses cm3, historical books make use of ccm as well. In the US however, cubic inches are much more common so I would consider the use of cubic centimetres uncommon in the US in general. In Europe, cc is completely unknown. And I seriously cannot imagine that anyone would have problems converting between m3 and litres. Since the template does not round by default, you would get 1,000 cm3 (1.000 l) — it does not do anything but making it harder to read.
This is about the abbreviation for the cubic centimetre. Using cm3 would reduce the readers confusion since most readers do not know what "cc" means. --Jojhnjoy (talk) 15:54, 5 May 2017 (UTC)
In the US, I doubt that more than one person in a thousand could give you the conversion between m3 and litres. And while cc may only be used by motorcycle enthusiasts and pharmacists over the age of 50, cm3 is unknown. Kendall-K1 (talk) 16:36, 5 May 2017 (UTC)
If cm3 is unknown in the US, I suppose that something like this: 16.39 cm3 (1 in3) would be the best way to display volume since I would say that a lot of people would not understand that cc means cubic centimetres. --Jojhnjoy (talk) 17:33, 5 May 2017 (UTC)
I can't imagine a context in which that would be helpful. Can you give an example? Kendall-K1 (talk) 19:56, 5 May 2017 (UTC)
For example, the BMW M67 displaces 3901 cm3. For those who do not know what that means, you would put the 3901 cm3 into the template which then displays an equivalent in in3 like this: {{convert|3901|cm3|in3|1|abbr=on}} "Displacement 3901 cm3 (238 in3)". However, if you would use cc rather than cm3, the people that don't use cubic inches would possibly get confused by cc and even worse, they don't know what a cubic inch is either. So they are confronted with two unknown figures, like in this example: BMW E65; Europeans neither understand cc nor cu in. And this is a German vehicle which most likely has an Austrian engine, in Germany and over here in Austria we both use cm3 only. So in that case, if the template was adjusted, cc would be displayed as cm3, making it much easier to understand. Those who don't know SI-units can still see the cubic inches. The second thing is that displaying displacement in litres just makes sense when you round it properly. But the template does not do that by default. (For example here). So you would get presented with "3,901 cm3 (3.901 l)" which is not very helpful; it is obviously the same. Litres are rather for the text part where you could say "the M67 displaces 3.9 litres" instead of "it displaces 3,901 cm3". But in a template its use is very small and therefore I suggest that the litre parameter will result in no result at all if used together with cm3. --Jojhnjoy (talk) 21:28, 5 May 2017 (UTC)

I still don't understand the problem. Why not just use litres, with a conversion to cubic inches for the Americans? Everyone understands litres, right? For your example I would use 3.901 L (238.1 in3). Why does the convert template need to change? Kendall-K1 (talk) 21:37, 5 May 2017 (UTC)

Because sometimes cc is being used and only Americans understand it. However, if the template would always display cm3 if cc is being used, it would be much easier. And as I said, you would usually round litres and that's why you would not use them for displacement. {{convert|3901|cc|L|in3|1|abbr=on}} would look like this: 3,901 cm3 (238.1 in3) --Jojhnjoy (talk) 22:05, 5 May 2017 (UTC)
That is an editorial issue. If a better unit should be used in an article, the article needs to be edited. Templates such as convert provide a tool that aids uniform styling but does not enforce it. After all, if convert did not support cc, editors at articles using it (examples: Bentley + Datsun + Harley-Davidson + Moped) could remove convert and show any wanted units. Johnuniq (talk) 23:30, 5 May 2017 (UTC)
It is both a template and an editorial issue. A template offering a "cc" conversion helps people that don't use exponents. But it confuses everyone else. Leaving the "cc" in the template resulting in cm3 would not require anything to be changed in articles and would prevent future confusion, since I could imagine that people would still continue to use cc. And as I mentioned initially, it is not permissible to use abbreaviations like "cc" for cm3; applying this rule would not hurt: People familiar with "cc" will understand in3, people not familiar with in3 will understand cm3, but not cc though. Providing two unknown unit symbols is the problem here, if the template would automatically correct this, the problem would be solved. And everything people use "cc" for, could be expressed in cubic centimetres as well, because 1 cc euqals 1 cubic centimetre. Adding yet another same conversion parameter to convert cc and cm3 does not make sense either. --Jojhnjoy (talk) 05:46, 6 May 2017 (UTC)
To shed some more light on the matter, countries where English is the clear majority language (I'm thinking Britain, US, Canada, New Zealand and Australia but it might also be true in other countries like South Africa and India), cc is universally understood to be cubic centimetres. It is in countries where another language is dominant and English is a well understood but secondary language (eg Germany) that cm3 is the more common form and cc is unknown. As an Australian who reads a lot of Australian, British and US car magazines and websites, 'cc' is the natural fit for car articles. Litres (or liters) is also common but usually rounds off at 1 decimal digit (eg 4.1 litres) for engines. 'cc' usually gets 2 more orders of magnitude of accuracy (eg 4104 cc). It is unusual to see high accuracy such as 4.104 litres in any car magazine but quite common to see 4104 cc.  Stepho  talk  00:06, 7 May 2017 (UTC)
Also true for South Africa. I don't know about India, but would not be surprised if the trend continues. Also, it is common for engine capacities in cc to be rounded to trailing zeros or, less commonly, fives, particularly in motorcycles. • • • Peter (Southwood) (talk): 12:53, 7 May 2017 (UTC)
But don't forget the 742 million Europeans. They understand neither cc nor in3. So replacing cc with cm3 would give them something they understand. This would affect cubic inches and leave something familiar for Americans. Also, it's confusing that articles about German topics don't show cm3 at all often. --Jojhnjoy (talk) 07:06, 7 May 2017 (UTC)
Yet both cc and in3 are in colloquial use in English language countries, and are used extensively in some contexts, like internal combustion engine capacity (swept volume). This is English Wikipedia, so it is not unreasonable to use and allow terminology used and understood by English speaking people. I have no objection to providing a conversion to a more universally accepted SI unit, but not at the expense of eliminating the commonly used unit. • • • Peter (Southwood) (talk): 12:53, 7 May 2017 (UTC)

g/PSh

Please add g/PSh = 1.3596216173039043234267903242528 g/kWh. --Jojhnjoy (talk) 15:41, 8 May 2017 (UTC)

Jojhnjoy, added to the extra units module. Frietjes (talk) 18:07, 8 May 2017 (UTC)

Kilopondmetre

The template lacks the kilopondmetre; 1 kp = 9.80665 N. Also, I suggest an automatic force/mass correction since mkg and kgm are used for kilopondmetres sometimes even though kilogramme is not a unit of force which is mandatory in this case. So the template should look like this:

{{convert|1|kpm|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|mkp|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|kgm|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|mkg|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)

It should display kp·m always, no matter which input abbreviation is being used. --Jojhnjoy (talk) 07:50, 6 May 2017 (UTC)

Kilogram-metre (kgm) already works:
  • {{convert|1|kgm|Nm|abbr=on}} → 1 kg⋅m (9.8 N⋅m)
  • {{convert|1|kgm|Nm|5|abbr=on}} → 1 kg⋅m (9.80665 N⋅m)
Is the suggestion that mkg should be equivalent to kgm? Unless there is a really good reason for that, I think it would be better to avoid confusion and just have one unit code. A discussion here notes "force-length units would be torque and length-force units would be energy" and convert generally follows that rule.
Once agreement is reached, it is easy to add a couple of units, but please provide a couple of examples of text in articles which would use them because we try to avoid adding clutter that is not used, or which would only be used in a small number of places where convert is not really needed. Johnuniq (talk) 02:48, 7 May 2017 (UTC)
The Kiloponndmetre is (or rather was, it is obsolete since 1978), a unit of both torque and energy. Both kgm and mkg are wrong, they imply that mass is force. They were widely used though, but the same is true for qm, ccm, U/min, km/st (and even kp rather than kg). So I suggest that the template automatically corrects both kgm and mkg to kp·m or m·kp; it does not matter which one is used, (this ia multiplication, so the order of multiplier and multiplicand does not matter, the product will always be the same. The rule to put the force first was made to avoid confusion with the Newtonmetre, mN would mean Millinewton rather than Newtonmetre.) In East-Germany, kp·m was used, in West-Germany, rather mkp. The kilopondmetre was the main unit of torque for example in countries such as the USSR, the DDR and W. Germany. The torque figure for every German, Russian or Austrian vehicle that was first made in 1978 or earlier is given in kilopondmetres. (For example here.) --Jojhnjoy (talk) 07:07, 7 May 2017 (UTC)
The distinction between mass and force is understood by convert, but various real-world usages mean convert has some special processing that allows a mass to be converted as if it were a force under limited circumstances. Some background is here. Please remember the examples requested. Johnuniq (talk) 07:47, 7 May 2017 (UTC)
As I said, basically every article about German and Russian vehicles older than 40 years would need this conversion since the kilopondmetre was the unit for torque by law until 1978. Therefore you will find it in every manual or technical data sheet, (see the link I provided above for example). Both mkg and kgm are just unit symbols for the kilopondmetre, and as I said, they imply that mass is force. We can adjust this problem with ease by simply making the template display kp·m, no matter which input unit symbol is used. We are not supposed to display force as mass even though we clearly know this is wrong. If you would say that mass can be converted as if it were a force, I would disagree, length and time are not the same either; on the other hand, we could convert the force applied to one kilogramme – this is what 1 kp is, resulting in the kilopondmetre. --Jojhnjoy (talk) 08:23, 7 May 2017 (UTC)
When we say "examples" we mean links to articles in which this conversion is used, the output is unclear, and a change to the template would make the output more clear. Kendall-K1 (talk) 11:19, 7 May 2017 (UTC)
Here you go: 1 2 3 4 --Jojhnjoy (talk) 12:37, 7 May 2017 (UTC)
Well, I tried. Kendall-K1 (talk) 12:44, 7 May 2017 (UTC)
The first replay was: Is the suggestion that mkg should be equivalent to kgm? Unless there is a really good reason for that, I think it would be better to avoid confusion and just have one unit code. Torque is a multiplication of force and length. So I do not have to suggest that mkg should be equivalent to kgm, they are equivalent. 2 × 3 is the same as 3 × 2. And I also think it would be better to avoid confusion and just have one unit symbol: kp·m. Why? It does not confuse mass with force. Newtonmetres also have the same order of force and length: N·m. Same for lb·ft. The template could also change mkg to mkp and kgm to kpm, so we had two unit symbols. It does well at changing ft2 to sq ft already for example. So we would end up with this:
{{convert|1|kpm|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|mkp|Nm|1|abbr=on}} 1 m·kp (9.80665 N·m)
{{convert|1|kgm|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|mkg|Nm|1|abbr=on}} 1 m·kp (9.80665 N·m)
or like this:
{{convert|1|kpm|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|mkp|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|kgm|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m)
{{convert|1|mkg|Nm|1|abbr=on}} 1 kp·m (9.80665 N·m) --Jojhnjoy (talk) 12:59, 7 May 2017 (UTC)
Thanks but the underlying elementary physics is not relevant. It would be better to focus on the replies which are from people very familiar with convert procedures. My point about mkg and kgm is that it is much better to reduce confusion by telling editors that the way to enter torque units is force-length. Apparently there is no reason to change that. Another issue is that kgm already exists; it is consistent with how convert works, namely that using kgm as input should give a corresponding symbol (kg·m). If another symbol is wanted, such as kp·m, a different unit code should be used. An example of existing usage is {{convert|20.2|kgm|0|abbr=on}} at Subaru Forester#Engines. This discussion has got way too long. Please think about what text in an existing article actually needs a new unit, and make a suggestion about that. Let's leave other units and issues for another time. Johnuniq (talk) 02:13, 8 May 2017 (UTC)
Typenschild Matador Gigant
″Thanks but the underlying elementary physics is not relevant.″ Okay. I will change the mass figure in the Claas Matador Gigant to force now as it is given on the name plate in kp. The template will then output this: 5,360 kp ([convert: unit mismatch]). And I will display time in metres now. :-) ″(...)it is much better to reduce confusion by telling editors that the way to enter torque units is force-length.″ I agree. And on the other hand I don't. While it would be great if editors would do that, many sources list mass-lenght instead of force-length. If we would force the editors to use force-length, the template would display something like this: 100 kg ([convert: unit mismatch]). ″using kgm as input should give a corresponding symbol (kg·m).″ It should give a corresponding unit symbol for the unit it displays. This unit is the kilopondmetre, the symbol is kp·m, also, mass is not force. And the mass applied to one kilogramme is called kilopond. I gave a dozen examples by linking a Wikipedia search with the parameters torque "kgm"... I do not want to introduce a new unit, I want to make the template display the difference between mass and force correctly by using the correct unit symbol for the kilopondmetre. And by the way, why would you use the kilopondmetre with new vehicles such as the Subaru Forester? It is obsolete since 1978 and I don't think that people seem to know what it is or means... --Jojhnjoy (talk) 10:16, 8 May 2017 (UTC)
Please see WP:POINT. Tarl N. (discuss) 14:50, 8 May 2017 (UTC)
Please read my initial comment. Do you have any questions? --Jojhnjoy (talk) 15:08, 8 May 2017 (UTC)
Again, please read WP:POINT. Once you've threatened to screw up articles out of spite, nothing else you've said matters as far as I'm concerned. Some behaviors are simply unacceptable. Tarl N. (discuss) 22:12, 8 May 2017 (UTC)
Please take a look at the Matadors version history. Found any recent mass-to-force-changes? I hope that you see that this was clearly sarcasm. The :-) should indicate this as well as time in metres. And even if I changed it, I could cite a source giving a mass figure.(Even though there is a citable source, this would be vandalism and is therefore unacceptable.) This was meant to illustrate how abstruse it would be to use force instead of mass; our problem here is that the current conversion uses mass instead of force. If you think that it does not matter that mass is not force, I recommend reading the articles Mass, Force and Torque. I think that we should not leave a clear mistake in the template since it is an obvious mistake and the template already denies converting mass to force and vice versa. Simply ignoring this in this case would be irrational. And again: Just add the kilopondmetre to the template with the correct unit symbols. And correct the wrong unit symbols automatically. I already explained that kgm and mkg are both the same and both wrong. I explained where they have have been used and by whom. I explained who used the unit symbols kpm and mkp. There is a simple reason for adding the kilopondmetre: It exists and it was used by everyone in Europe before the newtonmetre became the torque unit by law. To display the information given in historical sources properly, it is required in this template. The current way to convert it is doing it manually. --Jojhnjoy (talk) 23:25, 8 May 2017 (UTC)

Does someone want to add the kilopondmetre to the torque units module now? Best regards, --Jojhnjoy (talk) 17:24, 10 May 2017 (UTC)

error by several orders of magnitude for /mi2 and /km2

There seems to be an error of several (-5?) orders of magnitude when converting from per square mile (/mi2) to per km² (/km2) with or without the target unit specified.

Mi² → km²
  • {{convert|298.0|/mi2}} → 298.0 per square mile (115.1/km2) [given in Port Arthur, Texas as 115.1/km²; actual result 0.0001151/km2]
  • {{convert|298.0|/mi2|4=1}} → 298.0 per square mile (115.1/km2) [given in Port Arthur, Texas as 115.1/km²; actual result 0.0/km2]
  • {{convert|298.0|/mi2|/km2}} → 298.0 per square mile (115.1/km2) [given in Port Arthur, Texas as 115.1/km²; actual result 0.0001151/km2]
  • {{convert|298.0|/mi2|/km2|4=1}} → 298.0 per square mile (115.1/km2) [given in Port Arthur, Texas as 115.1/km²; actual result 0.0/km2]
  • -
  • {{convert|82.7|/mi2}} → 82.7 per square mile (31.9/km2) [given in Pahrump, Nevada as 31.9/km²; actual result 3.19×10−5/km2]
  • {{convert|82.7|/mi2|4=1}} → 82.7 per square mile (31.9/km2) [given in Pahrump, Nevada as 31.9/km²; actual result 0.0/km2]
  • {{convert|82.7|/mi2|/km2}} → 82.7 per square mile (31.9/km2) [given in Pahrump, Nevada as 31.9/km²; actual result 3.19×10−5/km2]
  • {{convert|82.7|/mi2|/km2|4=1}} → 82.7 per square mile (31.9/km2) [given in Pahrump, Nevada as 31.9/km²; actual result 0.0/km2]
  • -
  • {{convert|72,033|/mi2}} → 72,033 per square mile (27,812/km2) [given in Manhattan as 27,812/km² actual result 0.027812/km2]
  • {{convert|72,033|/mi2|/km2}} → 72,033 per square mile (27,812/km2) [given in Manhattan as 27,812/km² actual result 0.027812/km2]

When going the other way, there is an error of about +6 orders of magnitude, but only when mi2 are specified as the output units.

km² → mi²
  • {{convert|115.1|/km2}} → 115.1 per square kilometre (298/sq mi) [should be 298; actual result 298/sq mi]
  • {{convert|115.1|/km2|4=1}} → 115.1 per square kilometre (298.1/sq mi) [should be 298.0; actual result 298.1/sq mi]
  • {{convert|115.1|/km2|/mi2}} → 115.1 per square kilometre (298/sq mi) [should be 298; actual result 298,000,000/sq mi]
  • {{convert|115.1|/km2|/mi2|4=1}} → 115.1 per square kilometre (298.1/sq mi) [should be 298.0; actual result 298,107,631.5/sq mi)]
  • -
  • {{convert|31.9|/km2}} → 31.9 per square kilometre (83/sq mi) [should be 83; actual result 83/sq mi]
  • {{convert|31.9|/km2|4=1}} → 31.9 per square kilometre (82.6/sq mi) [should be 82.7; actual result 82.6/sq mi]
  • {{convert|31.9|/km2|/mi2}} → 31.9 per square kilometre (83/sq mi) [should be 83; actual result 83,000,000/sq mi]
  • {{convert|31.9|/km2|/mi2|4=1}} → 31.9 per square kilometre (82.6/sq mi) [should be 82.7; actual result 82,620,620.7/sq mi]
  • -
  • {{convert|27,812|/km2}} → 27,812 per square kilometre (72,030/sq mi) [should be 72,033; actual result 72,030/sq mi]
  • {{convert|27,812|/km2|/mi2}} → 27,812 per square kilometre (72,030/sq mi) [should be 72,033; actual result 7.203×1010/sq mi]

I haven't tested other units of area. Thryduulf (talk) 01:26, 11 May 2017 (UTC)

Ouch. I'm not in the mood to investigate the details today but will later. The problem appears to be a screw-up in the way automatic per units work.
Unit code /km2 is an alias for /sqkm which has the default output /sqmi, and that is defined correctly. That means conversions between /km2 (or /sqkm) and /sqmi work. Also, conversions using /km2 (or /sqkm) with no output also work, since the default output would be used.
However, /mi2 is not defined so convert valiantly calculates the conversion scale that should be used. Unfortunately something is not consistently accounting for the square of the scale.
I tried defining /mi2 as an alias for /sqmi but that is not helping. I will have to investigate later.
A fix right now would be to replace /mi2 with /sqmi.
  • {{convert|1|mi2|km2|6|abbr=on}} → 1 sq mi (2.589988 km2)
  • {{convert|1,000,000|/km2|0|abbr=on}} → 1,000,000/km2 (2,589,988/sq mi)
  • {{convert|1,000,000|/km2|/sqmi|0|abbr=on}} → 1,000,000/km2 (2,589,988/sq mi)
  • {{convert|2,589,988|/sqmi|0|abbr=on}} → 2,589,988/sq mi (1,000,000/km2)
  • {{convert|2,589,988|/sqmi|/km2|0|abbr=on}} → 2,589,988/sq mi (1,000,000/km2)
The following uses fixed wikkitext to show what convert outputs for /mi2 so it will not change if I fix it later.
  • {{convert|1,000,000|/km2|/mi2|sigfig=6|abbr=on}} → 1,000,000/km2 (2.58999×1012/sq mi)
Johnuniq (talk) 03:18, 11 May 2017 (UTC)
The bug is due to an inconsistency in the way "area" and "per unit area" units are defined. The area units are based on m2 while the per unit area units are based on km2. That was years ago but I think I dumbly decided to "simplify" the scales for the latter units. It never mattered until convert had the ability to handle automatic per units. Convert calculates the scale for /mi2 based on m2 but the defined unit /sqkm has a scale based on km2. I'll have to check that and look for other similar problems, then fix and test.
Meanwhile, please use /sqmi. Johnuniq (talk) 08:03, 11 May 2017 (UTC)
Thank you. Thryduulf (talk) 11:00, 11 May 2017 (UTC)

Language conversion by -{...}-

See mw:this. It describes that the parser is to be chagned, handling -{...}-. It is the construct for 'Language conversion' in bi-language wikis like zhwiki (actually bi-scriptual wikis, i.e. alphabets &tc not languages). The change is to deploy it wikiwide, not just known bilangual wikis.

A problem is when the sequence -{ appears in processingd code, like in {{...|foo=A-{0}-bar}} template parameter input, while not related to bilingual structure. In those cases the sequence should be escaped in article code, e.g. like <nowiki>-{</nowiki>

The general advised solution is to escape the parameter input in the page code. Still, while Module:convert already touches this issue (referring to zhwiki), it may need a check. -DePiep (talk) 09:28, 13 May 2017 (UTC)

Complex stuff, thanks. Fortunately I don't think convert will be affected. Units at zhwiki are defined using the language conversion syntax, for example, m has name
-{zh:米;zh-cn:米;zh-tw:公尺;zh-hk:米;}-
and convert outputs that. A change to the way wikitext is parsed is sure to have a few unexpected consequences. Johnuniq (talk) 09:54, 13 May 2017 (UTC)
Complex, and not sure if I made it more clear ;-). Anyway, the covering advice is to always escape in the input part, ie in the article parameter value (and always within [[...]] brackets too). -DePiep (talk) 10:01, 13 May 2017 (UTC)

Tool to find broken parameters

I noticed an amazing tool created by Bamyers99 that can quickly list all parameters used in a template. Due to the free-form nature of convert's parameters, there is very little structure in the result but it highlights obvious mistakes that need fixing.

For example, it shows 1k (that is one k rather than ell k) is used 26 times in convert, and provides a link listing each article that needs to be fixed. Now there is never a reason to go to sleep! Johnuniq (talk) 00:14, 6 May 2017 (UTC)

That is seriously cool, never knew such a tool existed. I'm going to add that to my list of useful tools. — Huntster (t @ c) 00:47, 6 May 2017 (UTC)
But does it have a button that automatically fixes these articles? I am not impressed. Kendall-K1 (talk) 13:31, 6 May 2017 (UTC)
No, but it does list those pages. I've not seen that feature except for handcoded parameter tracking. Only thing missing is some analysis of high numbers (">50 different values" could be more specific, e.g. split numeric/textual)). btw, it uses the templates TemplateData, and is updated every month. -DePiep (talk) 09:36, 13 May 2017 (UTC)
Just take a look: I count four dozen (mis)spellings of |abbr=. -DePiep (talk) 09:43, 13 May 2017 (UTC)
Johnuniq, seen the multitude of misspelled parameter names, I seriously propose to add one of those parametername checkers. Could be done silent, that is: just categorise and no tag in the article. (I've seen a Template:... page having Module:TemplatePar next to the main module call, i.e. set up independently from the main module). -DePiep (talk) 18:34, 19 May 2017 (UTC)
Convert has code to check the parameters but it is not enabled at enwiki due to the monumental backlog of typos and other mistakes. There is no reasonable way to bot-correct problems because, for example, an article may have converts with abbrev=on, and blindly changing that to abbr=on without checking the effect may not be desirable. There are lots of converts with broken parameters like that. Johnuniq (talk) 23:29, 19 May 2017 (UTC)
I'm not proposing bot-editing at all. Not at all. I propose to categorise misspelled (or 'unknown') parameter names. As you linked, [1], shows hundreds of pages having |abbr= misspelled in dozens of ways. These are errors (because the article editor intended something different from what is show), and they can be fixed from that hidden category. Why not? -DePiep (talk) 00:19, 20 May 2017 (UTC)
If it were helpful, I could tweak convert so it would report invalid parameters without showing a message. The "report" would include a new category (Category:Convert warnings) and could include the tiny asterisk used for deprecated-parameter messages if it were wanted. For example:
  • {{convert|1|to|5|m|ft|disp=/}} → 1 to 5 metres or 3.3 to 16.4 feet*
In preview, that would display a prominent message:
  • {{convert|1|to|5|m|ft|disp=/}} → 1 to 5 metres or 3.3 to 16.4 feetError in convert: Option "disp=/" is deprecated (help)
Or, I could make a list in a sandbox with a few hundred links to articles that have convert parameter problems. Johnuniq (talk) 02:59, 20 May 2017 (UTC)
Yes a dedicated tracking category and the preview-only warning would do. Then, an inline tag could be omitted IMO. Up to you to build it or to use an off the shelf module. I now they are sophisticated and very rich in options. -DePiep (talk) 07:53, 20 May 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_May_2017&oldid=1141671996"