This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
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
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)
{{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)
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)
{{convert|input=P2808|MHz|abbr=on}}
→ 9 cm (3,300 MHz), 18 cm (1,700 MHz), 21 cm (1,400 MHz){{convert|input=P2386|ft|abbr=on}}
→ 10 m (33 ft), 1 m (3.3 ft){{convert|input=P2386|qual=Q613628|ft|abbr=on}}
→ 10 m (33 ft){{convert|input=P2386|qual=Q1395645|ft|abbr=on}}
→ 1 m (3.3 ft){{convert|input=P2386|ft|abbr=on}}
→ (Empty, as this property hasn't been set){{convert|input=P2386|qual=Q613628|ft|abbr=on}}
→ (Empty, as there is no such qualifier for this property here){{convert|input=P2386|qual=Q1395645|ft|abbr=on}}
→ (Empty, as there is no such qualifier for this property here)@
Mike Peel: The first item on the wishlist above shows that {{convert|input=P2808|MHz|abbr=on}}
at
Nançay Radio Telescope should produce:
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:
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)
@ 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)
test=#
parameter outputs is not wanted?
Johnuniq (
talk) 01:46, 20 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"?
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)
@ Mike Peel: I have done some work on implementing this feature and it looks achievable with a limitation:
Is this limitation ok?
GEO600 has fixed wikitext in the infobox: wavelength = 43–10,000 km (30–7000 Hz)
Johnuniq ( talk) 10:28, 26 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)
I updated the sandbox modules to implement the following changes, as discussed above:
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.
{{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)
{{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)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.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:
Mach
from mph km/h
to km/h mph
(SI unit first; discussed
here).msw
and fsw
(discussed
here) from
Module:Convert/extra because they are not used; they can be restored if needed in articles.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.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.varname = 'pl'
in the translation_table
for Polish variable names so a unit can have different names depending on the value.#
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)|input=Pnnn
for values from Wikidata has been enhanced; Pnnn
is a Wikidata property identifier. Discussed
here
qual
has been added to define a Wikidata qualifier (a Qnnn item identifier) to specify which
applies to part (P518) item should be used by convert.qualifier
is an alias for qual
. That is, |qualifier=x
has the same effect as |qual=x
.|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.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.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.{{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)
frequency
and wavelength
have been merged into the above.
Johnuniq (
talk) 06:33, 6 May 2017 (UTC)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)
{{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)
{{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)
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)Please add g/PSh
= 1.3596216173039043234267903242528 g/kWh
. --
Jojhnjoy (
talk) 15:41, 8 May 2017 (UTC)
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)
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)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.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)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)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)Does someone want to add the kilopondmetre to the torque units module now? Best regards, -- Jojhnjoy ( talk) 17:24, 10 May 2017 (UTC)
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.
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.
I haven't tested other units of area. Thryduulf ( talk) 01:26, 11 May 2017 (UTC)
/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./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./mi2
as an alias for /sqmi
but that is not helping. I will have to investigate later./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)/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)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./sqmi
.
Johnuniq (
talk) 08:03, 11 May 2017 (UTC)
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)
m
has name
-{zh:米;zh-cn:米;zh-tw:公尺;zh-hk:米;}-
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)
|abbr=
. -
DePiep (
talk) 09:43, 13 May 2017 (UTC)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)
|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)
{{convert|1|to|5|m|ft|disp=/}}
→ 1 to 5 metres or 3.3 to 16.4 feet
*{{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)This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
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
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)
{{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)
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)
{{convert|input=P2808|MHz|abbr=on}}
→ 9 cm (3,300 MHz), 18 cm (1,700 MHz), 21 cm (1,400 MHz){{convert|input=P2386|ft|abbr=on}}
→ 10 m (33 ft), 1 m (3.3 ft){{convert|input=P2386|qual=Q613628|ft|abbr=on}}
→ 10 m (33 ft){{convert|input=P2386|qual=Q1395645|ft|abbr=on}}
→ 1 m (3.3 ft){{convert|input=P2386|ft|abbr=on}}
→ (Empty, as this property hasn't been set){{convert|input=P2386|qual=Q613628|ft|abbr=on}}
→ (Empty, as there is no such qualifier for this property here){{convert|input=P2386|qual=Q1395645|ft|abbr=on}}
→ (Empty, as there is no such qualifier for this property here)@
Mike Peel: The first item on the wishlist above shows that {{convert|input=P2808|MHz|abbr=on}}
at
Nançay Radio Telescope should produce:
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:
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)
@ 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)
test=#
parameter outputs is not wanted?
Johnuniq (
talk) 01:46, 20 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"?
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)
@ Mike Peel: I have done some work on implementing this feature and it looks achievable with a limitation:
Is this limitation ok?
GEO600 has fixed wikitext in the infobox: wavelength = 43–10,000 km (30–7000 Hz)
Johnuniq ( talk) 10:28, 26 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)
I updated the sandbox modules to implement the following changes, as discussed above:
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.
{{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)
{{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)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.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:
Mach
from mph km/h
to km/h mph
(SI unit first; discussed
here).msw
and fsw
(discussed
here) from
Module:Convert/extra because they are not used; they can be restored if needed in articles.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.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.varname = 'pl'
in the translation_table
for Polish variable names so a unit can have different names depending on the value.#
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)|input=Pnnn
for values from Wikidata has been enhanced; Pnnn
is a Wikidata property identifier. Discussed
here
qual
has been added to define a Wikidata qualifier (a Qnnn item identifier) to specify which
applies to part (P518) item should be used by convert.qualifier
is an alias for qual
. That is, |qualifier=x
has the same effect as |qual=x
.|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.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.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.{{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)
frequency
and wavelength
have been merged into the above.
Johnuniq (
talk) 06:33, 6 May 2017 (UTC)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)
{{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)
{{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)
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)Please add g/PSh
= 1.3596216173039043234267903242528 g/kWh
. --
Jojhnjoy (
talk) 15:41, 8 May 2017 (UTC)
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)
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)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.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)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)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)Does someone want to add the kilopondmetre to the torque units module now? Best regards, -- Jojhnjoy ( talk) 17:24, 10 May 2017 (UTC)
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.
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.
I haven't tested other units of area. Thryduulf ( talk) 01:26, 11 May 2017 (UTC)
/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./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./mi2
as an alias for /sqmi
but that is not helping. I will have to investigate later./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)/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)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./sqmi
.
Johnuniq (
talk) 08:03, 11 May 2017 (UTC)
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)
m
has name
-{zh:米;zh-cn:米;zh-tw:公尺;zh-hk:米;}-
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)
|abbr=
. -
DePiep (
talk) 09:43, 13 May 2017 (UTC)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)
|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)
{{convert|1|to|5|m|ft|disp=/}}
→ 1 to 5 metres or 3.3 to 16.4 feet
*{{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)