![]() | 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. |
As discussed at #DPI and dots/cm and micrometres per dot, GliderMaven added some units to Module:Convert/extra that have an "invert" property, and proposed a change to the module's convert routine. I have implemented that change in the sandbox, and have tweaked the extra units (see Module:Convert/sandbox and Module:Convert/extra/sandbox). Please carefully check the changes and let me know if anything has gone wrong.
For units pitch and dpcm I simplified the link from Dots per inch#Proposed metrication to Dots per inch because the latter is adequate, and the former will become obsolete when someone changes the section heading, and the topic is not sufficiently important to warrant an anchor with the rather dated text of "Proposed metrication".
In some of the scales, I changed 9.8066 to 9.80665 because the latter is the value used by other units referring to g, and they may as well be consistent even if the extra precision is meaningless.
I omitted the "invert = 1" fields because they are not needed as the module assumes that value if converting with a unit with "invert = -1" and "iscomplex= true", and "invert = 1" is not needed when converting with other kinds of units. Eventually the new units need to be added to the master list, but that cannot happen until I have updated makeunits to handle these units. I'm thinking that putting "invert" in the "Extra" column will cause makeunits to set "invert = -1" and "iscomplex= true", and that might be the only change needed.
The pitch unit has a default output of dpi, but it also has symbol µm, and that conflicts with the default exception for µm. As a result, pitch has a default output unit of inches.
Following are the converts provided as examples by GliderMaven, using the sandbox modules.
{{convert/sandbox|10|dpi}}
→ 10 DPI (2,500 μm){{convert/sandbox|100|dpi|pitch}}
→ 100 DPI (250 μm){{convert/sandbox|100|dpi|dpcm}}
→ 100 DPI (39 dot/cm){{convert/sandbox|100|dpi|m}}
→ 100 DPI (0.00025 m){{convert/sandbox|100|dpi|mm}}
→ 100 DPI (0.25 mm){{convert/sandbox|100|dpi|thou}}
→ 100 DPI (10 thou){{convert/sandbox|100|pitch}}
→ 100 μm (250 DPI){{convert/sandbox|350|isp}}
→ 350 seconds (3.4 km/s){{convert/sandbox|1.2|tsfc|isp}}
→ 1.2 lb/(lbf⋅h) (3,000 s){{convert/sandbox|0.71|tsfc|isp}}
→ 0.71 lb/(lbf⋅h) (5,100 s){{convert/sandbox|450|isp|ft/s}}
→ 450 seconds (14,000 ft/s){{convert/sandbox|33|tsfc|km/s}}
→ 33 lb/(lbf⋅h) (1.1 km/s){{convert/sandbox|33|km/s|tsfc}}
→ 33 kilometres per second (1.1 lb/(lbf⋅h))We will need to discuss the unit types again because I still think that converting, say, DPI to furlongs is undesirable. Actually, converting DPI to inches is pretty bizarre. The alternative would be to use a unit type like "dotlength" and provide whitelisted exceptions that allow some units of type length to be converted to/from dotlength. A similar consideration applies to the other new units, although they are much more esoteric, and there may be less argument. Any thoughts on this are welcome, but given the time of year, I'm not sure that it will be possible to sort out all the details so that the new units are incorporated into the master list by the time the modules are upgraded in a week or two. Johnuniq ( talk) 11:34, 28 December 2013 (UTC)
I have finally thought about GliderMaven's new units, and after a couple of minutes I came to the view that I could ponder it for a week and still think it was somewhat dubious but also potentially useful. On the principle that if a user wants to convert furlongs to DPI, who am I to stand in their way, I think the best thing is to just adopt GM's units without change. I have updated the sandbox with the units moved from "extra" to "data", and have put the necessary changes in the master list of units, and a couple of changes in makeunits to generate the new data. See the non-sandbox Module:Convert/extra for the original list list, and see the above examples. Some testcases are needed—I guess the examples will do, although I have not checked that the values are correct and am relying on GM for that. Johnuniq ( talk) 01:12, 4 January 2014 (UTC)
I have uploaded new versions of the sandbox modules for testing and comment. A convenient list of the modules is at the top of the documention seen when viewing Module:Convert/sandbox. Use {{ convert/sandbox}} to invoke the sandbox modules to try the new version. Depending on whether any problems are found or enhancements suggested, we could consider moving the main modules to the new version on, say, 6 January 2014.
New features:
{{convert/sandbox|12.3|e3km|e3mi+e6yd|abbr=off}}
→ 12.3 thousand kilometres (7.6 thousand miles; 13.5 million yards){{convert/sandbox|80|kg|lb stlb}}
→ 80 kilograms (180 lb; 12 st 8 lb)frac=N
specifies that fractions should be used for output values. Specifying frac=N
overrides other precision specifications such as |2
or |sigfig=3
or |disp=5
.
{{convert/sandbox|123|mm|in|frac=8}}
→ 123 millimetres (4+7⁄8 in){{convert/sandbox|18.45|in|m|frac=2}}
→ 18.45 inches (1⁄2 m){{convert/sandbox|18.45|in|ft in hand m|frac=2}}
→ 18.45 inches (1+1⁄2 ft; 18+1⁄2 in; 4.2+1⁄2
hands; 0.469 m){{convert/sandbox|18.45|in|ft in hand m|frac=2|1}}
→ 18.45 inches (1.5 ft; 18.5 in; 4.2+1⁄2
hands; 0.5 m)adj=ri0
specifies that the input value should be rounded to the nearest integer.
{{convert/sandbox|12.345|mi|km|disp=flip|adj=ri0|0}}
→ 20 kilometres (12 mi)round=5
rounds to the nearest multiple of 5 (same as disp=5
), and round=25
rounds to the nearest multiple of 25.
{{convert/sandbox|12.8|to|57|m|ft}}
→ 12.8 to 57 metres (42 to 187 ft){{convert/sandbox|12.8|to|57|m|ft|round=5}}
→ 12.8 to 57 metres (40 to 185 ft){{convert/sandbox|12.8|to|57|m|ft|round=25}}
→ 12.8 to 57 metres (50 to 175 ft)round=each
causes each conversion to use its own default precision. Sometimes round=each
(which is how the previous version behaved) is needed to avoid excess precision for some values, but usually the new default is better.
{{convert/sandbox|12.3|to|1400|mi|km}}
→ 12.3 to 1,400 miles (19.8 to 2,253.1 km){{convert/sandbox|12.3|to|1400|mi|km|round=each}}
→ 12.3 to 1,400 miles (19.8 to 2,300 km){{convert/sandbox|5000|–|5000.4|lb|kg}}
→ 5,000–5,000.4 pounds (2,268.0–2,268.1 kg){{convert/sandbox|5000|–|5000.4|lb|kg|round=each}}
→ 5,000–5,000.4 pounds (2,300–2,268.1 kg)abbr=off
; the hands value has at most one digit after the decimal mark, and has an optional fraction; specifying a precision of 2 or more causes the output to use frac=2
(half an inch).
{{convert/sandbox|27.749|in|hand}}
→ 27.749 inches (7.0
hands){{convert/sandbox|27.749|in|hand|0}}
→ 27.749 inches (7
hands){{convert/sandbox|27.749|in|hand|1}}
→ 27.749 inches (7.0
hands){{convert/sandbox|27.749|in|hand|2}}
→ 27.749 inches (6.3+1⁄2
hands){{convert/sandbox|27.749|in|hand|frac=4}}
→ 27.749 inches (6.3+3⁄4
hands){{convert/sandbox|156|cm|hand in|1|frac=2}}
→ 156 centimetres (15.1+1⁄2
hands; 61+1⁄2 in){{convert/sandbox|137|–|156|cm|handlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhand in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhandlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit)disp=table
or disp=tablecen
works with an output combination, and each output is placed in a new table cell.
{{convert/sandbox|300|PS|hp kW|0|disp=tablecen}}
gives wikitext:align="center"|300
|align="center"|296
|align="center"|221
×
" is an alias for "x
".
{{convert/sandbox|10|×|25|m}}
→ 10 by 25 metres (33 ft × 82 ft){{convert/sandbox|10|×|25|m|abbr=on}}
→ 10 m × 25 m (33 ft × 82 ft)I will finish some documentation for the new features in due course. These changes are rather massive, and I'm hoping any modifications needed in the next couple of months will be minor. Interestingly, frac=N
is used in a few articles, for example
Sebastian Bayer. It's an awkward time of year, but any feedback from testing would be appreciated.
Johnuniq (
talk)
09:48, 24 December 2013 (UTC)
I probably won't write more hands documentation for a while. Meanwhile, perhaps Justlettersandnumbers and Montanabw could use the above to experiment and see whether whether fixes are needed. Johnuniq ( talk) 10:30, 24 December 2013 (UTC)
{{convert/sandbox|123<ref>xyz3</ref>|m}}
→ 123
[3] metres (404 ft){{convert/sandbox|123<math>xyz4</math>|m}}
→
convert: invalid number{{convert/sandbox|123[[File:Help-browser.svg]]}}
→
convert: invalid number]
is "]").
[[Example|<span title="Value bad]] must be a number">invalid</span>]]
→
invalid<nowiki>...</nowiki>
tags, or a few others, then it's possible to remove them. But if you try and remove strip markers generated by <ref>...</ref>
tags, then you will end up with phantom references. The problem is that at the stage of processing that Lua is run, MediaWiki has already processed the tags once, so it is impossible to control the results of that first processing from Lua. In the case of ref tags, MediaWiki is going to stick the references wherever the next <references />
tag is whether you like it or not. :) The strip markers that Lua is passed in this case only control the superscript links to the references. So you can remove the superscript links, but you can't remove the references. And while most strip markers control fairly simple things like nowiki, gallery and ref tags, sometimes they might be pointing to much more complex things. (You'd have to ask a MediaWiki developer for more details on that last point.) So it's probably best not to try and mess with that at all. I would say that the best solution in this case is just to output an error message and a tracking category so that someone can fix the page and/or reconfigure whatever template passed the ref tags to {{
convert}}. —
Mr. Stradivarius
♪ talk ♪
11:10, 27 December 2013 (UTC)
I have updated the sandbox for the new fraction style. I decided to make the output exactly the same as that produced by {{
frac}} and {{
sfrac}} for now. That means that the module now outputs ⁄ instead of the Unicode character which a wikignome had put in the module, and that {{uc: {{convert|...with fractions...}} }}
will break (Wikid77 pointed out that the uppercase parser function outputs junk if given certain html entities as input).
Special:ExpandTemplates can be used to confirm that the output from the following matches the new style.
{{convert/sandbox|5/8|m|m|frac=8|abbr=on}}
→ 5⁄8 m (5⁄8 m){{convert/sandbox|12+5/8|m|m|frac=8|abbr=on}}
→ 12+5⁄8 m (12+5⁄8 m){{convert/sandbox|5//8|m|m|frac=-8|abbr=on}}
→ 5/8 m (5/8 m){{convert/sandbox|12+5//8|m|m|frac=-8|abbr=on}}
→ 12+5/8 m (12+5/8 m)Johnuniq ( talk) 10:09, 30 December 2013 (UTC)
handlk, hhandlk, hhand
for hand
Am I making sense? Hope so! All for now! Montanabw (talk) 22:41, 29 December 2013 (UTC)
{{convert/sandbox|137|–|156|cm|handlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhand in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhandlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit)|hand=link
or |hand=hh,link
or whatever. Or, unit "hand" could always link except if |lk=off
is used. Please write some examples of the wanted syntax for all wanted outputs. If anyone at WP:WPEQ might have an opinion, please notify the project (or, post the examples at the project and link to it from here).|lk=off
is used.{{convert/sandbox|137|–|156|cm|hands in}}
→ 137–156 centimetres (13.2–15.1
hands; 54–61 in) <--except this needs a link to hands, like this: 137–156 centimetres (13.2–15.1
hands; 54–61 in){{convert/sandbox|137|–|156|cm|hands in|abbr=h}}
→ 137–156 cm (13.2–15.1 h; 54–61 in)Am I making things clearer? Montanabw (talk) 06:25, 30 December 2013 (UTC)
|abbr=off
is used, output "
hands" for hands, and "inches" for inches.|abbr=out
or |abbr=h
is used, output "h" for hands (not linked), and "in" for inches.|abbr=hh
is used, output "hh" for hands (not linked), and "in" for inches.|lk=off
is used, no units would be linked.|lk=on
is used, each unit including inches would be linked.|adj=on
, the unit name will be "hand" (singular). I guess there is no problem with that, and you are just saying that the user should not be entering these values—a discussion we need not enter.
Johnuniq (
talk)
10:34, 30 December 2013 (UTC)Would Justlettersandnumbers and Montanabw please examine how the module handles hands—I think it's doing what was asked, but I may have overlooked something.
See
Help:Convert units#Hands for documentation, and please check that the text and examples achieve what is wanted. One of the examples shows eighths of an inch. I know that is meaningless for a horse, however |frac=8
works with all units, including hands. Outputs from {{
convert}} and {{
hands}} are very similar; the latter provides some options that are not supported by convert, but those options do not appear to be used.
The following changes have occurred.
|abbr=h
shows "h" for hands; |abbr=hh
is similar but shows "hh".|lk=off
or |abbr=on
or |abbr=h
or |abbr=hh
.|2
) rounds a hands value to the nearest 1⁄2 inch, and a precision of 3 (|3
) rounds to the nearest 1⁄4 inch.Johnuniq ( talk) 06:46, 2 January 2014 (UTC)
OK, I think this covers it, but @ Justlettersandnumbers: if there is anything else needed:
That's all I can think of. Montanabw (talk) 08:33, 7 January 2014 (UTC)
Please compare:
The bad example makes a calculation out of the input. Outcomes may not always be clear (clearly wrong) to the editor.
I suggest a rule like: when entering a negative number with a fraction, both number parts must have a minus sign or a hyphen. (Exception possible: when the integer is 0). The current example should produce a "wrong number" like error message. - DePiep ( talk) 05:38, 29 December 2013 (UTC)
1+2/3
or -1-2/3
or 2/3
or -2/3
. But a program has to do something if weird input is entered, and as the template handled it in a logical manner (very impressively actually), I went to a fair bit of trouble to make the module do likewise. I suppose it could be changed so only the "proper" input is accepted, with others giving an error message. If you think the above is unusual, try this:
{{convert/old|1.23e+2+12/24|in|ftin}}
→ ![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
{{convert|1.23e+2+12/24|in|ftin}}
→
convert: invalid numberI am likelky just not seeing the right documentation but this particular rendering of: "...used in in the WWI era Wyoming-class battleships,[1] could only throw an 870 pounds (390 kg) shell 24,000 yards (21,946 m)..."(emphasis mine) from 12"/50_caliber_Mark_8_gun is particularly annoying. How do I get it to put pounds in singular? CombatWombat42 ( talk) 21:19, 8 January 2014 (UTC)
Now that {{
Convert}} is using a real language in its back-end, could the single-value and range-of-values be consolidated? That is, Instead of having to say {{
convert|60|-|170|kg|lb}}
, it seems like the module could recognize that the first parameter of {{
convert|60-170|kg|lb}}
looks like a range and handle it accordingly. This would make it easier to handle infoboxes that have a numerical field that the infobox then converts, for example, {{
chembox}} melting points. Currently, there need to be separate fields for the two ends of the range, and also template logic to decide if {{
convert}} should be called in the one-value or range-of-values way. Having it all in a single field take a single value or range is more natural for editors, and having the choice of modes handled in lua is surely no less efficient than in template-language.
DMacks (
talk)
02:52, 7 January 2014 (UTC)
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
Urania (mentioned above) must be hard at work because only 20 extra lines were required to do the following.
{{convert/sandbox|1-2|ft|in}}
→ 1–2 feet (12–24 in){{convert/sandbox|1 to 2|ft|in}}
→ 1 to 2 feet (12 to 24 in){{convert/sandbox|1 to(-) 2|ft|in}}
→ 1 to 2 feet (12–24 in){{convert/sandbox|1 or 2|ft|in}}
→ 1 or 2 feet (12 or 24 in){{convert/sandbox|1 +/- 2|ft|in}}
→ 1 ± 2 feet (12 ± 24 in){{convert/sandbox|1 by 2|ft|in}}
→ 1 by 2 feet (12 by 24 in){{convert/sandbox|1 x 2|ft|in}}
→ 1 by 2 feet (12 in × 24 in){{convert/sandbox|1 xx 2|ft|in}}
→ 1 × 2 feet (12 × 24 in){{convert/sandbox|1*2|ft|in}}
→ 1×2 feet (12×24 in){{convert/sandbox|1*2 to 3*4|ft|in}}
→ 1×2 to 3×4 feet (12×24 to 36×48 in){{convert/sandbox|-1-2/3|ft|in}}
→ −1+2⁄3 feet (−20 in)The last line shows that a negative fraction is still recognized. However, negative fractions cannot be used in a "simplified range" ({{convert/sandbox|-1-2/3-4|ft|in}}
does nothing useful).
Spaces are ignored, so "1 - 2
" is the same as "1-2
", and "1to2
" is the same as "1 to 2
". The range words can also be mixed up in weird ways: |1*2to3*4|
and |1*2|to|3*4|
do the same thing (I'm reporting what the code does, not making recommendations!).
While Wikid77 makes a valid point, I have thought that ranges should be easier to enter, and while "1-2" is evaluated as an expression by the old template, it is currently an "invalid number" error in the module, so it is already incompatibile.
@ DMacks: Please test using {convert/sandbox} and let me know if it does what is needed. The changes will be live in {convert} when the module is updated from the sandbox in about a week. Johnuniq ( talk) 03:59, 8 January 2014 (UTC)
{{
convert/sandbox|8|°C|°F}}
→ 8 °C (46 °F){{
convert/sandbox|-8|°C|°F}}
→ −8 °C (18 °F){{
convert/sandbox|8-10|°C|°F}}
→ 8–10 °C (46–50 °F){{
convert/sandbox|-8-10|°C|°F}}
→ −8–10 °C (18–50 °F){{
convert/sandbox|10--8|°C|°F}}
→ 10 – −8 °C (50–18 °F){{
convert/sandbox|-8--6|°C|°F}}
→ −8 – −6 °C (18–21 °F){{
convert/sandbox|-6--8|°C|°F}}
→ −6 – −8 °C (21–18 °F)I intend switching the module to use the sandbox version on 17 January 2014.
The changes may take weeks to become apparent as the job queue slowly grinds away (it is now 1,900,000, and an announcement at WP:VPT indicates that it may be particularly slow due to indexing for a new search engine), but please be alert to the fact that the new convert will be in action, and report any problems.
See
#Module version 2 above for a list of many enhancements. Also included is the change in the way fractions (12+3⁄4) are formatted, use of "inverse units", new units from
Module:Convert/extra, automatic detection of a range ({{convert|1-2|ft}}
is the same as {{convert|1|-|2|ft}}
), and various code tweaks. Finally, the most important change is a fix for the
bug mentioned above which I have recently found is breaking some tables that use |disp=table
with an output combination unit (the module currently puts all of the outputs in a single cell, whereas the fixed sandbox puts each individual output in a separate cell). I had hoped to do more work on the range rounding issue raised by Wikid77; the sandbox convert is doing better in that respect, but there are some corner cases that do not work well, although I have not seen any examples in articles that are a problem. However, that will have to wait for later.
GliderMaven and I are discussing some new units above, and if they stabilize in the next 24 hours I will include them in the main data. Johnuniq ( talk) 01:08, 14 January 2014 (UTC)
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
A recent edit at
List of civilian nuclear accidents added {{convert|1.015|Sv|abbr=on}}
, but Sv (
sievert) is not known to convert. Perhaps
SkoreKeep (who added the convert), or
GliderMaven (who recently worked on some exotic units), or anyone, would like to recommend how convert should handle this unit. Is it likely to be used more often, and so should be supported? What default output should it have, etc. It looks like Sv works with rem, and nothing else? So a new unit type would be needed ("radiation dose"—becquerel and curie are called "radioactivity")? In case anyone is wondering, issues like this appear in the error tracking categories
Category:Convert invalid units and
Category:Convert invalid options.
Johnuniq (
talk)
06:53, 9 January 2014 (UTC)
Another approach to preparing new units would be to have a sandbox unit definitions page somewhere, then use makeunits. I have put a demo of that at User:Johnuniq/sandbox2. Using this method, it is necessary to become familiar with the rules for filling in the table to define a unit, but simple cases are very simple. The results can then be copied from User talk:Johnuniq/sandbox2 and pasted into Module:Convert/extra. Later I'll ponder where that page could live, and how it might be documented—the rules mentioned are complex when all details are needed; they are at the top of the master list of units (see link at top of sandbox). Johnuniq ( talk) 02:06, 10 January 2014 (UTC)
@GliderMaven: I'm responding down here because it's a bit easier. Re Module:Convert/extra: The link for rem should be Roentgen equivalent man, and the names for Sievert and Gray should be all lowercase (consider "millisievert"). Convert does not recognize Gy as gigayear, therefore Gy could be the unit code for gray, although using "gray" might reduce editor confusion. I don't see why it should be "Gray". OTOH, using mGy as a unitcode might be better than mgray, so perhaps the unit code should be "Gy".
Each of the following new units is defined as working with an SI prefix: Sievert, rem, Gray, rad, A/m, Oersted. I would need to ponder that because while it is convenient that SI prefixes can be used, I'm not sure it is useful to refer, for example, to millioesteds (symbol mOe) or kilorem (symbol krem). Surely SI prefixes should only be enabled on SI units where the symbols are standard? The exceptions (like mrem) probably need to be handled as separate units—that's what is done for µin. Perhaps some enhancement for making an alias with an SI prefix could be considered, if there are many units like that, but so far I'm only aware of microinch.
I have put my interpretations in Template:Convert/unit sandbox (keeping the SI prefixes for now); the results are at Template talk:Convert/unit sandbox.
There is an observation above that it would be more convenient if {{convert|10|Sv}}
gave "10 Sv" rather than "10 sieverts"—that is, abbr=on should be the default. I can see the logic of that for the new units, but it would be incompatible with the way that convert has worked for years where, for example {{convert|10|m}}
shows "10 metres" by default. The problem is that the new units are almost always used in a scientific context where abbr=on makes more sense. Perhaps some future enhancement could allow a unit to be defined as defaulting to abbr=on, but that would require a fair bit of thought.
Johnuniq (
talk)
11:18, 12 January 2014 (UTC)
I had forgotten that gauss and tesla were added three months ago, each as "magnetic field strength". The two related units with a different unit type are: A/m and Oe, each as "magnetizing field". Should we rethink the unit types? The traditional names would be "magnetic flux density" for gauss + tesla, and "magnetic field strength" for A/m and Oe. It is not iimportant because the names are rarely seen, but why not use the traditional names? Johnuniq ( talk) 00:59, 14 January 2014 (UTC)
I would like to know whether is possible to combine disp=or and disp=flip in any way, for example:
{{convert|24|in|cm|abbr=on|disp=flip|disp=or}}
24 in or 61 cm
*
{{convert|24|in|cm|abbr=on|disp=or|disp=flip}}
61 cm (24 in)
*
Expected result would be:
61 cm or 24 in
Thanks in advance.-- Carnby ( talk) 20:20, 13 January 2014 (UTC)
|adj=flip
":
{{convert|24|in|cm|abbr=on|adj=flip|disp=or}}
→ 24 in or 61 cm
*|disp=flip|disp=or
" to work because the underlying software simply accumulates the parameters, and the second occurrence of disp
overwrites the first. That happens before Template:Convert is called.
Johnuniq (
talk)
21:12, 13 January 2014 (UTC)
The solution is to define another parameter (let's call it order
) to control flipping (and possibly reordering in general). Using the disp
parameter for this never was satisfactory but was the simplest solution at the time due to the difficulty in adding new parameters (a difficulty we can now forget with the third incarnation of {{convert}}).
Jimp
09:51, 20 January 2014 (UTC)
Just seeking a wider range of input from informed persons at Template_talk:Height#rfc_97AACED.-- Gibson Flying V ( talk) 01:14, 23 January 2014 (UTC)
Among the numerous bugs which had to be fixed in {convert/old}, the non-numeric default result for 2 metres (any < 3) when "disp=number" has been a problem, as giving "6 ft 7 in" rather than number "6.6" (feet):
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
The fix for {convert/old} is ready as "m/sandbox" unit-code:
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
When "disp=number" is needed for converting metres below 3, then the 2nd unit ("ft") has had be specified to get a numeric result. - Wikid77 ( talk) 13:30/ 16:01, 23 January 2014 (UTC)
As many people are now aware, this massive delay in Convert updates is a substantial culture shock, and so I had recommended having an advance release as {convert/+} to indicate "plus new features". As a software developer and proponent of eXtreme Programming, I have planned configuration management strategies for many years, to deploy new features quickly, with minimal regression testing, by keeping smaller "configuration forks" isolated to a subset of the total use-cases. But at least the consolidation done with Lua Convert shows how the former 5-minute updates to various subtemplates had to be lengthened into multi-week reformatting, combined with 3-week release planning, combined with more multi-week reformatting, to extend as perhaps a 63-day update cycle, or 18,000x times slower than a wiki-style update with a 5-minute fix of subtemplates (60/5×24×63 = 18,144). Plus a subtemplate update was quickly reversible if the result was not better. Fortunately, since 2007, we had 6 years to quickly deploy new features for Convert, by adding various combinations of tiny subtemplates, and now we have reached the stage where major, quick advancements can be made with wp:wrapper templates, no longer needing to create hundreds of option-fork subtemplates. However, the underlying Lua Convert still needs some improvements and a few new features, and so the use of a {convert/+} advance-version release will allow for rapid improvements, restricted mainly by the limited regression testing of prior pages which used {convert/+}. The current cascade-protection lock-out, caused by Convert being used in subpages of " Main Page", is another major reason why {convert/+} should be used in cases where new features are needed sooner. Previously, people had come to expect the rapid "miracle" updates to Convert, and it will take a while to get accustomed to talk-page topics being archived weeks before the fix is actually deployed 18,000x times slower, among the 554,000 pages which use Convert. - Wikid77 ( talk) 16:37, 22 January 2014 (UTC)
I confirmed that the example you give {{convert|60|x|120|m|ft}} provides "60 by 120 metres (200 ft × 390 ft)". Should is say "60 metres by 120 metres (200 ft × 390 ft)"? Or even just "60 metres × 120 metres (200 ft × 390 ft)"? Maybe saying metres twice is considered awkward language but isn't is right scientifically and if not considered important should ft be once for consistency? Is it possible to get the the last version (without two convert templates)? If metres is to long if really should be "m"?
For the three dimensional example, {{convert/3 |2|x|4|x|6|m|ft}} provides "2×4×6 metres (6.6×13×20 ft)" but should give "2 m × 4 m × 6 m (6.6 ft × 13 ft × 20 ft)". Note the space before and after "×" and m not metres.
Is it too late to change and make consistent (in either direction)? For let's say smartphone dimensions what would you do? comp.arch ( talk) 15:50, 15 January 2014 (UTC)
{{convert}}
instead of {{convert/3}}
unless it's some more exotic use-case. however, I do see what you are saying about the differences in presentation between the 2 unit and 3 unit conversions for cases 2a and 2b.
Frietjes (
talk)
16:06, 15 January 2014 (UTC)I never was keen on abbr=mos
, disp=mos
, etc. The MOS isn't expected to flip willy-nilly this way and that and when it does it more of an indication that something is going wrong over there (it happens). I'd prefer we stick with the guidelines, if there weren't meant to be followed, they might as well be deleted. At the very least we should not be defaulting to ignore all rules. If there is a valid reason for the template to disregard to guidelines in this or that particular case, perhaps we can have some way of doing so but the default should be to follow the MOS. MOS suggests repeating the unit with "×" out of respect for what the mathematical symbol actually means. If the MOS has got it wrong, bring it up at WT:MOSNUM; we oughtn't just do as we please without regard to the guideline which was arrived at by consensus.
Jimp
09:44, 20 January 2014 (UTC)
Where in the list is the quantity time? And the possible conversions from seconds, to minutes, hours, weeks, months, years, like e.g. in /info/en/?search=List_of_radioactive_isotopes_by_half-life ? Jgamleus ( talk) 14:29, 30 January 2014 (UTC)
{{convert|1.13|e6year|e12s|abbr=off}}
→ 1.13 million years (36 trillion seconds){{convert|1.13|e6year|e12s|abbr=on}}
→ 1.13×10 6 a (36×10 12 s){{convert|1.13|e6years|e12s|abbr=on}}
→ 1.13×10 6 yr (36×10 12 s)![]() | 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. |
As discussed at #DPI and dots/cm and micrometres per dot, GliderMaven added some units to Module:Convert/extra that have an "invert" property, and proposed a change to the module's convert routine. I have implemented that change in the sandbox, and have tweaked the extra units (see Module:Convert/sandbox and Module:Convert/extra/sandbox). Please carefully check the changes and let me know if anything has gone wrong.
For units pitch and dpcm I simplified the link from Dots per inch#Proposed metrication to Dots per inch because the latter is adequate, and the former will become obsolete when someone changes the section heading, and the topic is not sufficiently important to warrant an anchor with the rather dated text of "Proposed metrication".
In some of the scales, I changed 9.8066 to 9.80665 because the latter is the value used by other units referring to g, and they may as well be consistent even if the extra precision is meaningless.
I omitted the "invert = 1" fields because they are not needed as the module assumes that value if converting with a unit with "invert = -1" and "iscomplex= true", and "invert = 1" is not needed when converting with other kinds of units. Eventually the new units need to be added to the master list, but that cannot happen until I have updated makeunits to handle these units. I'm thinking that putting "invert" in the "Extra" column will cause makeunits to set "invert = -1" and "iscomplex= true", and that might be the only change needed.
The pitch unit has a default output of dpi, but it also has symbol µm, and that conflicts with the default exception for µm. As a result, pitch has a default output unit of inches.
Following are the converts provided as examples by GliderMaven, using the sandbox modules.
{{convert/sandbox|10|dpi}}
→ 10 DPI (2,500 μm){{convert/sandbox|100|dpi|pitch}}
→ 100 DPI (250 μm){{convert/sandbox|100|dpi|dpcm}}
→ 100 DPI (39 dot/cm){{convert/sandbox|100|dpi|m}}
→ 100 DPI (0.00025 m){{convert/sandbox|100|dpi|mm}}
→ 100 DPI (0.25 mm){{convert/sandbox|100|dpi|thou}}
→ 100 DPI (10 thou){{convert/sandbox|100|pitch}}
→ 100 μm (250 DPI){{convert/sandbox|350|isp}}
→ 350 seconds (3.4 km/s){{convert/sandbox|1.2|tsfc|isp}}
→ 1.2 lb/(lbf⋅h) (3,000 s){{convert/sandbox|0.71|tsfc|isp}}
→ 0.71 lb/(lbf⋅h) (5,100 s){{convert/sandbox|450|isp|ft/s}}
→ 450 seconds (14,000 ft/s){{convert/sandbox|33|tsfc|km/s}}
→ 33 lb/(lbf⋅h) (1.1 km/s){{convert/sandbox|33|km/s|tsfc}}
→ 33 kilometres per second (1.1 lb/(lbf⋅h))We will need to discuss the unit types again because I still think that converting, say, DPI to furlongs is undesirable. Actually, converting DPI to inches is pretty bizarre. The alternative would be to use a unit type like "dotlength" and provide whitelisted exceptions that allow some units of type length to be converted to/from dotlength. A similar consideration applies to the other new units, although they are much more esoteric, and there may be less argument. Any thoughts on this are welcome, but given the time of year, I'm not sure that it will be possible to sort out all the details so that the new units are incorporated into the master list by the time the modules are upgraded in a week or two. Johnuniq ( talk) 11:34, 28 December 2013 (UTC)
I have finally thought about GliderMaven's new units, and after a couple of minutes I came to the view that I could ponder it for a week and still think it was somewhat dubious but also potentially useful. On the principle that if a user wants to convert furlongs to DPI, who am I to stand in their way, I think the best thing is to just adopt GM's units without change. I have updated the sandbox with the units moved from "extra" to "data", and have put the necessary changes in the master list of units, and a couple of changes in makeunits to generate the new data. See the non-sandbox Module:Convert/extra for the original list list, and see the above examples. Some testcases are needed—I guess the examples will do, although I have not checked that the values are correct and am relying on GM for that. Johnuniq ( talk) 01:12, 4 January 2014 (UTC)
I have uploaded new versions of the sandbox modules for testing and comment. A convenient list of the modules is at the top of the documention seen when viewing Module:Convert/sandbox. Use {{ convert/sandbox}} to invoke the sandbox modules to try the new version. Depending on whether any problems are found or enhancements suggested, we could consider moving the main modules to the new version on, say, 6 January 2014.
New features:
{{convert/sandbox|12.3|e3km|e3mi+e6yd|abbr=off}}
→ 12.3 thousand kilometres (7.6 thousand miles; 13.5 million yards){{convert/sandbox|80|kg|lb stlb}}
→ 80 kilograms (180 lb; 12 st 8 lb)frac=N
specifies that fractions should be used for output values. Specifying frac=N
overrides other precision specifications such as |2
or |sigfig=3
or |disp=5
.
{{convert/sandbox|123|mm|in|frac=8}}
→ 123 millimetres (4+7⁄8 in){{convert/sandbox|18.45|in|m|frac=2}}
→ 18.45 inches (1⁄2 m){{convert/sandbox|18.45|in|ft in hand m|frac=2}}
→ 18.45 inches (1+1⁄2 ft; 18+1⁄2 in; 4.2+1⁄2
hands; 0.469 m){{convert/sandbox|18.45|in|ft in hand m|frac=2|1}}
→ 18.45 inches (1.5 ft; 18.5 in; 4.2+1⁄2
hands; 0.5 m)adj=ri0
specifies that the input value should be rounded to the nearest integer.
{{convert/sandbox|12.345|mi|km|disp=flip|adj=ri0|0}}
→ 20 kilometres (12 mi)round=5
rounds to the nearest multiple of 5 (same as disp=5
), and round=25
rounds to the nearest multiple of 25.
{{convert/sandbox|12.8|to|57|m|ft}}
→ 12.8 to 57 metres (42 to 187 ft){{convert/sandbox|12.8|to|57|m|ft|round=5}}
→ 12.8 to 57 metres (40 to 185 ft){{convert/sandbox|12.8|to|57|m|ft|round=25}}
→ 12.8 to 57 metres (50 to 175 ft)round=each
causes each conversion to use its own default precision. Sometimes round=each
(which is how the previous version behaved) is needed to avoid excess precision for some values, but usually the new default is better.
{{convert/sandbox|12.3|to|1400|mi|km}}
→ 12.3 to 1,400 miles (19.8 to 2,253.1 km){{convert/sandbox|12.3|to|1400|mi|km|round=each}}
→ 12.3 to 1,400 miles (19.8 to 2,300 km){{convert/sandbox|5000|–|5000.4|lb|kg}}
→ 5,000–5,000.4 pounds (2,268.0–2,268.1 kg){{convert/sandbox|5000|–|5000.4|lb|kg|round=each}}
→ 5,000–5,000.4 pounds (2,300–2,268.1 kg)abbr=off
; the hands value has at most one digit after the decimal mark, and has an optional fraction; specifying a precision of 2 or more causes the output to use frac=2
(half an inch).
{{convert/sandbox|27.749|in|hand}}
→ 27.749 inches (7.0
hands){{convert/sandbox|27.749|in|hand|0}}
→ 27.749 inches (7
hands){{convert/sandbox|27.749|in|hand|1}}
→ 27.749 inches (7.0
hands){{convert/sandbox|27.749|in|hand|2}}
→ 27.749 inches (6.3+1⁄2
hands){{convert/sandbox|27.749|in|hand|frac=4}}
→ 27.749 inches (6.3+3⁄4
hands){{convert/sandbox|156|cm|hand in|1|frac=2}}
→ 156 centimetres (15.1+1⁄2
hands; 61+1⁄2 in){{convert/sandbox|137|–|156|cm|handlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhand in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhandlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit)disp=table
or disp=tablecen
works with an output combination, and each output is placed in a new table cell.
{{convert/sandbox|300|PS|hp kW|0|disp=tablecen}}
gives wikitext:align="center"|300
|align="center"|296
|align="center"|221
×
" is an alias for "x
".
{{convert/sandbox|10|×|25|m}}
→ 10 by 25 metres (33 ft × 82 ft){{convert/sandbox|10|×|25|m|abbr=on}}
→ 10 m × 25 m (33 ft × 82 ft)I will finish some documentation for the new features in due course. These changes are rather massive, and I'm hoping any modifications needed in the next couple of months will be minor. Interestingly, frac=N
is used in a few articles, for example
Sebastian Bayer. It's an awkward time of year, but any feedback from testing would be appreciated.
Johnuniq (
talk)
09:48, 24 December 2013 (UTC)
I probably won't write more hands documentation for a while. Meanwhile, perhaps Justlettersandnumbers and Montanabw could use the above to experiment and see whether whether fixes are needed. Johnuniq ( talk) 10:30, 24 December 2013 (UTC)
{{convert/sandbox|123<ref>xyz3</ref>|m}}
→ 123
[3] metres (404 ft){{convert/sandbox|123<math>xyz4</math>|m}}
→
convert: invalid number{{convert/sandbox|123[[File:Help-browser.svg]]}}
→
convert: invalid number]
is "]").
[[Example|<span title="Value bad]] must be a number">invalid</span>]]
→
invalid<nowiki>...</nowiki>
tags, or a few others, then it's possible to remove them. But if you try and remove strip markers generated by <ref>...</ref>
tags, then you will end up with phantom references. The problem is that at the stage of processing that Lua is run, MediaWiki has already processed the tags once, so it is impossible to control the results of that first processing from Lua. In the case of ref tags, MediaWiki is going to stick the references wherever the next <references />
tag is whether you like it or not. :) The strip markers that Lua is passed in this case only control the superscript links to the references. So you can remove the superscript links, but you can't remove the references. And while most strip markers control fairly simple things like nowiki, gallery and ref tags, sometimes they might be pointing to much more complex things. (You'd have to ask a MediaWiki developer for more details on that last point.) So it's probably best not to try and mess with that at all. I would say that the best solution in this case is just to output an error message and a tracking category so that someone can fix the page and/or reconfigure whatever template passed the ref tags to {{
convert}}. —
Mr. Stradivarius
♪ talk ♪
11:10, 27 December 2013 (UTC)
I have updated the sandbox for the new fraction style. I decided to make the output exactly the same as that produced by {{
frac}} and {{
sfrac}} for now. That means that the module now outputs ⁄ instead of the Unicode character which a wikignome had put in the module, and that {{uc: {{convert|...with fractions...}} }}
will break (Wikid77 pointed out that the uppercase parser function outputs junk if given certain html entities as input).
Special:ExpandTemplates can be used to confirm that the output from the following matches the new style.
{{convert/sandbox|5/8|m|m|frac=8|abbr=on}}
→ 5⁄8 m (5⁄8 m){{convert/sandbox|12+5/8|m|m|frac=8|abbr=on}}
→ 12+5⁄8 m (12+5⁄8 m){{convert/sandbox|5//8|m|m|frac=-8|abbr=on}}
→ 5/8 m (5/8 m){{convert/sandbox|12+5//8|m|m|frac=-8|abbr=on}}
→ 12+5/8 m (12+5/8 m)Johnuniq ( talk) 10:09, 30 December 2013 (UTC)
handlk, hhandlk, hhand
for hand
Am I making sense? Hope so! All for now! Montanabw (talk) 22:41, 29 December 2013 (UTC)
{{convert/sandbox|137|–|156|cm|handlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhand in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit){{convert/sandbox|137|–|156|cm|hhandlk in|abbr=on|1}}
→ 137–156 cm (
convert: unknown unit)|hand=link
or |hand=hh,link
or whatever. Or, unit "hand" could always link except if |lk=off
is used. Please write some examples of the wanted syntax for all wanted outputs. If anyone at WP:WPEQ might have an opinion, please notify the project (or, post the examples at the project and link to it from here).|lk=off
is used.{{convert/sandbox|137|–|156|cm|hands in}}
→ 137–156 centimetres (13.2–15.1
hands; 54–61 in) <--except this needs a link to hands, like this: 137–156 centimetres (13.2–15.1
hands; 54–61 in){{convert/sandbox|137|–|156|cm|hands in|abbr=h}}
→ 137–156 cm (13.2–15.1 h; 54–61 in)Am I making things clearer? Montanabw (talk) 06:25, 30 December 2013 (UTC)
|abbr=off
is used, output "
hands" for hands, and "inches" for inches.|abbr=out
or |abbr=h
is used, output "h" for hands (not linked), and "in" for inches.|abbr=hh
is used, output "hh" for hands (not linked), and "in" for inches.|lk=off
is used, no units would be linked.|lk=on
is used, each unit including inches would be linked.|adj=on
, the unit name will be "hand" (singular). I guess there is no problem with that, and you are just saying that the user should not be entering these values—a discussion we need not enter.
Johnuniq (
talk)
10:34, 30 December 2013 (UTC)Would Justlettersandnumbers and Montanabw please examine how the module handles hands—I think it's doing what was asked, but I may have overlooked something.
See
Help:Convert units#Hands for documentation, and please check that the text and examples achieve what is wanted. One of the examples shows eighths of an inch. I know that is meaningless for a horse, however |frac=8
works with all units, including hands. Outputs from {{
convert}} and {{
hands}} are very similar; the latter provides some options that are not supported by convert, but those options do not appear to be used.
The following changes have occurred.
|abbr=h
shows "h" for hands; |abbr=hh
is similar but shows "hh".|lk=off
or |abbr=on
or |abbr=h
or |abbr=hh
.|2
) rounds a hands value to the nearest 1⁄2 inch, and a precision of 3 (|3
) rounds to the nearest 1⁄4 inch.Johnuniq ( talk) 06:46, 2 January 2014 (UTC)
OK, I think this covers it, but @ Justlettersandnumbers: if there is anything else needed:
That's all I can think of. Montanabw (talk) 08:33, 7 January 2014 (UTC)
Please compare:
The bad example makes a calculation out of the input. Outcomes may not always be clear (clearly wrong) to the editor.
I suggest a rule like: when entering a negative number with a fraction, both number parts must have a minus sign or a hyphen. (Exception possible: when the integer is 0). The current example should produce a "wrong number" like error message. - DePiep ( talk) 05:38, 29 December 2013 (UTC)
1+2/3
or -1-2/3
or 2/3
or -2/3
. But a program has to do something if weird input is entered, and as the template handled it in a logical manner (very impressively actually), I went to a fair bit of trouble to make the module do likewise. I suppose it could be changed so only the "proper" input is accepted, with others giving an error message. If you think the above is unusual, try this:
{{convert/old|1.23e+2+12/24|in|ftin}}
→ ![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
{{convert|1.23e+2+12/24|in|ftin}}
→
convert: invalid numberI am likelky just not seeing the right documentation but this particular rendering of: "...used in in the WWI era Wyoming-class battleships,[1] could only throw an 870 pounds (390 kg) shell 24,000 yards (21,946 m)..."(emphasis mine) from 12"/50_caliber_Mark_8_gun is particularly annoying. How do I get it to put pounds in singular? CombatWombat42 ( talk) 21:19, 8 January 2014 (UTC)
Now that {{
Convert}} is using a real language in its back-end, could the single-value and range-of-values be consolidated? That is, Instead of having to say {{
convert|60|-|170|kg|lb}}
, it seems like the module could recognize that the first parameter of {{
convert|60-170|kg|lb}}
looks like a range and handle it accordingly. This would make it easier to handle infoboxes that have a numerical field that the infobox then converts, for example, {{
chembox}} melting points. Currently, there need to be separate fields for the two ends of the range, and also template logic to decide if {{
convert}} should be called in the one-value or range-of-values way. Having it all in a single field take a single value or range is more natural for editors, and having the choice of modes handled in lua is surely no less efficient than in template-language.
DMacks (
talk)
02:52, 7 January 2014 (UTC)
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
Urania (mentioned above) must be hard at work because only 20 extra lines were required to do the following.
{{convert/sandbox|1-2|ft|in}}
→ 1–2 feet (12–24 in){{convert/sandbox|1 to 2|ft|in}}
→ 1 to 2 feet (12 to 24 in){{convert/sandbox|1 to(-) 2|ft|in}}
→ 1 to 2 feet (12–24 in){{convert/sandbox|1 or 2|ft|in}}
→ 1 or 2 feet (12 or 24 in){{convert/sandbox|1 +/- 2|ft|in}}
→ 1 ± 2 feet (12 ± 24 in){{convert/sandbox|1 by 2|ft|in}}
→ 1 by 2 feet (12 by 24 in){{convert/sandbox|1 x 2|ft|in}}
→ 1 by 2 feet (12 in × 24 in){{convert/sandbox|1 xx 2|ft|in}}
→ 1 × 2 feet (12 × 24 in){{convert/sandbox|1*2|ft|in}}
→ 1×2 feet (12×24 in){{convert/sandbox|1*2 to 3*4|ft|in}}
→ 1×2 to 3×4 feet (12×24 to 36×48 in){{convert/sandbox|-1-2/3|ft|in}}
→ −1+2⁄3 feet (−20 in)The last line shows that a negative fraction is still recognized. However, negative fractions cannot be used in a "simplified range" ({{convert/sandbox|-1-2/3-4|ft|in}}
does nothing useful).
Spaces are ignored, so "1 - 2
" is the same as "1-2
", and "1to2
" is the same as "1 to 2
". The range words can also be mixed up in weird ways: |1*2to3*4|
and |1*2|to|3*4|
do the same thing (I'm reporting what the code does, not making recommendations!).
While Wikid77 makes a valid point, I have thought that ranges should be easier to enter, and while "1-2" is evaluated as an expression by the old template, it is currently an "invalid number" error in the module, so it is already incompatibile.
@ DMacks: Please test using {convert/sandbox} and let me know if it does what is needed. The changes will be live in {convert} when the module is updated from the sandbox in about a week. Johnuniq ( talk) 03:59, 8 January 2014 (UTC)
{{
convert/sandbox|8|°C|°F}}
→ 8 °C (46 °F){{
convert/sandbox|-8|°C|°F}}
→ −8 °C (18 °F){{
convert/sandbox|8-10|°C|°F}}
→ 8–10 °C (46–50 °F){{
convert/sandbox|-8-10|°C|°F}}
→ −8–10 °C (18–50 °F){{
convert/sandbox|10--8|°C|°F}}
→ 10 – −8 °C (50–18 °F){{
convert/sandbox|-8--6|°C|°F}}
→ −8 – −6 °C (18–21 °F){{
convert/sandbox|-6--8|°C|°F}}
→ −6 – −8 °C (21–18 °F)I intend switching the module to use the sandbox version on 17 January 2014.
The changes may take weeks to become apparent as the job queue slowly grinds away (it is now 1,900,000, and an announcement at WP:VPT indicates that it may be particularly slow due to indexing for a new search engine), but please be alert to the fact that the new convert will be in action, and report any problems.
See
#Module version 2 above for a list of many enhancements. Also included is the change in the way fractions (12+3⁄4) are formatted, use of "inverse units", new units from
Module:Convert/extra, automatic detection of a range ({{convert|1-2|ft}}
is the same as {{convert|1|-|2|ft}}
), and various code tweaks. Finally, the most important change is a fix for the
bug mentioned above which I have recently found is breaking some tables that use |disp=table
with an output combination unit (the module currently puts all of the outputs in a single cell, whereas the fixed sandbox puts each individual output in a separate cell). I had hoped to do more work on the range rounding issue raised by Wikid77; the sandbox convert is doing better in that respect, but there are some corner cases that do not work well, although I have not seen any examples in articles that are a problem. However, that will have to wait for later.
GliderMaven and I are discussing some new units above, and if they stabilize in the next 24 hours I will include them in the main data. Johnuniq ( talk) 01:08, 14 January 2014 (UTC)
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
A recent edit at
List of civilian nuclear accidents added {{convert|1.015|Sv|abbr=on}}
, but Sv (
sievert) is not known to convert. Perhaps
SkoreKeep (who added the convert), or
GliderMaven (who recently worked on some exotic units), or anyone, would like to recommend how convert should handle this unit. Is it likely to be used more often, and so should be supported? What default output should it have, etc. It looks like Sv works with rem, and nothing else? So a new unit type would be needed ("radiation dose"—becquerel and curie are called "radioactivity")? In case anyone is wondering, issues like this appear in the error tracking categories
Category:Convert invalid units and
Category:Convert invalid options.
Johnuniq (
talk)
06:53, 9 January 2014 (UTC)
Another approach to preparing new units would be to have a sandbox unit definitions page somewhere, then use makeunits. I have put a demo of that at User:Johnuniq/sandbox2. Using this method, it is necessary to become familiar with the rules for filling in the table to define a unit, but simple cases are very simple. The results can then be copied from User talk:Johnuniq/sandbox2 and pasted into Module:Convert/extra. Later I'll ponder where that page could live, and how it might be documented—the rules mentioned are complex when all details are needed; they are at the top of the master list of units (see link at top of sandbox). Johnuniq ( talk) 02:06, 10 January 2014 (UTC)
@GliderMaven: I'm responding down here because it's a bit easier. Re Module:Convert/extra: The link for rem should be Roentgen equivalent man, and the names for Sievert and Gray should be all lowercase (consider "millisievert"). Convert does not recognize Gy as gigayear, therefore Gy could be the unit code for gray, although using "gray" might reduce editor confusion. I don't see why it should be "Gray". OTOH, using mGy as a unitcode might be better than mgray, so perhaps the unit code should be "Gy".
Each of the following new units is defined as working with an SI prefix: Sievert, rem, Gray, rad, A/m, Oersted. I would need to ponder that because while it is convenient that SI prefixes can be used, I'm not sure it is useful to refer, for example, to millioesteds (symbol mOe) or kilorem (symbol krem). Surely SI prefixes should only be enabled on SI units where the symbols are standard? The exceptions (like mrem) probably need to be handled as separate units—that's what is done for µin. Perhaps some enhancement for making an alias with an SI prefix could be considered, if there are many units like that, but so far I'm only aware of microinch.
I have put my interpretations in Template:Convert/unit sandbox (keeping the SI prefixes for now); the results are at Template talk:Convert/unit sandbox.
There is an observation above that it would be more convenient if {{convert|10|Sv}}
gave "10 Sv" rather than "10 sieverts"—that is, abbr=on should be the default. I can see the logic of that for the new units, but it would be incompatible with the way that convert has worked for years where, for example {{convert|10|m}}
shows "10 metres" by default. The problem is that the new units are almost always used in a scientific context where abbr=on makes more sense. Perhaps some future enhancement could allow a unit to be defined as defaulting to abbr=on, but that would require a fair bit of thought.
Johnuniq (
talk)
11:18, 12 January 2014 (UTC)
I had forgotten that gauss and tesla were added three months ago, each as "magnetic field strength". The two related units with a different unit type are: A/m and Oe, each as "magnetizing field". Should we rethink the unit types? The traditional names would be "magnetic flux density" for gauss + tesla, and "magnetic field strength" for A/m and Oe. It is not iimportant because the names are rarely seen, but why not use the traditional names? Johnuniq ( talk) 00:59, 14 January 2014 (UTC)
I would like to know whether is possible to combine disp=or and disp=flip in any way, for example:
{{convert|24|in|cm|abbr=on|disp=flip|disp=or}}
24 in or 61 cm
*
{{convert|24|in|cm|abbr=on|disp=or|disp=flip}}
61 cm (24 in)
*
Expected result would be:
61 cm or 24 in
Thanks in advance.-- Carnby ( talk) 20:20, 13 January 2014 (UTC)
|adj=flip
":
{{convert|24|in|cm|abbr=on|adj=flip|disp=or}}
→ 24 in or 61 cm
*|disp=flip|disp=or
" to work because the underlying software simply accumulates the parameters, and the second occurrence of disp
overwrites the first. That happens before Template:Convert is called.
Johnuniq (
talk)
21:12, 13 January 2014 (UTC)
The solution is to define another parameter (let's call it order
) to control flipping (and possibly reordering in general). Using the disp
parameter for this never was satisfactory but was the simplest solution at the time due to the difficulty in adding new parameters (a difficulty we can now forget with the third incarnation of {{convert}}).
Jimp
09:51, 20 January 2014 (UTC)
Just seeking a wider range of input from informed persons at Template_talk:Height#rfc_97AACED.-- Gibson Flying V ( talk) 01:14, 23 January 2014 (UTC)
Among the numerous bugs which had to be fixed in {convert/old}, the non-numeric default result for 2 metres (any < 3) when "disp=number" has been a problem, as giving "6 ft 7 in" rather than number "6.6" (feet):
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
The fix for {convert/old} is ready as "m/sandbox" unit-code:
![]() | This userpage has been blanked. If this is your userpage, you can retrieve the contents of this page in the page history. Alternatively, if you would like it deleted, simply replace the content of this page with {{db-u1}}. |
When "disp=number" is needed for converting metres below 3, then the 2nd unit ("ft") has had be specified to get a numeric result. - Wikid77 ( talk) 13:30/ 16:01, 23 January 2014 (UTC)
As many people are now aware, this massive delay in Convert updates is a substantial culture shock, and so I had recommended having an advance release as {convert/+} to indicate "plus new features". As a software developer and proponent of eXtreme Programming, I have planned configuration management strategies for many years, to deploy new features quickly, with minimal regression testing, by keeping smaller "configuration forks" isolated to a subset of the total use-cases. But at least the consolidation done with Lua Convert shows how the former 5-minute updates to various subtemplates had to be lengthened into multi-week reformatting, combined with 3-week release planning, combined with more multi-week reformatting, to extend as perhaps a 63-day update cycle, or 18,000x times slower than a wiki-style update with a 5-minute fix of subtemplates (60/5×24×63 = 18,144). Plus a subtemplate update was quickly reversible if the result was not better. Fortunately, since 2007, we had 6 years to quickly deploy new features for Convert, by adding various combinations of tiny subtemplates, and now we have reached the stage where major, quick advancements can be made with wp:wrapper templates, no longer needing to create hundreds of option-fork subtemplates. However, the underlying Lua Convert still needs some improvements and a few new features, and so the use of a {convert/+} advance-version release will allow for rapid improvements, restricted mainly by the limited regression testing of prior pages which used {convert/+}. The current cascade-protection lock-out, caused by Convert being used in subpages of " Main Page", is another major reason why {convert/+} should be used in cases where new features are needed sooner. Previously, people had come to expect the rapid "miracle" updates to Convert, and it will take a while to get accustomed to talk-page topics being archived weeks before the fix is actually deployed 18,000x times slower, among the 554,000 pages which use Convert. - Wikid77 ( talk) 16:37, 22 January 2014 (UTC)
I confirmed that the example you give {{convert|60|x|120|m|ft}} provides "60 by 120 metres (200 ft × 390 ft)". Should is say "60 metres by 120 metres (200 ft × 390 ft)"? Or even just "60 metres × 120 metres (200 ft × 390 ft)"? Maybe saying metres twice is considered awkward language but isn't is right scientifically and if not considered important should ft be once for consistency? Is it possible to get the the last version (without two convert templates)? If metres is to long if really should be "m"?
For the three dimensional example, {{convert/3 |2|x|4|x|6|m|ft}} provides "2×4×6 metres (6.6×13×20 ft)" but should give "2 m × 4 m × 6 m (6.6 ft × 13 ft × 20 ft)". Note the space before and after "×" and m not metres.
Is it too late to change and make consistent (in either direction)? For let's say smartphone dimensions what would you do? comp.arch ( talk) 15:50, 15 January 2014 (UTC)
{{convert}}
instead of {{convert/3}}
unless it's some more exotic use-case. however, I do see what you are saying about the differences in presentation between the 2 unit and 3 unit conversions for cases 2a and 2b.
Frietjes (
talk)
16:06, 15 January 2014 (UTC)I never was keen on abbr=mos
, disp=mos
, etc. The MOS isn't expected to flip willy-nilly this way and that and when it does it more of an indication that something is going wrong over there (it happens). I'd prefer we stick with the guidelines, if there weren't meant to be followed, they might as well be deleted. At the very least we should not be defaulting to ignore all rules. If there is a valid reason for the template to disregard to guidelines in this or that particular case, perhaps we can have some way of doing so but the default should be to follow the MOS. MOS suggests repeating the unit with "×" out of respect for what the mathematical symbol actually means. If the MOS has got it wrong, bring it up at WT:MOSNUM; we oughtn't just do as we please without regard to the guideline which was arrived at by consensus.
Jimp
09:44, 20 January 2014 (UTC)
Where in the list is the quantity time? And the possible conversions from seconds, to minutes, hours, weeks, months, years, like e.g. in /info/en/?search=List_of_radioactive_isotopes_by_half-life ? Jgamleus ( talk) 14:29, 30 January 2014 (UTC)
{{convert|1.13|e6year|e12s|abbr=off}}
→ 1.13 million years (36 trillion seconds){{convert|1.13|e6year|e12s|abbr=on}}
→ 1.13×10 6 a (36×10 12 s){{convert|1.13|e6years|e12s|abbr=on}}
→ 1.13×10 6 yr (36×10 12 s)