Jump to content

Template talk:Convert/Archive September 2019

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


Specific fuel consumption.

Armstrong_Siddeley_Snarler#Performance has an entry for thrust specific fuel consumption given as 20 lb/lbf/h (2,000 kg/kN/h).

This is incorrect: the units should be lb/(lbf·h) and kg/(kN·h).

I've looked at the help page and tried a few things myself, but so far nothing I've tried has worked. I'd appreciate information on how I can fix the page to use correct units.

Michael F 1967 (talk) 18:13, 1 September 2019 (UTC)

Michael F 1967, deep inside Module:Convert/documentation/conversion data (but not in the documentation) we have thrust specific fuel consumption factors "si tsfc" and "tsfc". Then {{cvt|20|tsfc|si tsfc}} produces 20 lb/(lbf⋅h) (570 g/(kN⋅s)). The units "kg/(kN·h)" would seem to make more sense. Could the conversion be changed or at least added to convert? StarryGrandma (talk) 18:58, 1 September 2019 (UTC)
Thanks for this. I've had another look and it seems that on the page thrust-specific fuel consumption, there are specific fuel consumption figures explicitly (if mistakenly) provided in g/kN/s (which should be g/kN·s). That leads me to think that g/kN·s is the preferred means of expressing the quantity when using SI units in this context. Strange to see something using grams rather than kilograms - but then again, maybe it's to give a conveniently-sized number when using seconds rather than hours.
I've just done a bit of searching on-line and I can't find anything to guide me one way or another on this, beyond the Wikipedia page I mention above.
In the absence of any other guidance, I'd be inclined to stick with g/kN·s.
I was puzzled that thrust specific fuel consumption is listed in the speed section - but having done a bit of scribbling it seems that it's got the dimensions of inverse speed which seems to be what "invert" in the "Extra" column means.
(It's odd seeing specific impulse in the speed section, too: kN‑s/kg. But then again, that works out to m/s so yeah, it's in the right place)
It seems to me that the sensible thing to do would be to label the various entries for specific impulse and thrust specific fuel consumption with their descriptive names in the table at Module:Convert/documentation/conversion_data#Speed so that they might be found easily by a human searching.
Is that something I could safely do myself without messing anything up?
Michael F 1967 (talk) 20:52, 1 September 2019 (UTC)
I think the safest thing to do would be to add the units to Template:Convert/list of units, which is linked from the main documentation page. That page isn't involved in generating the code and is more likely to be found by someone looking for help. StarryGrandma (talk) 23:34, 1 September 2019 (UTC)
Or maybe not as easy to find, but I still think it is a safer place. StarryGrandma (talk) 23:39, 1 September 2019 (UTC)
Surely kg/(kN·h) is exactly the same as kg/kN/h ? If 120 kg are consumed producing 3 kN for 2 hours, then 120/(3x2) = 120/6 = 20 kg/(kN·h). Also 120/3/2 = 40/2 = 20 kg/kN/h. How can either of these units be considered "incorrect"? --RexxS (talk) 01:39, 2 September 2019 (UTC)
You know what? You're completely correct. I shall have to think more carefully in future. Michael F 1967 (talk) 02:38, 2 September 2019 (UTC)

Proposed edit

I'd like to propose that an HTML span wrap around the output of this template, so that it can be targeted by user scripts. See phab:T231759 for background, and Special:Diff/913565347 for the proposed edit. Thoughts? --DannyS712 (talk) 21:27, 1 September 2019 (UTC)

Currently, for example, {{convert|71|kg}} outputs:
71 kilograms (157 lb)
The proposal is that it would instead output:
<span class="template-convert">71 kilograms (157&nbsp;lb)</span>
Apparently this is so the OP could write a script to allow them to suppress certain units. For example, they might see 157 lb when viewing the output and not the kilograms stuff. I am not in favor of padding stuff out without seeing a strong need. For the example, the output would be changed from 26 bytes to 64 bytes. Who would benefit from this? Johnuniq (talk) 23:25, 1 September 2019 (UTC)
@Johnuniq: this isn't for me, but rather for @Akeosnhaoe - the benefit would be that scripts can target the text output by the template. Can I ask what draw backs you see from this change? If the concern is about the extra characters, I would suggest that we Don't worry about performance. Thanks, --DannyS712 (talk) 23:30, 1 September 2019 (UTC)
One user wants to see pounds and not kilograms, so all articles should be padded? My attitude would be different if there were a pointer to a widely advertised discussion showing consensus that such a change should occur. Johnuniq (talk) 23:43, 1 September 2019 (UTC)
@Johnuniq: I want to see kilograms and not see pounds. Lots of people want Wikipedia to completely remove imperial units. They would probably also use an option to hide them.
This specific proposal is not exactly what I had in mind. Ideally I want this as a built-in Wikipedia setting that hooks into the Convert template, just like there is for date formatting https://meta.wikimedia.org/wiki/Help:Date_formatting_and_linking, as this user suggested back in 2005 Wikipedia:Measurements_Debate#Automatic_software_conversion. But if that's not possible, I guess this is good enough to be useful, it would make it easier to write a browser extension to target imperial units than it is now. Akeosnhaoe (talk) 00:53, 2 September 2019 (UTC)

I still think a wide discussion (not just here) should occur before such a change. Meanwhile, I'm wondering how this would interact with various options. The following shows some converts and their outputs. Would these work if the output is wrapped with <span class="template-convert">...</span>? WOSlinker can you please check. 

{{convert|71|kg|sortable=on}}
<span data-sort-value="7001710000000000000♠"></span>71 kilograms (157&nbsp;lb)

{{convert|71|kg|disp=table}}
style="text-align:right;"|71
|style="text-align:right;"|157

{{convert|71|kg|disp=table|sortable=on}}
style="text-align:right;" data-sort-value="7001710000000000000"|71
|style="text-align:right;" data-sort-value="7001710000000000000"|157

Johnuniq (talk) 04:00, 2 September 2019 (UTC)

While convert with the table options still looks ok visually, it's got the span tags in odd places, so I think it would be better to add the span tags in the module and also not add them if the table option is used.
  • 71 kilograms (157 lb)
  • 157 pounds (71 kg)
  • 71 kilograms (157 lb)
  • 157 pounds (71 kg)
  • 71 kg (157 lb)
  • 157 pounds (71 kilograms)
  • 157 pounds (71 kg; 2,510 oz)
  • 157 pounds (2,510 oz; 71 kg)
  • 157 pounds (2,510 oz)
  • 71–75 kilograms (157–165 lb)
Also, just wondering how a gadget would be able to handle all the different formatting option for all the imperial units? Just a handful shown above. -- WOSlinker (talk) 08:30, 2 September 2019 (UTC)
Good point. Also, for example, {{convert|1.13|kg|lb|disp=or}} is used at Muja Power Station in "(1.13 kilograms or 2.5 pounds)". I suppose a gadget would not have to work correctly all the time. Johnuniq (talk) 10:37, 2 September 2019 (UTC)
I'm also in the process of creating modules for use in power stations that draw data from Wikidata. One of the things these modules may do is internally call {{cvt}} (via frame:expandTemplate). It's one thing to adapt {{convert}} on the assumption that its output goes straight to html/the wiki parser, but it's another altogether when a different module is calling it and expecting "clean" text to be returned. I don't know how many cases there are of this template being called internally in another module, perhaps very few, but it's certainly a consideration we ought to be anticipating. --RexxS (talk) 15:13, 2 September 2019 (UTC)

Cuerda to acre and vice versa

Cuerda!

Would it be possible for someone knowledgeable with conversion templates to expand this one so it can convert cuerdas to acres, and vice versa. The equation is 1.000 cuerda = 0.971 acres. Thanks, Mercy11 (talk) 01:39, 4 September 2019 (UTC)

@Mercy11: The unit code is cda which is documented here. Examples:
  • {{convert|12,300|cda|abbr=off}} → 12,300 cuerdas (4,800 hectares; 11,900 acres)
  • {{convert|12,300|cda|abbr=on|lk=in}} → 12,300 cda (4,800 ha; 11,900 acres)
Johnuniq (talk) 04:43, 4 September 2019 (UTC)
As noted in its article, there are multiple definitions of cuerda. Is there a way to warn editors that this conversion is valid only for the Puerto Rican cuarda? --John Maynard Friedman (talk) 11:08, 4 September 2019 (UTC)
It sounds like a curse. EEng 11:28, 4 September 2019 (UTC)

I have previously said that cuerda should not be supported by convert because it is vague and has multiple meanings. Some history:

  • August 2013 • cuerda proposed and made a temporary unit
  • April 2017 • doubts about cuerda
  • May 2017 • cuerda made a temporary unit to track usage
  • July 2018 • cuerda added as it had again been made a temporary unit and was used

There are some missing details that I haven't found at the moment. Johnuniq (talk) 00:58, 5 September 2019 (UTC)

The cuerda article was poorly written, perhaps leading to confusion. I have re-organized it, applying the cites to where they actually belonged, to help reduce confusion, and questioning the validity of some sources.
Still, I don't see any problem with the cuerda conversion template as it has stood for years. It is implemented as per the Puerto Rican cuerda meaning. This makes sense since that's the only definition that is authoritative as it is supported by an Act of Legislature. Of the other definitions, some come from WP:SPS sites and some from questionable or at best incomplete sources. Also, of all the uses of that templete in WP, I haven't seen where it was used, even once, for something other than the Puerto Rico land area measurement (as intended). Hope this helps. Mercy11 (talk) 04:11, 5 September 2019 (UTC)
So in PR it is an area measure, but Guatemala it can also be a unit of length? Sure we need a good article on that. But {{Convert}} is not encyclopedic by itself, it is just a helper for conversions. When definitions are this complicated and variant, including it in {{Convert}} does not help wikipedia (what a documentation page that would be). Are there many articles relying on this conversion? (alternative option: create "cuerdaPR"). -DePiep (talk) 19:58, 7 September 2019 (UTC)

Units for Electric Vehicle Fuel Consumption

The units used across most of Europe are kWh/100km, whereas the units used within UK (and presumably US) are mi/kWh. Trying this conversion gives Error in convert: Cannot convert "energy per unit length" to "length/energy". Since the conversion of L/100km to mpg is effectively the same "reciprocal of unit types" but works, I guess there is a way to add this conversion?

I've never modified a template on here before, so thought it would be best to bring it up here before trying to add it myself. — Preceding unsigned comment added by ProgrammerJoe (talk • contribs) 19:25, 7 September 2019 (UTC)

This (slash is recognised)?
{{convert|1000|mi/kWh}} → 1,000 miles per kilowatt-hour (450 km/MJ)
Todo: inverse somehow. -DePiep (talk) 20:09, 7 September 2019 (UTC)
Convert supports mpge (miles per gallon gasoline equivalent).
  • {{convert|101|mpge|kWh/100km|abbr=on}} → 101 mpg‑e (21 kWh/100 km)
If that is not sufficient, please link to sections in a couple of articles where a new unit would be used. Is there an article where mi/kWh is explained? Johnuniq (talk) 23:21, 7 September 2019 (UTC)

New unit

In cooking, there is a unit called "cup" of which 1 equates to 236.588 millilitres

Could this be added? Back ache (talk) 10:59, 18 September 2019 (UTC)

Previous discussion was at Template_talk:Convert/Archive_May_2019#U.S._Cup_as_unit? Size is not standardised.  Stepho  talk  11:03, 18 September 2019 (UTC)
To make things more "interesting" there aparently also exists the US metric cup of 240 ml. Peter Horn User talk 15:06, 18 September 2019 (UTC)

Conversion of Imperial and US hundred weight to kg

For sack (unit)#Conversion Peter Horn User talk 14:56, 18 September 2019 (UTC)

That all should have read {{convert|2|cwtimp|lb kg|abbr=on}} or/and {{convert|2|cwtUS|lb kg|abbr=on}} Peter Horn User talk 16:41, 18 September 2019 (UTC)
The units are "long" and "short" as follows:
  • {{convert|2|Lcwt|abbr=on}} → 2 long hundredweight (220 lb)
  • {{convert|2|Scwt|abbr=on}} → 2 short hundredweight (200 lb)
  • {{convert|2|long cwt|abbr=on}} → 2 long cwt (220 lb; 100 kg)
  • {{convert|2|short cwt|abbr=on}} → 2 short cwt (200 lb; 91 kg)
Johnuniq (talk) 01:15, 19 September 2019 (UTC)

Pressure in gauge and absolute units?

Does the conversion template understand between gauge and absolute pressures? They're the same scale, but one is offset by atmospheric pressure. Riveted Fox (talk) 12:25, 23 September 2019 (UTC)

You mean like with temperature:
Absolute: {{convert|20|C|F}} → 20 °C (68 °F)
Delta: {{convert|20|C-change|F-change}} → 20 °C (36 °F)
Do you have examples of wrong conversion re pressure? -DePiep (talk) 14:52, 23 September 2019 (UTC)
I dont have an example. I cant see a way to make the template do it.
That delta might be possible, but its really long-winded.
{ convert|14.7|psia|psig} should give 14.7 psi (0 psi) or something like that. Always the same offset. Riveted Fox (talk) 15:54, 23 September 2019 (UTC)
{convert|14.7|psi|psig} → 14.7 pounds per square inch ([convert: unknown unit])
'psia', 'psig' unk units. Not nough info to continue. -DePiep (talk) 15:57, 23 September 2019 (UTC)
So? It should already recognise 'psig'? I couldnt get this to work, but its how I'd expect it to work?? absolute pressure gauge pressure Riveted Fox (talk) 16:07, 23 September 2019 (UTC)
Best would be to provide a simple example (could be from an article, or from a textbook), using known unit names or abbreviations. For example, in psi only, a difference between those two values (gauge & absolute). When that is clear and illlustrating the question, a conversion (a second pressure unit) might be added. -DePiep (talk) 17:57, 23 September 2019 (UTC)

One can't convert unless one knows the actual atmospheric pressure at the location of the gauge. In situations where these distinctions need to be delved into, it's probably better to explain it in prose rather than use a template. And if, perchance, the original poster isn't clear about the distinction, then using a template is definitely the wrong thing to do. Jc3s5h (talk) 18:46, 23 September 2019 (UTC)

6'1

Hey- I want to give the meters of height for someone that's 6'1 on the 1948 United States Senate election in Texas page. I used the convert template like this (convert|6|ft|1|in|m|abbr=on) and it reads as '6 ft 1 in (1.85 m)'. Is there any way I can make it so that the convert template gives me "6'1 (1.85 m)" instead? I think that writing it like "6'1 (1.85 m)" would be more in line with the way in which the original editor was writing, and I don't want to dumb down the style of the article without cause. Geographyinitiative (talk) 01:44, 22 September 2019 (UTC)

Per Wikipedia:Manual_of_Style/Dates_and_numbers#Specific_units, don't use ' and " for feet and inches. EEng 02:18, 22 September 2019 (UTC)
Don't forget x for yards. Hawkeye7 (discuss) 20:33, 25 September 2019 (UTC)
Was there ever a similar superscript abbreviation for the larger units: chains, furlongs and miles? Martin of Sheffield (talk) 20:57, 25 September 2019 (UTC)
EEng explained that ' and " should not be used. Re the technical question, no, convert cannot show anything other than feet/ft and inch/in. Johnuniq (talk) 03:35, 22 September 2019 (UTC)

Using this template from a lua module

is there a good way to use Module:Convert from another lua module? I was working on 'Module:Person height' and at the moment I am going through the template, which is probably not the most efficient, but certainly more efficient than the current version of 'Template:Infobox person/height'. Frietjes (talk) 15:47, 25 September 2019 (UTC)

@Frietjes: You're only expanding 'template convert' once per call to Person height|main, so any inefficiency is going to be negligible. If you really wanted to eke the last bit of performance, you could modify Module:Convert so that main_convert preprocessed the frame and then called a sub-function that did the rest of the work, passing just the args table. That sub-function could then be exported to other modules and directly loaded as required. I could be mistaken, but my experience tells me that any tiny performance gain isn't going to be worth the effort. --RexxS (talk) 17:00, 25 September 2019 (UTC)
A priori predictions of what matters to performance are always wrong. Code it in the clearest and most straightforward way possible. EEng 17:04, 25 September 2019 (UTC)
Unfortunately, a priori assessments of predictions of what matters to performance are also always wrong. If we were coding from scratch, we'd do it differently, but we're not; so feel free to re-code this module in the clearest and most straightforward way possible. I'm sure Johnuniq will appreciate it. --RexxS (talk) 17:12, 25 September 2019 (UTC)
Regrettably, a priori prognostications of assessments of predictions of what matters to performance are, additionally, always wrong, so feel at liberty to code this in the clearest and most straightforward way possible. EEng 17:24, 25 September 2019 (UTC)
Read the OP. It is what Frietjes is looking for. Your replies however did not bring her any closer to that aim. -DePiep (talk) 18:44, 25 September 2019 (UTC)
Yes it did. It explained that she should ignore putative performance considerations. EEng 21:13, 25 September 2019 (UTC)
And I explained that you were talking through your arse and were offering her advice on a subject that you have no knowledge of. The performance cost of a single call to template:convert is at worst around 25 ms of CPU time and 50 bytes of memory. So the answer to the original question, "is there a good way to use Module:Convert from another lua module?", remains "Yes, you can re-write the module to create another entry point that doesn't expect a frame object, and then require('Module:Convert') from the other Lua module". But the rider is that in this case the effort is large compared to any possible performance gain over using frame:expandTemplate. --RexxS (talk) 21:46, 25 September 2019 (UTC)
Well, to be honest you posted your response just before mine, and I didn’t notice that once the edit window was open; I was responding to the OP. I assure you, however, that I do know what I’m talking about. The 25 ms and 50 bytes matter, in the context of what the OP is doing... why? EEng 23:09, 25 September 2019 (UTC)
Ah, ok. I see now. Mea culpa. To answer your question seriously (for a change): Module:Person height makes use of Template:Convert internally by calling it via the frame:expandTemplate method available to Scribunto modules. That has to set up a template call, pass the arguments, and then return the results to the call. If Module:Convert had a direct entry point available to other modules, then we could bypass calling the template and save some CPU time/memory. If you try running a few calls to Template:Convert and comparing the 'Parser profiling data' with and without the call, you'll find that a convert template consumes around 25 ms CPU time and 50 or bytes of memory. That means that the most resources we could save by bypassing the template and using the module directly can't be any greater than those values. Of course that's for a single call, and if we called the template multiple times in a module, then the savings would start to add up and begin to look significant. As it happens, though, Frietjes has constructed Module:Person height so that it only ever calls a conversion once. And that's why I suggested there aren't many savings to be made in her module by attempting to use Module:Convert directly, instead of via the template. Hope that makes sense. --RexxS (talk) 00:57, 26 September 2019 (UTC)
It certainly does. We were in violent agreement. EEng 09:53, 26 September 2019 (UTC)

thank for the feedback, a simple lua entry point into Module:Convert could be helpful, but isn't critical. I believe Module:Person height is an improvement over template:infobox person/height + template:infobox person/height/locate + template:infobox person/height/switch in terms of (1) readability, (2) performance, and (3) extensibility (e.g., the addition of the prefer and enforce parameters for m vs cm). however, I am sure there are ways to improve it even more so any additional feedback is welcome (most of the short variable names were inherited from the older template). Frietjes (talk) 19:29, 25 September 2019 (UTC)

Sorry, but as noted and due to historical reasons, Module:Convert has no entry point for another module. Convert was one of the first modules to be developed, starting at test2wiki before Scribunto was available here, and I wasn't sure it would manage all the work required so other modules and nice-to-have features were not a consideration. Convert has some assumptions about how a template handles parameters, and it expects that certain configuration items (not needed at enwiki) can be read from the parameters in the wikitext in Template:Convert. Adding an entry point is on my to-do list but getting to the end of that is looking less likely. Johnuniq (talk) 00:34, 26 September 2019 (UTC)

Default conversion with Wikidata

Example from Johan Cruyff (Q17163) and height (P2048), 178 centimetre:

  • {{convert | qid=Q17163 | input=P2048 | m | disp=out}} gives 1.78 m Green tickY
  • {{convert|qid=Q17163|input=P2048|m|disp=out}} gives 1.78 m Green tickY
  • {{convert | qid=Q17163 | input=P2048 | cm | disp=out}} gives 178 cm Green tickY
  • {{convert|qid=Q17163|input=P2048|cm|disp=out}} gives 70 in Red XN

When I try to fetch it with the same unit defined in Wikidata (seems weird but it is unknown a priori), it does a default conversion when the unit parameter has no space at the beginning or the end. The disp=out option does not affect this behavior, it is for convenience to avoid strange outputs as "178 cm (178 cm)". Pinging Amadalvarez as initial reporter. --Vriullop (talk) 07:55, 27 September 2019 (UTC)

@Vriullop and Amadalvarez: I hope you don't mind but I moved this to here. Sorry about the confusion at Module talk:Convert, I'll try to make it more explicit that discussion like this should be here. I will look at the issue and respond in due course. Johnuniq (talk) 08:03, 27 September 2019 (UTC)
Hmm, interesting problem. A hint about what's going on is seen with the following. In each convert, |qid=Q17163|input=P2048 is replaced with |178|cm as read from Wikidata.
  • {{convert|qid=Q17163|input=P2048|ftin}} → 178 centimetres (5 ft 10 in) (uses given output unit)
  • {{convert|qid=Q17163|input=P2048|mm}} → 178 centimetres (1,780 mm) (similar)
  • {{convert|qid=Q17163|input=P2048}} → 178 centimetres (70 in) (uses default output unit)
  • {{convert|qid=Q17163|input=P2048|cm}} → 178 centimetres (70 in) (uses default output unit)
Convert has some special-case code to handle the last case to avoid showing 178 centimetres (178 cm). Convert compares any specified output unit (cm in this case) with the input unit from Wikidata (also cm). Because they are the same, convert removes the specified output unit so the default will be used.
Convert does not trim spaces from the numbered parameters because in some cases spaces are significant (they appear in the output). When checking for a unit, convert trims spaces. However, due to an oversight (aka bug), the code handling the Wikidata special case does not trim spaces. For example, " cm" (has a leading space) is not the same as "cm" so the former would not be removed. If the bug were fixed, any spaces around cm would be removed so the cm would also be removed, giving the default output.
If someone wants to know what |qid=Q17163|input=P2048 contains ("178 centimetre" in this case), one of the Wikidata modules would probably do the job. If that is what is wanted, please say so and one of the watchers here will probably know what to do. I am puzzled why the unit is centimetre rather than centimeter because I thought I had seen an editor systematically change all the SI units to US spelling saying that was the standard. Convert uses the Wikidata ID so the label (centimetre or centimeter) is irrelevant for convert. Johnuniq (talk) 10:07, 27 September 2019 (UTC)
I know I can use a Wikidata module but units are not consistent and they do not manage unit conversions, AFAIK. Apart from the wikidata trim, I am more concerned about the default conversion being applied when using disp=out. In this case it does not show the requested unit. --Vriullop (talk) 11:53, 27 September 2019 (UTC)
Thanks, @Johnuniq:. Your last solution is not was I look for, because when I know that the unit is the same, then I have to make a new get -via module- to fetch the information as is in WD. This function you well describe is different as that what "convert" does when ask for a conversion cm to cm with manual parameter. Look that convert template could tell me that I'm stupid to ask for convert nothing, however is very polite and it returns the same value it got without do unit conversion. So, why doesn't have same behaviour when gets from WD ? specially, because I do not know a priori what is the unit I'll receive. By now, I fetch the info with wikidata module (value+unit), then I compare if unit received are the same that I wanted, if not, then I call manual convert using value+unit I got as source for "covert". So, only 1 access to WD and 0 or 1 calculation with convert. The wiki code is not clean, but cheaper than any other way. Could the logic be harmonitzed between manual and WD convert process for this circumstances ?. And alternative way: I tested to change the default table telling cm-cm instead cm-in and it ran perfectly. However, I reverted change because I did not know if it could have other side effects. What do you think ? Is default table used for any other action?. Thanks a lot, Amadalvarez (talk) 12:07, 27 September 2019 (UTC) cc. @Vriullop:

@Amadalvarez and Johnuniq: This isn't intended to be a solution, but I thought I'd supply some information about what we can do with the Wikidata modules:

  • {{wdib |ps=1 |qid=Q17163 |P2048}} → 178 centimetre
  • {{wdib |ps=1 |qid=Q17163 |P2048 |lang=fr}} → 178 centimètre
  • {{wdib |ps=1 |qid=Q17163 |P2048 |uabbr=y}} → 178 cm
  • {{wdib |ps=1 |qid=Q17163 |P2048 |conv=y}} → 178 cm (70 in)

The reason why the units actually use "-metre" as default rather than "-meter" is that I subsequently systematically changed all the unit labels from the US back to the SI standard spellings (following d:Talk:Q11573). If you really want to know what's going on on Wikidata, there is this tool:

  • {{examine |Q17163 |P2048}} →
table#1 {
    table#2 {
        ["id"] = "Q17163$586AE750-49A0-48E0-A425-62B8B46AA59C",
        ["mainsnak"] = table#3 {
            ["datatype"] = "quantity",
            ["datavalue"] = table#4 {
                ["type"] = "quantity",
                ["value"] = table#5 {
                    ["amount"] = "+178",
                    ["unit"] = "http://www.wikidata.org/entity/Q174728",
                },
            },
            ["property"] = "P2048",
            ["snaktype"] = "value",
        },
        ["rank"] = "normal",
        ["references"] = table#6 {
            table#7 {
                ["hash"] = "d5847b9b6032aa8b13dae3c2dfd9ed5d114d21b3",
                ["snaks"] = table#8 {
                    ["P143"] = table#9 {
                        table#10 {
                            ["datatype"] = "wikibase-item",
                            ["datavalue"] = table#11 {
                                ["type"] = "wikibase-entityid",
                                ["value"] = table#12 {
                                    ["entity-type"] = "item",
                                    ["id"] = "Q11920",
                                    ["numeric-id"] = 11920,
                                },
                            },
                            ["property"] = "P143",
                            ["snaktype"] = "value",
                        },
                    },
                },
                ["snaks-order"] = table#13 {
                    "P143",
                },
            },
        },
        ["type"] = "statement",
    },
}

HTH --RexxS (talk) 14:05, 27 September 2019 (UTC)

@RexxS: Thanks, that is helpful. At least I should be able to find them later. Johnuniq (talk) 02:14, 28 September 2019 (UTC)

@Amadalvarez: Convert omits the duplicate output unit for a specific reason related to the origin of the input= parameter, namely its use in certain infoboxes. Perhaps it should not do that when disp=out is used, but currently it does. The solution to your problem is to include a space in the output unit because, as explained above, that causes convert to not omit the duplicate unit. In fact, writing that makes me wonder if I intentionally did not trim the parameter—I normally would not forget something like that. At any rate perhaps this is a solution for you (note the space before "cm"):

  • {{convert|qid=Q17163|input=P2048| cm|disp=out}} → 178 cm

Johnuniq (talk) 02:22, 28 September 2019 (UTC)

@Johnuniq: It runs !!. So, do not trim it, please. Thanks. Amadalvarez (talk) 06:49, 28 September 2019 (UTC)

disp=in

Please could disp=in by enabled (counterpart of disp=out). This would allow {{convert}} to take care of the consistent/unit formatting/conversion/wordwrap protection; eg:

—Sladen (talk) 15:32, 28 September 2019 (UTC)

That is more difficult than would appear. I forget the reason but when I looked a couple of years ago it seemed complex although I can't see why at the moment. I stopped thinking about it because {{val}} should be able to do whatever is wanted if convert's workaround is unsatisfactory:
  • {{val|123|u=m}} → 123 m
  • {{convert|2|cuyd|cuyd|disp=out}} → 2.0 cu yd
Does val or the workaround satisfy your use case? Johnuniq (talk) 01:26, 29 September 2019 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_September_2019&oldid=922124716"