This is an archive of past discussions about Template:Height. 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.
Clawed, by stretching out this template to say ft and in, you are stretching out countless infoboxes needlessly which use this template inside of them. ie: NHL players. Just leave it with the standard " for inches and ' for feet. The strokes16:06, 11 July 2006 (UTC)
The template should strictly follow the manual of style since it is a template in many articles. I have looked at half of all the NHL players that use the NHL infobox and only found a couple of boxes that were expanded such as Sergei Samsonov, but always by only a very small amount. Can you please provide some exapmles of articles where the infoboxes have been expanded by the change of this template--Clawed08:36, 12 July 2006 (UTC)
Shawn_Horcoff Sergei_Samsonov Brendan_Morrison
. The bracketed measurement will be placed on a second line
This template is being used on that article, but the numbers given in it are not exact, so using this template implies an inappropriate degree of precision. This shouldn't be used outside of cases where the numbers are specifically known. Night Gyr (talk/Oy) 18:39, 21 March 2007 (UTC)
Small change to remove spaces
A small request/proposal: rather than 6 ft (1.8 m), how about 6ft (1.8m)? When written normally, there would be no space between the number and symbol, e.g. 20kg, 100m. Fedgin | Talk11:46, 26 March 2007 (UTC)
Put a space between the value and the unit symbol, for example "25 kg", "5 °C", (not "25kg", "5° C"); however, angles in degrees have no space: "45°". Preferably, use for the space (25 kg) so that it does not break lines.GregorB14:49, 6 May 2007 (UTC)
Well, strictly speaking 1.82m is 5.97112861 feet. Since it's not quite yet six feet, that's probably why it's not rounding it up to 6 ft 0 in—to insinuate the small difference.
Is it possible to have the template display conversions in centimetres rather than metres and centimetres, e.g. 6 ft 1 in (185 cm)? McPhail00:21, 17 April 2007 (UTC)
My thoughts also... Besides: e.g. 5 ft 11 in expands to "1.8 m", which is an odd format for human height (1.80 m or 180 cm would be customary). I'd also like to see a 1/2 inch precision (e.g. 187 cm is 6 ft 1½ in), although this looks pretty difficult to implement. GregorB14:35, 6 May 2007 (UTC)
Hi I've created a copy of this template on the norwegian language. Can an administrator add a IW in the noinclude section to no:Mal:Height? Nsaa18:37, 17 May 2007 (UTC)
I just noticed an apparent fix is posted above under the "Fault" heading, as well as a request to add an interwiki link, so I'm adding the editprotected template here.
Hi I've added instructions without noticing there were some at the top of this talkpage, so I reduced mi edits to a quick guide, I wonder if you would mind to move these long table to the /doc subpage --Andersmusician$00:55, 17 June 2007 (UTC)
Enquiry
Could someone add an instruction so that you can specify whether you want feet or metres to appear first? For example with footballers, some people get very nationalistic over which units to highlight and so used { {height|ft=6|in=1} } / 6 ft 1 in (1.85 m) when the player is actually 1.86 m tall. I reverted to { {height|m=1.86} } / 1.86 m (6 ft 1 in) because it is more correct, and only after a few iterations of this minor edit war did I notice what the problem is.
So what I'm saying is that it would be good to be able to enter the height in metres, but get feet display first. Shouldn't be too much work, should it? Cheers, aLii15:44, 4 July 2007 (UTC)
Links
{{editprotected}}
I'd like to propose removing links to ft, in, metres, etc, as this makes the display of height in infoboxes very inelegant. It's also superfluous as the most obvious of links are not supposed to be made unless relevant to the article, such as linking years when not part of a date. Opinions? robwingfield«T•C»21:30, 23 May 2007 (UTC)
I have turned off the editprotected link for now because there is very little comment on this and this template is used very widely. I would like to see enough to believe that there is consensus before making the change. Perhaps you can post something at the village pump to draw some attention for people to come here and comment. Once (if) you have consensus, I will be happy to make the change. --After Midnight000114:00, 31 May 2007 (UTC)
I support it per GregorB's comment. ~ thesublime514 • talk • sign 03:59, July 5, 2007 (UTC)
I oppose this. I believe the links should remain because users may not be familiar with the units, or more importantly the abbreviations. And on many articles, this template is the first and only usage of them. I wouldn't be opposed to a parameter specifying whether to link or not. — The Storm Surfer04:13, 6 July 2007 (UTC)
A reader wouldn't be familiar with the units or abbreviations? I'd find that hard to believe, but in the remote possibility that they're not familiar with pretty much the only units used to measure height worldwide (either metres or feet & inches), then the figures being provided are of no use to them, so a link to the article describing them would be of no use either. robwingfield«T•C»18:35, 7 July 2007 (UTC)
Half inches
I can't seem to get the template to use half inches; { {height|ft=6|in=1.5} } and { {height|ft=6|in=1} } both display as 6ft 1in; however, the metric changes correctly. Thanks, BertieBasset16:35, 30 June 2007 (UTC)
{{Height}} currently does not support half inches, but for the equivalent result you can try this: {{Ft in to m|ft=6|in=1.5|abbr=yes|precision=2|wiki=yes}}, which expands as 6 ft 1.5 in (1.87 m). Speaking of which: it would make sense for {{Height}} to transclude {{Ft in to m}}, it would simplify its code greatly, with half inches as a bonus. Any opinions on that? GregorB17:24, 4 July 2007 (UTC)
Precision=0 should be the default instead of precision=1 because that's how human height in inches is usually represented and that was the template's original behavior. The current setting displays precision that isn't there. GregorB13:04, 5 August 2007 (UTC)
I agree. In the main, people never measure height in fractions of inches. Precision=0 should be the default. - PeeJay14:26, 5 August 2007 (UTC)
Whoops, I didn't realize there were more complaints above. Just wanted to say that when I was re-designing this template, I beleived that it should be deprecated; all improvements were introduced only as a stop-gap measure. But since people are eager to keep this, a more serious re-write is in order. Anyway, as for the fractions being 16ths, that can be easily switched to any other denominator, as {{dec to frac}} (which is called to handle fraction conversions) can handle all of the smaller values (16 is used here only as a default; it is trivial to switch to 2 (for halves) or to a custom parameter.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 15:53, 5 August 2007 (UTC)
"Precision=0" broke the support for fractions. I'm going to leave it as is for now because the fractions support is not used anywhere and the default/requested behavior is not affected, but rest assured I'll have it fixed later... unless this fraction feature is found to be completely unneeded.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 19:15, 5 August 2007 (UTC)
Update
OK, hopefully I was able to finally fix this template. For meters-to-feet/inches conversions, the output now defaults to showing half-inches. If fourths, sixteenths, 45ths, or whatever else is desired, specify it using the frac parameter (set frac=4, 16, 45, or whatever). Use frac=10 to show inches as decimals (the default precision for this is one, but it can be changed using the precision parameter). To make sure no fractional inches are shown (either vulgar or decimal), set precision=0.
Well, there's this very minor issue that was present since the beginning: e.g. {{height|ft=5|in=11}} displays the height as 1.8 m, while the display of 1.80 m would be more common in general use. As far as I can tell, this is due to behavior of the MediaWiki round function, so working around it looks difficult. GregorB17:44, 16 August 2007 (UTC)
You are right, it is how the round function works. I won't say it's unfixable (it is), but fixing it is definitely not something that can be done quickly (not with the limited assortment of tools the template language provides, anyway).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:59, 16 August 2007 (UTC)
Ah, alright, I couldn't resist—I tried it out :) Turned out to be not as difficult as I first thought. However, since I don't have time to test is thoroughly, please do so for me before this improvement can go into production.
In order to change {{height}}'s handling of trailing zeroes, {{ft in to m}} will need to be improved. That improved version of {{ft in to m}} is now located at {{X8}} (here's the permalink in case X8 gets reset; it's a sandbox template). Please test it out with different values and precisions. If everything checks, then X8's code can simply be used to overwrite {{ft in to m}}'s, after which <!-- {{height}} --> will handle trailing zeros properly.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:55, 16 August 2007 (UTC)
I thought I've fixed this one already? Could you, please, point out where exactly it is in violation of MOS? I might have missed something, of course. As for {{weight}}, I also promised to fix it, but never got around to actually doing it :( Thanks.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 21:29, 30 October 2007 (UTC)
Ah, that. The only reason why this template defaults to abbreviated units is because it is intended for use primarily in infoboxes, where spelling out units is not practical. I was not aware this template is used anywhere outside infoboxes; perhaps this point should be clarified in the documentation. In any case, it is possible to add the abbr switch to take care of this contingency. Please let me know if that would be helpful. Thanks.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 21:17, 31 October 2007 (UTC)
OK, done. You can now use the standard abbr parameter, which takes values of yes (default), no (both sides spelled out), and mos (MoS-compliant). Note that the issue with singular units still needs to be fixed—one foot/one inch/one meter currently show as "1 feet"/"1 inches"/"1 meters", so until that's fixed please exercise caution.
This is a great addtion to Wikipedia. Would it be possible to use the ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ and ⅞ characters when displaying fractions of inches? This would enhance the appearance of the output. Best Wishes Saga City08:11, 31 October 2007 (UTC)
The author of the template that handles the fractions ({{frac}}) originally implemented that feature, but I believe he then rolled it back because of the MoS concerns and overall inconsistency of look. It is not terribly difficult to add the feature back, making it optional if necessary, but we first need to determine whether this feature can be considered to be MoS-compliant or not.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 14:16, 31 October 2007 (UTC)
In most cases in which this template is used, nothing more than half-inch precision is reasonable. But that isn't true in all cases in which it is used, let alone in all cases in which it could be used, were it designed with some way to override the default to the current precision.
But even when half-inch precision is used, there is a second point made here by Saga City
Done. You could have done it on your own, by the way (interwikis go to the doc page, which is not protected). Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 21:47, November 30, 2009 (UTC)
1.82 converts to 5' 12""
I found the above problem as well, but also not that a person exactly 1.82 meters will convert incorrectly.
{{height|m=1.82|precision=0}}->1.82 m (6 ft 0 in)
--SPhilbrickT11:58, 29 June 2009 (UTC)
On a slightly related issue, Is there any guidance over people doing mass changes from height->convert or vice versa in a case when the extra functionalities aren't being used? Mattlore (talk) 05:15, 13 September 2011 (UTC)
Centimetres
Why give heights in metres? Usually when people speak of height it's in centimetres (if they're talking metric). Jɪmp23:27, 11 September 2007 (UTC)
Having for most of my life lived in a country that uses the metric system, I should note that stating a human height in centimeters is not nearly as common as giving it in meters (e.g., 1.89 m) or in meters and centimeters (1 m 89 cm). I can't vouch, of course, that this is the case everywhere else.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 00:15, 14 September 2007 (UTC)
That country would be Russia, would it not? I should rephrase ... usually when people speak of height, in English speaking countries, it's in centimetres (if they're talking metric) ... or at least that's my experience. Giving human height in metres would be most uncommon where I'm from (Australia). Jɪmp07:02, 20 September 2007 (UTC)
We can inform ourselves with some crude research. Here are some suggestions for google tests:
height 178-cm weight
height 1.78-m weight
taille poids 178-cm
taille poids 1.78-m
Höhe Gewicht 178-cm
Höhe Gewicht 1.78-m
altura peso 178-cm
altura peso 1.78-m
Google has excellent facilities for restricting searches to one country (e.g. Spain) or language (e.g. Spanish). Run the english language tests on www.google.co.za using the 'pages from South Africa' button below the search box.
Similarly with www.google.com.au using the 'pages from Australia' button.
Other useful data sources would be articles (but not translations of US non-metric articles) from local Wikipedias. For example, the Italian Wikipedia shows the height of Matias_Aguero in metres.
In ignorance of the 'right' answer, we could have a slight preference for base units (m, kg, W) over prefixed units. My impression is that there is no consensus that would be 'right' for all countries and all domains. Lightmouse12:15, 22 September 2007 (UTC)
Here in Sweden we at least say (translated) "I'm one and eighty-seven" going with the 1.87m view. "I'm 187 centimeters" just sounds retarded ;) Chandlertalk09:10, 5 October 2007 (UTC)
In Canada, its centimetres. Giving height in metres AND centimetre (1 m 87 cm) copies the foot-inch reporting & does not make use of the decimal relationship between metres & centimetres - the very reason for the design of the metric system. Using decimals for height (1.87 m)adds an unneeded character - a character that is easily confused with a punctuation mark in sentences. The height template needs to allow the conversion be done to cm, at least as an option if not as default.--JimWae (talk) 06:57, 2 July 2010 (UTC)
In Australasia and East Asia it's all centimetres. I've never seen anyone express height in metres in my life till I came to Wikipedia. The problem with the solution mentioned by JimWae is that it has feet and inches as the main height with the centimetres in brackets. How can we get it the other way around?--Gibson Flying V (talk) 01:04, 26 July 2012 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please implement the changes I have entered into this version of the sandbox which will allow cm to be entered into the template, but will display it as m for now until the RfC on this talk page is closed. The testcases page shows that this is working properly. I've also replaced the deprecated <font color=red>...</font> with the {{Error}} template. Finally, in the comparison I've linked here, it shows the sandbox using {{template sandbox notice}} instead of {{Documentation}} which obviously won't change. Thank you.
Technical 13 (talk) 02:05, 28 January 2014 (UTC)
Done as there has been no opposition, and the protection level has been lowered to Template editor so that I could make this change. Please feel free to ping me if there is an issue and I will quickly revert until a new consensus is formed. Technical 13 (talk) 14:40, 29 January 2014 (UTC)
The RfC is to whether or not cm should be allowed as an output from this template, the changes made do not effect the output as it pertains to units at all and as such are not effected by the RfC. GS, if you are actually saying that you oppose the change that allows it to simply be an input, then I would be happy to revert that part of the change. Technical 13 (talk) 16:17, 29 January 2014 (UTC)
Other problems: Those changes help somewhat, but {height} has many other problems, so I proposed a cm-focused, co-template for {height} to be totally rewritten from scratch, to avoid the recent problems in {height}, including:
Even worse, {height} has had a expansion depth of 18 levels (should be less than 10), for the wp:expansion depth limit. Overall, I would let people use {convert} for cm, until a special cm utility was developed as a simple, clear alternative. Then later, rewrite {height} using the dozen improvements in the new cm-focused template. -Wikid77 (talk) 16:01, 29 January 2014 (UTC)
Wikid... Eek!!! I didn't realize it was so deeply expanded. I would be happy to write a /core for this template to reduce that issue (and since it won't be transcluding other templates like {{Convert}}, it should be much faster and lighter weight as well). Technical 13 (talk) 16:17, 29 January 2014 (UTC)
There are so many options, such as "frac=16" which could be dropped as extravagant, but we need to see where used. The short ft/in format, as 5'10" is opposed by wp:MOS, and you know what that entails. -Wikid7703:36, 30 January 2014 (UTC)
Better to just rewrite this template as a simple frontend to {{convert}}, rather than creating a new template. The new LUA version of convert seems to work well, and we should just use that where possible. Plastikspork―Œ(talk)00:10, 30 January 2014 (UTC)
Long-term, we cannot keep expanding the "{Convert} empire" which has become "all eggs in one basket" and there is no need to complicate a simple multiply-and-round to become a gigantic 15,000-line, Lua-based system. Meanwhile, new features could be added into a separate template, and bypass bugs in {convert} such as "inch" when plural: • {convert|1.56|m|ftin|frac=2|abbr=off} → 1.56 metres (5 feet 11⁄2 inch) The plural bugfix for "1+1⁄2 inch" as formerly a 1-hour fix, will be delayed until March 2014. The "Rise of the Mega-template" has greatly complicated bugfixes and thwarted new features from the TfD'd alternate templates. Remember: {convert} did not support fractional output inches for 8 years. Already {convert} has dropped support for dates/times, now handled by {convert/old |10 Feb|date|day} → {{convert/old |10 Feb|date|day}}. Imagine what other, not-so-obvious features would be delayed by using Lua {convert} another 7 years. -Wikid7703:36, 30 January 2014 (UTC)
Mindful use of see alsos, categories, or maybe even disambiguation pages would make it easy to find the correct template in lieu of a super convert template.—Bagumba (talk) 05:49, 30 January 2014 (UTC)
Replacing ERROR with exact proofreader notes
I have been looking at replacing the red-error message with small proofreader notes (of the style "[citation needed]"). Currently, if a newcomer thinks they have to supply both metres and feet, then the numbers disappear and the page will show:
{{height|m=1.83|ft=6}} = Error: please specify height using only one type of units
So, instead of hiding the numbers, the new message would appear as:
Proposed: {{height|m=1.83|ft=6}} = 1.83 m 6 ft [fix double units]
Proposed: {{height|m=1+80cm}} = 1+80cm m [fix '1+80cm']
The proposed format will show the numbers in question, such as "1.8o" with letter "o" (as invalid number), and new users can see the specific numbers, plus tiny notes such as "[fix double units]" which links to a mouse-over description plus the related text in the template documentation. In the early days of Wikipedia, most templates had to be kept simple because all error-message code was stored for every use of each template, even when no errors had occurred; however, in January 2008, a recursive descent parser was installed to skip false branches of if-functions (such as error clauses), and now messages can be formatted with wikilinks as small superscript proof-notes without storing all error-text when every page is formatted. Since 2008, there is no longer a performance-based reason to show only minimal red-error messages without repeating the exact numbers in question, or linking to the documentation to further explain how the numbers are invalid. Now the clear, precise proofreader notes are quick to process in templates, to provide better messages for new users who do not check all data before saving an edit. Such precise messages require extra internal work, but it is worth the extra effort to provide better typesetting in live articles. -Wikid77 (talk) 16:55, 25 January 2014 (UTC)
I like this idea. It puts the error into perspective, allowing it to be readily identified without being unhelpfully intransigent. Just a detail: have you thought of making the "fix" red instead of blue? Or even the whole message? It's all a matter of perceptual degree. Evensteven (talk) 22:14, 28 January 2014 (UTC)
Blue-link proofreader notes follow the style of "[citation needed]" with blue wikilinks, and smaller text. The prior use of "Red-text messages" which had seemed better, as eye-catching errors, has proven ineffective, where other red-text messages have been left in articles for months (or years), while (many) thousands of users view the pages with the over-the-top wp:grandstanding about one problem among dozens of other issues to be improved. When a new user specifies both height amounts as, "1.88 m (6 ft 2 in)" then it is technically correct text, and does not deserve a glaring red "Error" nor red "fix" message, and certainly not the: • 1950s-style: ERROR: Does not compute, choose either A or B Instead, the main focus now is "live typesetting" but red-error text is often just over-the-top shouting about one issue, among many others possibly 100x times more crucial for the page. Also, auto-correction is even better, to note "m=1.8o" as invalid letter "o" but treat it as "1.80" to show correct ft/in but with blue-link warning "[fix '1.8o']" as a reminder. -Wikid7716:01, 29 January 2014 (UTC)
