Template talk:Convert/Archive April 2014

Range input by single parameter - tests

This earlier discussion pointed to the option to enter a rangne of values in by a single parameter:

• {convert|10|to|20|km|mi}} → 10 to 20 kilometres (6.2 to 12.4 mi) -- classic Y
• {convert|10 to 20|km|mi}} → {convert|10 to 20|km|mi}} -- new: by single parameter Y

Testpage Template:Convert/testcases/range now has test comparisions of these cases. All Help:Convert#Range options are tested. But not all parameters settings are cross-checked, not many units. Compare:

• Testcases Classic multi-parameter input
• Testcases Single parameter

The next range indicators (separators) give issues:

test setup: {{Convert|5|and|12|kg}} vs {{Convert/sandbox|5 and 12|kg}}

1. and 5 and 12 kilograms (11 and 26 lb) vs 5 and 12 kilograms (11 and 26 lb)
2. and(-) 3 and 4 inches (76–102 mm) vs 3 and 4 inches (76–102 mm)
3. to about 140 to about 160 km/h (87 to about 99 mph) vs
4. × 3 by 4 inches (76 mm × 102 mm) vs 3 by 4 inches (76 mm × 102 mm)
5. ± 3 ± 4 inches (76 ± 102 mm) vs 3 ± 4 inches (76 ± 102 mm)
6. & 3 & vs 3 &
7. , 1.0, 0.8 metres (3.3, 2.6 ft) vs 1.0, 0.8 metres (3.3, 2.6 ft)
8. , and 1.0, and 0.8 metres (3.3, and 2.6 ft) vs
9. , or 10, 25 , or 100 -- (not all , or tests) vs
10. mixed

1. 3.5, 3.0 and 2.0 m (11 ft 6 in, 9 ft 10 in and 6 ft 7 in) vs 3.5, 3.0 and 2.0 m (11 ft 6 in, 9 ft 10 in and 6 ft 7 in)
2. 7.5 cm–16 cm × 3.5 cm–7.5 cm (3.0 in–6.3 in × 1.4 in–3.0 in) vs 7.5 cm–16 cm × 3.5 cm–7.5 cm (3.0 in–6.3 in × 1.4 in–3.0 in)
3. −7.5 cm – −16 cm × −3.5 cm – −7.5 cm (−3.0 in – −6.3 in × −1.4 in – −3.0 in) vs −7.5 cm – −16 cm × −3.5 cm – −7.5 cm (−3.0 in – −6.3 in × −1.4 in – −3.0 in)

Tests are against {convert/sandbox}. Covering all options alike (barred the impossible or contradicting situations) is the goal would be a great feature. Just think of the editos' ease! The simple documentation! -DePiep (talk) 13:01, 11 March 2014 (UTC)

I agree that natural language input would be desirable, but parsing it takes a significant time (and adds code complexity). The way convert currently handles simple ranges like "1 to 9" is that it tries to evaluate the input as a number, and when that fails it searches the input for certain range "words" such as "to" and "-". It takes the first found and splits the input into three components—in the above, that would be "1" and "to" and "9", and it tries again. A more logical approach would be to detect the first number ("1"), then examine what comes after it. However, convert accepts really weird stuff for numbers, and detecting the first number is not easy. We could agree that natural-language input would not work with weird numbers, and that would make parsing a lot easier. Examples of weird numbers are: 1.23e-6 and −12.5 (Unicode minus) and −12.5 (html entity) and +1+2/3 and -1-2/3 (and other, frankly absurd, values are also accepted for fractions). Johnuniq (talk) 04:36, 12 March 2014 (UTC)

If I understand you well, the weird numbers should be excluded from this service. And some symbols (that otherwise would work well in multi-parameter input). That would leave plain text on the could-do list, with en dash (range by MOS) on top. -DePiep (talk) 07:50, 2 April 2014 (UTC)

Yes, that can be in a longer-term to-do list. However, did I mention that en dash now works? However, it's only in the sandbox and is waiting for me to do the update I said I would. Example:

• {{convert/sandbox|10–15|mm}} → 10–15 millimetres (0.39–0.59 in)

That range is using an en dash. Johnuniq (talk) 08:55, 2 April 2014 (UTC)

My sloppy reading again, sorry. En dash was not even in my error-list above. To complete, these are the tests with negatives. Test: {convert} vs {convert/sandbox}.

1. vs -- ndash char used. Y
2. vs -- "to" range indicator. Y

These pass OK, together with the other tested options (testpages linked above). -DePiep (talk) 09:25, 2 April 2014 (UTC)

Tonnes per acre ~ tonnes per hectare

Winemaking needs these units, e.g. in this article.
For example:

• 3 tonnes per acre (7.5 tonnes/hectare)
  
• 4 tonnes per acre (9 tonnes/hectare)
  

or with |disp=flip when the article does not deal directly with the US or UK.--Carnby (talk) 13:10, 31 March 2014 (UTC)

Done, examples:

• {{convert|3|tonne/acre|abbr=off}} → 3 tonnes per acre (7.4 tonnes per hectare)
• {{convert|4|tonne/acre|abbr=off}} → 4 tonnes per acre (9.9 tonnes per hectare)
• {{convert|12.5|tonne/acre}} → 12.5 tonnes per acre (31 t/ha)
• {{convert|12.5|tonne/ha}} → 12.5 tonnes per hectare (5.1 t/acre)
• {{convert|30.9|tonne/acre|disp=flip|abbr=off}} → 76 tonnes per hectare (30.9 tonnes per acre)

The default is to abbreviate the output, so that has to be set to "off" if wanted. Johnuniq (talk) 23:50, 31 March 2014 (UTC)

@Carnby: I'm not sure if you have seen this, but the above units now work. The blunder I mention next does not affect how the units work.

Blunder fixed: When adding the above, I called the units "mass per unit area" as that is the most logical. I had this nagging feeling in the back of my mind that something was wrong because I was sure I had seen units of that type before (but could not find them), as well mention of "spread rate". Now I recall that all the mass/area units were redefined as pressure, with a trick (multiplier = 9.80665) to make the conversions work. That allows conversion between a larger number of units (the module only permits conversions between units of the same type, with a couple of exceptions). I fixed the units at Module:Convert/extra but for the record am putting this explanation here hoping it will help me or others understand this in the future. Search terms: "mass per area" and "mass per unit area" and "mass/area" and "pressure". Archives: Feb 2014 and Oct 2013. Johnuniq (talk) 06:06, 2 April 2014 (UTC)

Thank you, now they seem to work. I have already edited the page about Chianti wine.--Carnby (talk) 10:28, 2 April 2014 (UTC)

That's not ambiguous

I'm getting an error saying that my convert from feet to m is ambiguous. The help text tells me to use ft instead of feet.

Well, that's definitely not "ambiguous", so the error message is wrong.

Moreover, why am I even getting this error? If the system understands my intent, which it obviously does, why report anything? Do we expect another "feet" that might appear and cause a problem?

Maury Markowitz (talk) 11:14, 2 April 2014 (UTC)

Like in

{{convert|1|feet|m}} → 1 foot (0.30 m)

Well, units don't pluralize in measurements. Maybe the error message could better be "unknown unit", but I doubt if that would help you. -DePiep (talk) 11:32, 2 April 2014 (UTC)

However,

{{convert|1|ft|m}} → 1 foot (0.30 m)

{{convert|2|ft|m}} → 2 feet (0.61 m)

{{convert|2|feet|m}} → 2 feet (0.61 m)

With Maury Markowitz, I am confused. -DePiep (talk) 11:57, 2 April 2014 (UTC)

Thanks for raising this issue. The following unit codes generate "ambiguous unit" where the unit really is ambiguous and the message is reasonable:

• gallon • Use "USgal" for US gallons or "impgal" for imperial gallons (not "gallon")
• gallons • Use "USgal" for US gallons or "impgal" for imperial gallons (not "gallons")
• pt • Use "USpt" for US pints or "imppt" for imperial pints (not "pt")
• qt • Use "USqt" for US quarts or "impqt" for imperial quarts (not "qt")
• mpg • Use "mpgus" for miles per US gallon or "mpgimp" for miles per imperial gallon (not "mpg")

The following unit codes generate "ambiguous unit" where it is not ambiguous:

• L100km • Use "L/100 km" (not "L100km")
• feet • Use "ft" (not "feet")
• light-year • Use "ly" (not "light-year")
• light-years • Use "ly" (not "light-years")
• meter • Use "m" (not "meter")
• meters • Use "m" (not "meters")
• metre • Use "m" (not "metre")
• metres • Use "m" (not "metres")
• kilogram • Use "kg" (not "kilogram")
• sq feet • Use "sqft" (not "sq feet")

The module is doing something similar to what the old templates did, although the "ambiguous unit" text is my addition—I must have got lazy regarding the second set of units above and not made a separate error code for them. What to do? I'm from the old school where editors should use the "right" unit code because it's confusing if some converts use "ft" while others use "feet" as anyone noticing that is going to wonder what the difference is, and which one they should use. However, we already have aliases like sqm being the same as m2. How about we split the difference and make the following units aliases:

• feet • Same as "ft"
• light-year • Same as "ly"
• meter • Same as "m"
• metre • Same as "m"
• kilogram • Same as "kg"

But, remove the following unit codes. If someone uses one of these, the result would be "unknown unit":

• light-years
• meters
• metres
• L100km
• sq feet

There is no reason to support plural names for the first three, and no reason to support "sq feet" but not "sq. feet" or "square feet" for the last. Also, I don't see why "L100km" would be needed—it would be very rare that an editor would type that? Thoughts? Johnuniq (talk) 05:37, 3 April 2014 (UTC)

L100km is wrong and so not acceptable.

m and ft: hell, the plural is in the outcome! How could it be unacceptable for the input?

5 metres (16 feet)

5 square feet (0.46 square metres)

light-years not commonly used, but the plural seems not confusing. -DePiep (talk) 06:54, 3 April 2014 (UTC)

I don't see the point in adding aliases unless they really are needed. Each alias is inconsequential, but taken together they add complexity. Johnuniq (talk) 08:46, 3 April 2014 (UTC)

Hard to argue against that, but I'd thought once one alias is in, it's only more of the same. -DePiep (talk) 20:23, 3 April 2014 (UTC)

Johnuniq, I will not belittle your point about redundancy, but let me offer a personal take on this… HyperTalk was easy to program because they deliberately added such redundant terms, specifically so that people using it would be able to write code their way instead of the programmers. The Wiki, one might argue, should be easier to use than a programming language, so I vote in favour of making your life harder if that makes mine easier. See, so easy! :-) More to the point, I think "gotchas" like this one are precisely the sort of thing we should avoid if possible, and I'd much prefer to have "feet" work. But I leave it to you to decide whether this would complicate the back end too much. Maury Markowitz (talk) 22:55, 3 April 2014 (UTC)

OK, I have updated my files with the changes I proposed above, except I made "meters" and "metres" an alias for "m" rather than removing them. That will go live in the next release...not sure when that will be. Thanks again for pointing out the inappropriate message. Johnuniq (talk) 23:48, 3 April 2014 (UTC)

• Convert/old was overly restrictive about full names: As noted, the prior rejection of "feet" as a unit-code was started with {convert/old}, but there was no technical reason, perhaps only a fear of people using full names mixed for any unit "miles per hour" or "mi per hour" or hundreds of other combinations. In fact, unit-code "miles" and "acres" were used to test new features in {convert/old}:

• {convert/old |4|feet|m}} →
  ERROR {{Convert}}: Use "ft" (not "feet") as the unit code. Try:{{convert|4|ft|m|...}}.
  For other unit codes, see: Template:Convert/list of units.
• {convert/old |7|miles|km}} →
• {convert/old |9|acres|ha}} →
• {convert/old |9|acres|hect}} →

When {convert/old} displayed the large, orange error messages, people still left errors in pages for months, and so small superscript notes "^[fix cite]" were used instead. The unit-code "acres" was the first to autofix invalid "hect" as being "ha" with a warning. After years of allowing full name "|miles" for the "|mi" unit-code, no drawbacks were found, and nobody complained likewise that "|kilopascals" should be allowed now as a unit-code. -Wikid77 11:25, 4 April 2014 (UTC)

Protected edit request on 5 April 2014

Under "Range of 2 values" one of the examples appears to be wrong. It says that

{{convert|60|by|120|ft}}

displays as

60 by 120 metres (200 by 390 ft)

but it actually displays as

60 by 120 feet (18 by 37 m)

(which is what I would expect - the specified unit is the "from" unit, not the "to" unit.)

Could someone fix it please. (Or explain what I'm doing wrong.)

Mitch Ames (talk) 07:48, 5 April 2014 (UTC)

The error was on the unprotected Template:Convert/doc, which could be edited by anyone. I have fixed the error. Imzadi 1979 → 07:59, 5 April 2014 (UTC)

Thanks for reporting this, but in case you did not notice, be sure to look at Help:Convert which has some more up-to-date information. All the documentation (here and at Help:Convert) needs fixing, and is on my to-do list. Johnuniq (talk) 09:48, 5 April 2014 (UTC)

ktTNT

The ktTNT parameter should probably output as kiloton and not kilotonne is what is used on the main page, TNT equivalent. This is not the unit of mass, so it is unclear that the current spelling is in any way correct. If it is determined that the current spelling is correct, the template should respect the sp=us parameter. Vegaswikian (talk) 22:45, 5 April 2014 (UTC)

The system of units grew over several years as people asked for different things; the result is a bit confusing. The following units are available (the full list is here):

unitcode   link             default   symbol              name1              name1_us
kt(TNT)    TNT equivalent   TJ        kt                  kilotonne          kiloton
ktonTNT    TNT equivalent   TJ        kt                  kiloton of TNT     --
ktTNT      TNT equivalent   TJ        kilotonne of TNT    kilotonne of TNT   --

That means that kt(TNT) changes its name with sp=us, but the others don't. I do not know what is correct, and am just reporting what I know about convert. Johnuniq (talk) 23:32, 5 April 2014 (UTC)

Thanks. These probably need to be reduced to one with a bot cleaning up the other options and then dropping support. Vegaswikian (talk) 18:25, 7 April 2014 (UTC)

Module version 3

Quite a lot of changes to the module have occurred, and I have updated the sandbox modules to the latest versions. I intend switching the main modules to use the sandbox soon.

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • different (diff)
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

Following is an overview of the changes.

• Move units from Module:Convert/extra to main data.
• Adjust some "should be" units, for example "feet" will be the same as "ft" rather than an incorrect "ambiguous unit" error message (see discussion).
• Range and(-) now gives "and" for input and "–" (en dash) for output, instead of "and" for both.
• More range words are possible in a "simple range" like {{convert|1–5|ft}} (a range using en dash).
• Fix problem introduced in version 2 whereby a convert using a range loaded Module:Convert/extra because it looked the range word up as a unit.
• Fix glitch in processing some unknown input units.
• Fix some singular/plural issues, mainly for output multiples like ftin which could produce "1+1⁄2 inch" (incorrect singular) instead of "1+1⁄2 inches" (correct plural).
• Adjust processing of adj=mid option so other wikis can disable hyphenation.
• Make decimal mark and thousand separator more versatile for other wikis; also, can specify values in convert/text.
• Template:Convert/sandbox now uses |sandbox=sandbox instead of |sandbox=on so the sandbox name can be specified at other wikis.
• Remove assumptions regarding position of SI prefixes in SI units for more flexibility at other wikis.
• For other wikis, can set abbr to be "on always" or "off always" or "on default" or "off default".
• For fawiki, if looking up a unit fails, try again after translating any digits from the local language (they run a script to translate all English digits which, for example, changes "km2" to "km۲").

By the way, I have updated the transwiki guide which includes a link to a new translate page. Johnuniq (talk) 03:50, 6 April 2014 (UTC)

Looks good! Thanks! Plastikspork _―Œ^(talk) 14:15, 6 April 2014 (UTC)

I second that. Both the module/template and the development process are a pleasure to work with. -DePiep (talk) 14:55, 6 April 2014 (UTC)

• Done, the modules have been updated. Thanks for the encouragement! Johnuniq (talk) 00:26, 8 April 2014 (UTC)

st changed from 'short tons' to 'stone'

Hello all - 'st' in the template seems to have been changed from 'short tons' to 'stone' at some point in the past... few months? This has thrown out lots of articles, like HMS Richard Bacon, where short tons are now reporting as stone. Could this be fixed somehow please? Chase me ladies, I'm the Cavalry (Message me) 18:31, 5 April 2014 (UTC)

No, I think st has been stone for a long time (see the history of the old template, now unused, at Template:Convert/st). Both LT and lt are long tons with a tiny difference (see mass units), but ST is short tons while st is stone. After checking that it makes no difference for how lt is used in the article, I changed all lt to LT and all st to ST (diff). Johnuniq (talk) 22:22, 5 April 2014 (UTC)

Thankyou Johnuniq! Chase me ladies, I'm the Cavalry (Message me) 22:06, 8 April 2014 (UTC)

Spelling

For Chaldron#Coal {{convert/spell|1|impqt|L USqt|lk=on}} one imperial quart (1.1 L; 1.2 US qt) as compared to {{convert|1|impqt|L USqt|lk=on}} 1 imperial quart (1.1 L; 1.2 US qt). Something is going wrong in the former. Peter Horn User talk 03:25, 15 April 2014 (UTC)

Please see Help:Convert#Spell for how spelling is handled now (all templates of form convert/xxx are from the old system and have been replaced by {{convert}}). Example:

• {{convert|1|impqt|L USqt|lk=on|spell=in}} → one imperial quart (1.1 L; 1.2 US qt)

I changed the section name from "A bug" to "Spelling" which might help others find this in the future. Johnuniq (talk) 07:35, 15 April 2014 (UTC)

Some missing units

Some missing units: I have noticed "e6ST" had been missing "million": {convert/old |9|e6t|e6ST}} as "

" not as "9 million tonnes (9.9×10^⁶ short tons)" and might need others not copied from {convert/old}. -Wikid77 (talk) 17:56, 10 April 2014 (UTC)

Is there a problem? Consider:

• {{convert|9|e6t|e6ST}} → 9 million tonnes (9.9×10^⁶ short tons)
• {{convert|9|e6t|e6ST|abbr=off}} → 9 million tonnes (9.9 million short tons)
• {{convert|9|e6t|e6ST|abbr=on}} → 9×10^⁶ t (9.9×10^⁶ short tons)
• {{convert/old|9|e6t|e6ST}} →
• {{convert/old|9|e6t|e6ST|abbr=off}} →
• {{convert/old|9|e6t|e6ST|abbr=on}} →

That seems ok? Johnuniq (talk) 23:10, 10 April 2014 (UTC)

yes, seems to be fine, and actually an improvement over the old version. Frietjes (talk) 23:46, 10 April 2014 (UTC)

• Johnuniq Has it been considered to allow the "e6" notation into the number input (in some form), not the unit input? search for "e6 e9" in archives -DePiep (talk) 12:29, 13 April 2014 (UTC)
  • could be useful, considering that 9×10⁶ t (9.9×10⁶ short tons) sort of works. Frietjes (talk) 18:59, 13 April 2014 (UTC)

Well, that is a bit small. Some "e6" in some form notation is common and general numeric notation, so for a Grand Convert module it should be target functionality. I know it might imply a big redesign of the module, but now that we are freed of the old wikicode templates, we could aim for that. -DePiep (talk) 20:38, 13 April 2014 (UTC)

Yes, I have wondered about the fact that input like 12.5e6 is accepted and does not give a good result (it shows the input as 12.5e6). I'll probably need to be reminded/prodded in a couple of months. Johnuniq (talk) 02:56, 14 April 2014 (UTC)

For Chaldron#Coal please add 52+1⁄2 cwt {{convert|52+1/2|cwt|lb kg|abbr=on|lk=on|disp=or}} Peter Horn User talk 01:30, 14 April 2014 (UTC)

Please use "long hundredweight" or "short hundredweight", see hundredweight.

• {{convert|52+1/2|Lcwt|lb kg|abbr=on|lk=on|disp=or}} → 52+1⁄2 long hundredweight or 5,880 lb or 2,670 kg
• {{convert|52+1/2|Scwt|lb kg|abbr=on|lk=on|disp=or}} → 52+1⁄2 short hundredweight or 5,250 lb or 2,380 kg

The list of all units is disconcertingly large, but useful for searching. See Help:Convert which links to Help:Convert units which has the full list. Johnuniq (talk) 02:56, 14 April 2014 (UTC)

Thanks Peter Horn User talk 02:58, 15 April 2014 (UTC)

Again for Chaldron#Coal, how does one convert the likes of 36 bushels Winchester bushel? Peter Horn User talk 03:32, 15 April 2014 (UTC)

That's pretty obscure, and I don't think it's worth adding to {{convert}}. Following Winchester bushel shows that it is a redirect to bushel, and the only mention of "winchester" on that page is a "see also" link to Winchester measure. It looks like there were several historical usages of that measure, with differing details. The reference in Chaldron is this page at Google books, and it gives a very unclear statement of what is meant. It appears a London chaldron was specified as a volume equal to 36 somethings, where each something is a "Winchester bushel and a quart", being 19.5 inches diameter externally (no height specified). Winchester measure suggests that one kind of Winchester bushel was a cylinder 18.5 inches diameter internally, with 8-inch height. Quite a bit of research/thinking would be required to sort all that out, and ultimately the exact value would depend on which variation was being referred to. Google shows some interesting hits, but not much clarity. Johnuniq (talk) 11:18, 15 April 2014 (UTC)

Is this a bug in the template, missing non-break space?

Says it all. comp.arch (talk) 16:56, 29 April 2014 (UTC)

use xx. Frietjes (talk) 18:25, 29 April 2014 (UTC)

Not all enough (I was mislead into the 8 GB thing). You mean this:

	wikicode	result*	note
A	{{convert|115|x|115|x|17.5|mm|in|2|abbr=on}}	115 mm × 115 mm × 17.5 mm (4.53 in × 4.53 in × 0.69 in)	by {convert}
B	115 × 115 × 17.5 mm (4.53 × 4.53 × 0.69 in)	115 × 115 × 17.5 mm (4.53 × 4.53 × 0.69 in)	entered literally, using  
C	{{convert|115|xx|115|xx|17.5|mm|in|2|abbr=on}}	115 × 115 × 17.5 mm (4.53 × 4.53 × 0.69 in)	by {convert}
D	{{convert/3|115|x|115|x|17.5|mm|in|2|abbr=on}}	{{convert/3|115|x|115|x|17.5|mm|in|2|abbr=on}}	old wikicode template /3
E	{{convert/3 |115|x|115|x|17.5|mm|in|abbr=mos}}	{{convert/3|115|x|115|x|17.5|mm|in|abbr=mos}}

*Column 'result' has set style="max-width:5em". -DePiep (talk) 19:00, 29 April 2014 (UTC)

Oops, my previous editsummary was wrong. I do see the issue in the table. -DePiep (talk) 19:01, 29 April 2014 (UTC)

added C. Frietjes (talk) 19:21, 29 April 2014 (UTC)

It's a {convert}3D issue, clearly in the fringes of {convert}. -DePiep (talk) 21:23, 29 April 2014 (UTC)

Added D: old style wikicode. -DePiep (talk) 22:57, 29 April 2014 (UTC)

• This is my idea. Johnuniq Lua-converted wikicode {{convert}} successfully last December 2013. That was with the absolute promise to convert 1:1 with old documentation & definition of all {{convert/xxx}}. Now that we are free of that restriction, we can aim for module:convert 2.0. And redesign the input & parameter & structure of all {convert}. Even enwiki being the goto for this backoffice job! (otrher websites going to the enwiki:help:convert:Unit page). These unit relations are universal. Now I say this: we better redesign {convert} asap, and then export it to interwikis. If we wait one year, those iw's have the spaghetti 1.0 version. Since Juhnuniq is already working with 1.0 translations (iw) now, their opinion I'd like to hear mostly. -DePiep (talk) 21:23, 29 April 2014 (UTC)
  • I haven't gone totally to sleep as my attention has wandered to world domination: hiwiki and zhwiki and a couple of older ones. A large number of tweaks have occurred in the module to make it more accommodating for other languages. Re the above issue, I don't think anything better could be expected because there are people who hate large blocks of non-wrapping text, and they would strongly object if the output (in parentheses) was always a non-breaking blob. As Frietjes points out, the solution is to use a different option in an infobox. I'll add some details at Help:Convert#Ranges later, but in brief:
    • x (when abbr=on) uses " × " (starts with a space)
    • xx uses " × "
    • * uses "×"
  • Johnuniq (talk) 22:53, 29 April 2014 (UTC)

Just to make the point in time: setting the nowrap option by input "x" vs. "xx" is not universal. It should be set independently. That's 2.0. -DePiep (talk) 23:01, 29 April 2014 (UTC)

The syntax would need a lot of thought. By the way, this works:

• {{convert|115xx115xx17.5|mm|in|2|abbr=on}} → 115 × 115 × 17.5 mm (4.53 × 4.53 × 0.69 in)
• {{convert|115*115*17.5|mm|in|2|abbr=on}} → 115×115×17.5 mm (4.53×4.53×0.69 in)

Johnuniq (talk) 23:09, 29 April 2014 (UTC)

Thanks for changing Amazon Fire TV, but thinking about it more, shouldn't it be case E, I added? But then it looks bad (breaks at a bad point in the Infobox - another one than in this page). xx is not inituitive and the case used should be in the documentations.. comp.arch (talk) 11:57, 30 April 2014 (UTC)