Template talk:Convert/Archive September 2017
 | This is an archive of past discussions about Template:Convert. 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. |
Flight Level
Sorry if this is a hardy perennial, but can Flight Level (100 feet) be added (or if there's a way to jigger the template into working in an non-SI prefix, please let me know). Pinkbeast (talk) 23:31, 28 August 2017 (UTC)
- Please spell out a rule for whatever is wanted. What is the input, and what is the wanted output? Also, please show some examples in articles where the text would benefit from the use of convert. Johnuniq (talk) 00:50, 29 August 2017 (UTC)
- The table in Time of useful consciousness is where I wanted to use it, and I imagine it would be beneficial in other aviation-related pages. Flight Level X corresponds to 100X feet, and I would hope to be able to write FL{{cvt|150|flightlevell|ft m}} or maybe {{cvt|150|flightlevell|ft m}} (I don't know if it's practical to handle a unit symbol that's prefixed to the number) to produce the output "FL150 (15,000 ft; 4,600 m)". Pinkbeast (talk) 10:26, 29 August 2017 (UTC)
- Does not look like a *new* conversion is needed. Just formatting. I created {{Flight level}}:
- {{Flight level|150}} → FL150 (15,000 ft; 4,550 m)
- -DePiep (talk) 11:24, 29 August 2017 (UTC)
- Very nice, thanks! Johnuniq (talk) 11:43, 29 August 2017 (UTC)
- I'm unsure about the utility of that conversion. Yes, it may be useful for the general reader to know that 18,000ft equates to 5,500m, but that has nothing to do with how Flight Levels are used - i.e. any ATC and any pilot will never need to know that. Thanks. Martinevans123 (talk) 13:23, 29 August 2017 (UTC)
- Hardly ever converted values are used by professionals. For example, would take a rounding and precision checking excercise. Here too. But alas, it gives our general reader an insight, esp when one is not familiar with feet-system. (Metric me, I just learned that there are actually paths of a delta FL005 (500 ft; 150 m) that are ~150 m! -DePiep (talk) 13:35, 29 August 2017 (UTC)
- I'm unsure about the utility of that conversion. Yes, it may be useful for the general reader to know that 18,000ft equates to 5,500m, but that has nothing to do with how Flight Levels are used - i.e. any ATC and any pilot will never need to know that. Thanks. Martinevans123 (talk) 13:23, 29 August 2017 (UTC)
- Very nice, thanks! Johnuniq (talk) 11:43, 29 August 2017 (UTC)
- Does not look like a *new* conversion is needed. Just formatting. I created {{Flight level}}:
- The table in Time of useful consciousness is where I wanted to use it, and I imagine it would be beneficial in other aviation-related pages. Flight Level X corresponds to 100X feet, and I would hope to be able to write FL{{cvt|150|flightlevell|ft m}} or maybe {{cvt|150|flightlevell|ft m}} (I don't know if it's practical to handle a unit symbol that's prefixed to the number) to produce the output "FL150 (15,000 ft; 4,600 m)". Pinkbeast (talk) 10:26, 29 August 2017 (UTC)
Thank you. I agree that pilots only work in Flight Levels as a rule, but we are writing for the general reader, who is unlikely to know what a flight level is. I certainly didn't. Pinkbeast (talk) 19:10, 29 August 2017 (UTC)
- Very useful to translate pilot jargon into everyman's units, thanks! — JFG talk 19:46, 29 August 2017 (UTC)
- Note: the meters are rounded to 50 m (not 100 as might be expected). The reason is: FL number is in steps of "5" (100, 105, 110), i.e, 500 ft (152.400 m). Since these steps are actually meaningful in aviation (they define separation layers), using and showing that 0–150–300 m range is meaninful compared with an unevenly rounded 0–200–300 m. See also the template testcases. Further development at {{Flight level}} I suggest. -DePiep (talk) 07:57, 30 August 2017 (UTC)
- The other gotcha (alas) is that arguably flight level is a range - aircraft A is at FL150 meaning 15,000 feet, but also with an expectation that FL150 is clear meaning some range 14xxx to 15xxx feet the size of which varies based on operational practice. I'm not sure what can be done about that. Pinkbeast (talk) 08:04, 30 August 2017 (UTC)
- So that's part of the FL definition, I understand. But it would be an extension of proimary "FL150" meaning, and so {{Flight level}} usage. If and when "FL150" should mean that range, the template could show that but only when coded (and additional parameters I guess). As said, template development over there. -DePiep (talk) 08:20, 30 August 2017 (UTC)
- The other gotcha (alas) is that arguably flight level is a range - aircraft A is at FL150 meaning 15,000 feet, but also with an expectation that FL150 is clear meaning some range 14xxx to 15xxx feet the size of which varies based on operational practice. I'm not sure what can be done about that. Pinkbeast (talk) 08:04, 30 August 2017 (UTC)
- Note: the meters are rounded to 50 m (not 100 as might be expected). The reason is: FL number is in steps of "5" (100, 105, 110), i.e, 500 ft (152.400 m). Since these steps are actually meaningful in aviation (they define separation layers), using and showing that 0–150–300 m range is meaninful compared with an unevenly rounded 0–200–300 m. See also the template testcases. Further development at {{Flight level}} I suggest. -DePiep (talk) 07:57, 30 August 2017 (UTC)
What bothers me about this is that Flight Level is not necessarily a linear distance above either sea level or the ground. The rules are complicated. Using a simple conversion for this is a bit misleading. Kendall-K1 (talk) 12:58, 4 September 2017 (UTC)
- Wrong place. Not a {{Convert}} issue. Discuss at Template talk:Flight level. -DePiep (talk) 21:04, 4 September 2017 (UTC)
- How is this the wrong place? I'm arguing that the convert template should not provide a conversion for flight level. Isn't this the right place to discuss proposed additions to the convert template? Kendall-K1 (talk) 13:00, 5 September 2017 (UTC)
- OP by Pinkbeast has been answered. Non-issue for {{Convert}} concluded. -DePiep (talk) 16:17, 5 September 2017 (UTC)
- How is this the wrong place? I'm arguing that the convert template should not provide a conversion for flight level. Isn't this the right place to discuss proposed additions to the convert template? Kendall-K1 (talk) 13:00, 5 September 2017 (UTC)
Spurious ♠ character in sortkey?
- The following has been moved from Module talk:Convert; see my second comment below. Johnuniq (talk) 02:49, 19 September 2017 (UTC)
Should the character ♠ really be inserted at the end of every sortkey on lines 2518-2519? I'm not familiar with Wikipedia's sorting by hidden keys, but after a glance at the information on the subject, I don't see any reason for it and it looks like perhaps a typo? I happened to notice it because the EmojiOne plugin for chrome detects this character and tries to render it as an SVG. Snoopjedi (talk) 00:19, 19 September 2017 (UTC)
- See Template talk:Val/Archive 5#Template:♥ where the first part discusses the heart symbol but the issue of the spade symbol was raised. Johnuniq (talk) 02:34, 19 September 2017 (UTC)
- On reflection, I think the question is not just curiosity. Are you saying that a browser displays junk when viewing an article using convert with sort? On the assumption that the answer is yes, I am moving this to here because it concerns what this template displays. A good place for input if there is a problem in articles is WP:VPT. However, if the problem concerns a particular plugin for a particular browser, the answer might be to get that plugin fixed because it should not be touching hidden text.
- Here are some examples:
{{convert|3.5|in|sortable=on}}→ 3.5 inches (89 mm){{convert|3.5|in|sortable=on|debug=yes}}→ 6998888999999999999♠3.5 inches (89 mm)
- The wikitext output by the first is
<span style="display:none" class="sortkey">6998888999999999999♠</span>3.5 inches (89 mm)- I'm busy elsewhere and will think about any responses later. Johnuniq (talk) 02:49, 19 September 2017 (UTC)
- I see! It looks like the use of the character is well-motivated, then. The issue does not happen with a "plain" browser, but is indeed a plugin touching some hidden text. I've opened an issue with the project, but because they do text->SVG replacement for objects that may be hidden at first and become unhidden later, I think it's not likely to get any attention (the only fix I can think of would be a domain-specific rule). Thanks for clearing up the rationale of this character, though! Snoopjedi (talk) 19:42, 19 September 2017 (UTC)
- I'm not familiar with HTML details but I would not think that a plugin should be displaying anything if it finds text inside a "display:none" span, see the above wikitext. However, that's up to them. Johnuniq (talk) 22:21, 19 September 2017 (UTC)
- I see! It looks like the use of the character is well-motivated, then. The issue does not happen with a "plain" browser, but is indeed a plugin touching some hidden text. I've opened an issue with the project, but because they do text->SVG replacement for objects that may be hidden at first and become unhidden later, I think it's not likely to get any attention (the only fix I can think of would be a domain-specific rule). Thanks for clearing up the rationale of this character, though! Snoopjedi (talk) 19:42, 19 September 2017 (UTC)
Troy weight
How to convert Troy weight to grams and ounces? Peter Horn User talk 01:45, 22 September 2017 (UTC)
- The unit codes are
oztandlbt.{{convert|100|ozt}}→ 100 troy ounces (110 oz; 3,100 g){{convert|100|ozt|abbr=on|lk=in}}→ 100 ozt (110 oz; 3,100 g){{convert|100|lbt}}→ 100 troy pounds (82 lb; 37 kg){{convert|100|lbt|abbr=on|lk=in}}→ 100 troy pounds (82 lb; 37 kg)
- Johnuniq (talk) 03:07, 22 September 2017 (UTC)
Volume as millions of m3 or Mm3
When editing page "Guajataca Lake" (the overtopped reservoir dam in Puerto Rico), the source says capacity "48.46 Mm3" which I think is intended as unit code "e6m3" but converts as astronomical zillions e19 or 1019 (quintillions?), so I'm planning to use "e6m3" in those conversions. Compare:
- {convert|48.46|Mm3 |cuyd |abbr=in} - 48.46 Mm3 (6.338×1019 cu yd)
- {convert|48.46|e6m3|e6cuyd |abbr=in} - 48.46×106 m3 (63.38 million cubic yards)
What unit symbol do scientists use for million cubic metres? I'm not familiar with volumes of lakes covering 2 sq mi (5.2 km2). -Wikid77 (talk) 06:04, 24 September 2017 (UTC)
- The capacity of lakes and dams is measured in megalitres or gigalitres. [1] There are 1,000 litres to the cubic metre, so 48.46 Mm3 is 48.46 Gl. I don't know what the Mm3 conversion is supposed to be, because it is undocumented, but it isn't millions of cubic metres (Mm3) (Looks like an error). Hawkeye7 (discuss) 06:19, 24 September 2017 (UTC)
- Hawkeye7 has answered what units should be used (I have no idea), but I can say that convert regards
Mm3asMmcubed. Examples usingkfor smaller numbers:{{convert|1.234|km|m|abbr=on}}→ 1.234 km (1,234 m){{convert|1.234|km2|m2|abbr=on}}→ 1.234 km2 (1,234,000 m2) (1 km2 is 1 km by 1 km){{convert|1.234|km3|m3|abbr=on}}→ 1.234 km3 (1.234×109 m3) (1 km3 is 1 km by 1 km by 1 km)
- Johnuniq (talk) 07:35, 24 September 2017 (UTC)
- Using 'Gl' to handle intended 'Mm3': So, in this case, the intended meaning of "Mm3" seems to be "million m3" instead of (Mm)^3, as if same as Gl:
- {convert|48.46|Gl|e6cuyd |abbr=in} —> 48.46 Gl (63.38 million cubic yards)
- Otherwise, the unit code "Mm3" converts as a quadrillion gigalitres:
- {convert|1|Mm3|e9Gl|abbr=in} —> 1 Mm3 (1,000 billion gigalitres)
- The intended value in the source document seems to be Mm3 as "e6m3". Thanks. Wikid77 (talk) 11:37, 24 September 2017 (UTC)
e9 units in a table - display only the figures
At List of lakes of Iceland one column of data is for the volume in gigalitres. The default conversion for this is to cubic feet, which results in large numbers
- {{convert|330|Gl}} → 330 gigalitres (1.2×1010 cu ft)
One way to get more human scale numbers is to use billions of cubic feet
- {{convert|330|Gl|e9cuft}} → 330 gigalitres (12×109 cu ft)
Not quite what I was after, so use abbr=unit to display "billions"
- {{convert|330|Gl|e9cuft|abbr=unit}} → 330 Gl (12 billion cu ft)
If we only want the numbers we can use "disp=number"
- {{convert|330|Gl|e9cuft|disp=number}} → 12×109
- {{convert|330|Gl|e9cuft|abbr=unit|disp=number}} → 12 billion
I was hoping for "12", but that's not really my point here as this doesn't work in a table as the disp parameter needs to be "table"
- {{convert|330|Gl|e9cuft|disp=table}}
Gigalitres Billion cu ft 330 12×109
- {{convert|330|Gl|e9cuft|abbr=unit|disp=table}}
Gigalitres Billion cu ft 330 Gl 12 billion cu ft
So is there way to get convert to output only the figures, without any words or units, when using e9cuft or other exponential units? Thryduulf (talk) 10:56, 24 September 2017 (UTC)
- I don't think there is a way—apart from defining a new unit, say gigcuft, which could be done if needed in a few articles (convert already defines Gcuft as equivalent to e9cuft). A cubic foot does not work well for that scale. I don't know what common usage is, but these alternatives are more manageable.
{{convert|330|Gl|cumi}}→ 330 gigalitres (0.079 cu mi){{convert|330|Gl|acre-ft}}→ 330 gigalitres (270,000 acre⋅ft){{convert|330|Gl|cuyd}}→ 330 gigalitres (430,000,000 cu yd)
- Johnuniq (talk) 12:00, 24 September 2017 (UTC)
- Thanks. I've got no idea what the common usage is either so in these situations I usually just go with whatever convert gives me as default. Thryduulf (talk) 12:06, 24 September 2017 (UTC)
- Wrap simple conversion in {first_word} or define new unit code 'Bcuft' for number: Since "12 billion" is not "12" then a new unit code (such as 'Bcuft') could be defined to show number as merely "12" in tables of disp=number, for unit symbol "billion cu ft". Meanwhile, the Template:First_word has been used for years to show the first word in a character string, as: {first word|12 billion} —> 12. However, using a new unit code 'Bcuft' (or similar) with unit name "billion cubic feet" seems like a clean, long-term solution, and was planned for old Convert (in pre-December 2013) to simplify display of word "billion" in related cases. -Wikid77 (talk) 12:21, 24 September 2017 (UTC)
Yes, I think Bcuft would be a better unit code. It's a bit of a kludge but I added it on a temporary basis to see if it is useful.
{{convert|1|Bcuft}}→ 1 billion cubic foot (28 Gl){{convert|1.234|Bcuft|abbr=on}}→ 1.234 billion cu ft (34.9 Gl)
{{convert|330|Gl|Bcuft|disp=table}}
| Gigalitres | Billion cu ft |
|---|---|
| 330 | 12 |
@Thryduulf: Please try the above. Johnuniq (talk) 22:57, 24 September 2017 (UTC)
- @Johnuniq: Thanks, I've now made the change at List of lakes of Iceland so it's using Bcuft, and it looks (to me at least) much cleaner - cuft Bcuft. Thryduulf (talk) 23:10, 24 September 2017 (UTC)
annotation before the value in tables
At List of lakes of Switzerland#Main list there is a large table of values, a handfull of which are not exact and so are marked with "<" before the value (e.g. max depth for Alte Aare, ranked 67 - see also an excerpt from the table in my sandbox) but this doesn't really work with the convert template - anything not part of the template is ignored other than to change the alignment of the input cell from right to left.
{|class="wikitable sortable"
!Name
!metres
!feet
|-
|Alte Aare
|<{{convert|50|m|ft|disp=table|sortable=on}}
|}
| Name | metres | feet |
|---|---|---|
| Alta Aare | 50 | 160 |
Is there a way to pass the "<" to the template somehow? I can also imagine that ">", "~", "ca.", "+", "-" and "±" will be useful similarly in other cases, maybe other things as well so a generic solution would be preferable to hardcoding something for just for less than. Using something to the "disp=preunit" would be logical from a user point of view. Thryduulf (talk) 15:47, 26 September 2017 (UTC)
- Can't do, sorry. Convert has never had an option to display text before the value because it was "obvious" that such text should simply be placed before the convert. However, that does not work in a table, as shown above. Interestigly, the "<" in the table wikitext is ignored and does not appear in the result. The reason is that the convert outputs the following (two lines, with
...for simplicity):style="..." data-sort-value="..."|50|style="..." data-sort-value="..."|160
- The text before the convert becomes part of the style and is ignored as invalid.
- The available options are here. Some serious thought on better syntax would be needed before thinking about any implementation. Johnuniq (talk) 22:35, 26 September 2017 (UTC)
- Something like "|pretext=" - {{convert|50|m|ft|pretext="<"|disp=table|sortable=on}} - that just displayed the pretext string before both input and output would be nice and simple from my perspective as an end user. I have no idea if that is possible let alone easy to code. Thryduulf (talk) 00:32, 27 September 2017 (UTC)
- I can think about it later, but something which cleans up the weird options (
adj=mid+adj=pre+disp=preunit+disp=x) would be desirable! Johnuniq (talk) 03:24, 27 September 2017 (UTC)
- I can think about it later, but something which cleans up the weird options (
- Something like "|pretext=" - {{convert|50|m|ft|pretext="<"|disp=table|sortable=on}} - that just displayed the pretext string before both input and output would be nice and simple from my perspective as an end user. I have no idea if that is possible let alone easy to code. Thryduulf (talk) 00:32, 27 September 2017 (UTC)
- I support you could end up with a really comprehensive set of options (if it was really needed)
text-pre= text-pre-in= text-pre-out= text-post= text-post-in= text-post-out= text-join= text-pre-unit-both= text-pre-unit-in= text-pre-unit-out= text-post-unit-both= text-post-unit-in= text-post-unit-out= text-pre-value-both= text-pre-value-in= text-pre-value-out= text-post-value-both= text-post-value-in= text-post-value-out=
- {{Convert|1|ft}} with all the text values populated in place would produce (without the line breaks):
(text-pre) (text-pre-in) (text-pre-unit-both)(text-pre-unit-in)1(text-post-unit-in)(text-post-unit-both) (text-pre-value-both)(text-pre-value-in)foot(text-post-value-in)(text-post-value-both) (text-post-in) (text-join) (text-pre-out) (text-pre-unit-both)(text-pre-unit-out)0.30(text-post-unit-out)(text-post-unit-both) (text-pre-value-both)(text-pre-value-out)m(text-post-value-out)(text-post-value-both) (text-post-out) (text-post)
- two-part units such as ft in would be an additional complication.
- And then switch over all the current usages to the new options and then remove those old options. -- WOSlinker (talk) 10:10, 27 September 2017 (UTC)
- Yikes. I was hoping for something like a very simple printf format so the wanted text could be directly specified, and only one parameter needed. Johnuniq (talk) 11:33, 27 September 2017 (UTC)
- (edit conflict) My thought was to have three parameters, "text=" saying what text you want, and "text-position=" (or "text-pos=") to say where you want it, and "text-with=" to say whether you want to display this with the input, the output or both. Using example text "foo" teh text-pos options would include
- first: >1 metre (>3 feet)
- pre-unit: 1 painted metre (3 painted feet)
- last: 1 metre long (3 feet long)
- between-units: 1 metre (3 feet and 3 inches)
- No idea how that ranks in complexity to WOSlinker's idea though. Thryduulf (talk) 11:35, 27 September 2017 (UTC)
- Idea: New parameter:
|line=. Coded parts of output: v1, v2 (for value 1, 2; btw, value=number unit); n1, n2, u1, u2 (for number, unit, in case value needs to be split); c1, c2 (for table columns). - Then user can enter:
|line=<-v1-(v2), or for OP question:|line=c1-<-v1-c2-<-v2 - That's it (now, see if we can get all current parameter options into this one ;-) -DePiep (talk) 20:11, 27 September 2017 (UTC)
- Better/iow: parts of the output are available as escaped code. Non-escaped text it literal. There are also escaped codes for adj forms etc. -DePiep (talk) 20:28, 27 September 2017 (UTC)
- Idea: New parameter: