Misplaced Pages

This is an old revision of this page, as edited by Franamax (talk | contribs) at 08:23, 3 September 2008 (→Update on templates vs, page load time: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archives

2007January–October November December2008January February March April May June July August

This page has archives. Sections older than 21 days may be automatically archived by Lowercase sigmabot III when more than 1 section is present.

template options: Tft3 versus Tcuft

The template permits 'cuft' and 'ft3' in the code. It permits 'Tcuft' but not 'Tft3'. Do we need to review the code options for trillion, billion, million etc and which units they apply to? Lightmouse (talk) 17:38, 7 August 2008 (UTC)

That might be a good idea. JIMp _talk·cont 17:40, 7 August 2008 (UTC)

Thanks. I would also like to say again that I think we should have 'sqft' produce 'sq ft' and 'ft2' produce 'ft²'. Lightmouse (talk) 17:58, 7 August 2008 (UTC)

FWIW, standard abbreviations in the petroleum and natural gas industry are:

• scf - standard cubic feet
• Mcf - thousand cubic feet
• MMcf - million cubic feet
• Bcf - billion cubic feet
• Tcf - trillion cubic feet

Of course, Mcf and MMcf conflict with the standard metric prefixes kilo for thousand and mega for million. M actually stands for Latin mille or thousand. RockyMtnGuy (talk) 04:59, 9 August 2008 (UTC)

To reply to both of the above:

• Lightmouse, I really think we should avoid generating two output forms for the same concept. Decide on a single output, and have both forms use that output. Less confusion all around.
• RockyMtnGuy, while it may be useful to adopt those standards, at the same time I think we should use more logical inputs..."Kcf" for thousand, and "Mcf" for million. Unless there's a real need for "scf", I'm not sure it should be used. — Huntster (t • @ • c) 15:44, 9 August 2008 (UTC)

The real problem is that many of the units used within the petroleum industry are only used within the petroleum industry (and similar industries), are very antiquated, and do not make sense to persons outside the industry who do not know the background. For instance, "scf" for "standard cubic feet" means cubic feet corrected to standard temperature and pressure conditions, which is important if you are measuring natural gas. However, since the abbreviations Mcf and MMcf are in common use for thousand cubic feet and million cubic feet, perhaps it would be best to use abbreviations that do not conflict with them. One set of possibilities is:

• ft - cubic feet
• Kft - thousands of cubic feet
• Mft - millions of cubic feet
• Gft - billions of cubic feet
• Tft - trillions of cubic feet

All of this is nonstandard, but given that most people don't know what the standard is, at least it is unambiguous and would make sense to people with computer expertise (who nowadays vastly outnumber people with petroleum expertise). RockyMtnGuy (talk) 20:53, 9 August 2008 (UTC)

One of my main objections to "Follow the current literature" (a recent much-debated proposed addition to WP:MOSNUM) was that it would introduce industry/feild/etc.-specific terms and abbreviations like "Bcf". Writing for as broad an audience as Misplaced Pages's we should avoid the like. With respect to the above, I'd hesitate to introduce our own home-grown abbreviations and I wonder how ambiguous they really are: if 1 Mft is one million cubic feet, what's 1 Mm? JIMp _talk·cont 09:17, 11 August 2008 (UTC)

Bcf is the industry-standard abbreviation for billion cubic feet in the natural gas industry, but not necessarily any other industry. 1 Mm is one cubic megametre, and that's, like, really big. Under most circumstances you should use 1×10m for 1 million cubic metres. The situation regarding traditional units is basically insoluble because traditions vary from country to country and you will never get everyone to agree, especially not the Brits and Americans. It's like herding cats. My own preference, based on vast experience in herding cats, is to put all traditional units into a museum alongside cubits and leagues, and use SI units exclusively. However that gets all the traditionalists upset. There's no winning scenario. RockyMtnGuy (talk) 03:33, 13 August 2008 (UTC)

Our best bet I reckon is to stick to engineering notation. JIMp _talk·cont 16:18, 13 August 2008 (UTC)

Engineering notation is a coherent solution. But I do prefer (1,400 m³) to (1.4 × 10³ m³) which is what we get with {{convert|50|kcuft}}. In fact, values up to 6 digits seem fine to me. I am not proposing a change, just stating my preference. Lightmouse (talk) 16:36, 13 August 2008 (UTC)

Reading some of the other sections on this page, I see that we can have:

• {{convert|300|e3impgal|m3}} giving 300 thousand imperial gallons (1,400 m)
• {{convert|50|kcuft}} giving 50 thousand cubic feet (1.4×10^ m)
• {{convert|50|kcuft|m3}} giving 50 thousand cubic feet (1,400 m)

I am not sure what I would want, but it looks like we need to choose whether to use 'k' or 'e3' and choose whether the addition of 'm3' should make a difference. Lightmouse (talk) 20:53, 13 August 2008 (UTC)

We should probably reserve the SI prefixes for those units actually formed with them and otherwise have "e3", "e6", etc. Adding "m3" probably should not make a differemce until we're dealing with millions of cubic metres. JIMp _talk·cont 09:08, 14 August 2008 (UTC)

That sounds like prefixes would not be used in the code unless the prefix is applied to the output. Thus 'kblah' would produce 'kiloblah', not 'thousand blah'. Instead, 'e3blah' would give 'thousand blah'. And 'e3kblah' would produce 'thousand kiloblah'. Good, that looks like a coherent solution. I agree with you about the effect of m3. Lightmouse (talk) 09:20, 14 August 2008 (UTC)

{{convert|250|e3U.S.gal|m3}}--->250 thousand U.S. gallons (950 m).

ahhhh...."e3". Ya learn something new everyday. We should probably make a concentrated effort to update the doc page for this template. —MJCdetroit 16:29, 14 August 2008 (UTC)

Too true. I've just got so little Wikitime these days ... y'know: life ... and this long list of things that need doing on this and other templates. JIMp _talk·cont 01:46, 15 August 2008 (UTC)

Superscripts for square and cubic imperial/US units

option

Can we add an option to abbreviate US units as "unit²" rather than "sq unit"? --Lasunncty (talk) 01:36, 10 August 2008 (UTC)

When the template was rewritten (around November 2007) this was not an option according to WP:MOSNUM. It is now. JIMp _talk·cont 09:38, 11 August 2008 (UTC)

Lasunncty, I have previously suggested that:

• input code 'sqblah' produces output text 'sq blah'
• input code 'blah2' produces output text 'blah²'

This would make the code more wysiwyg. If the output is not permitted, then the input code would not be valid. Jimp is, I think, aware that this is on my wishlist for the template. Lightmouse (talk) 09:46, 12 August 2008 (UTC)

Yes, aware I am and was meaning to point you, Lasunncty, in the direction of Template talk:Convert#template options: Tft3 versus Tcuft which does touch on this. Since "blah²" for imperial/US units is now permitted by MOSNUM the template should be able to output this. Lightmouse's suggested input codes make good sense: just what I'd have suggested. JIMp _talk·cont 13:04, 12 August 2008 (UTC)

A foot2 and a sqft are not the same thing, 3ftsq is 9sqft. Dave Rave (talk) 06:09, 30 October 2018 (UTC)

so much response to that, going well ... Dave Rave (talk) 12:10, 23 March 2021 (UTC)

Docs

can we document the acre rood sqperch and include some abbrieviations, Australian government documentation shows a. r. p. Dave Rave (talk) 12:10, 23 March 2021 (UTC)

... Dave Rave (talk) 05:02, 21 November 2021 (UTC)

How to use?

Hi, could anyone explain how these templates are used? Cheers, Horst-schlaemma (talk) 10:32, 9 November 2014 (UTC)

Horst-schlaemma, try asking at Template talk:Convert. Frietjes (talk) 17:57, 9 November 2014 (UTC)

Horst-schlaemma This page is just a list of area units. The template to use them is {{convert}}. It has documentation with it. There is also the more extended Help:Convert. -DePiep (talk) 18:05, 9 November 2014 (UTC)

Cheers and thanks! I was looking for something else and stumbled upon in the meantime. Have a good night! -- Horst-schlaemma (talk) 20:04, 9 November 2014 (UTC)

I've always been against unit² & unit³ because it is not the most common way that cubic/square units in the U.S./imperial system are encountered and shows a huge inconsistency in the encyclopedia as a whole. Many pro-metric editors wanted/want unit²/unit³ for English units because it is similar to what they always have seen with metric units. Some have argued to allow "sq km" (and the like) in the past. Those who have argued for such have lost because for metric units superscripted is the most commonly encountered abbreviations/symbols and SI units are regulated to be only be siunit². English units are not regulated as tightly as SI units, therefore some inconsistencies can occur. Although, there are inconsistencies that do occur with metric units as well. However, there is a recent proposal to eliminate the lower case "l" for litres in favor of "L"; also ml vs. mL. So unless some industry has a specialized standard symbol that it always uses like CCF, MCF, CID, or maybe Tft³ (I don't know about the last one), then we should always stick to the most commonly used symbols/abbreviations for the sake of consistency! Also, with two different styles, I could foresee someone going around and changing English units to suit their fancy. If anything, we should have a bot go through and change all of the code occurrences of mi2, ft2, yd3, mi3, and others to sqmi, sqft, cuyd, cumi, etc, in the same way that Lightmouse had to go through with his bot and change all of the old coding from sqkm, sqm, cum, cukm to km2, m2, m3, km3. —MJCdetroit 02:54, 13 August 2008 (UTC)

I tend to agree with you, MJCdetroit: I'd rather have things consistant in general. The thing is that when the change was made to MOSNUM maintaining the proscription of superscripts for square and cubic imperial/US units was rather low on my list of things to fight for/against. Shall we bring it up on WT:MOSNUM—for whilst this is permitted by the guideline it's no unreasonable request to have the template adjusted to produce it? JIMp _talk·cont 08:54, 13 August 2008 (UTC)

I would be happy for my bot to change all current code occurrences of '|blah2|' to '|sqblah|' where blah is non-metric. This would have no visible effect for readers. It could be done now because it does not conflict with any guidance that exists now or is likely to exist. My bot is currently blocked so I would appreciate support from you all to get it unblocked. Lightmouse (talk) 09:02, 13 August 2008 (UTC)

As discussed on Lightmouse's talk page, the bot has been unblocked by the blocking admin. Good luck. —MJCdetroit 16:22, 14 August 2008 (UTC)

Temperature intervals

Is it possible to give temperature intervals rather than specific temperatures? I wan't to avoid this sort of error. CambridgeBayWeather Have a gorilla 19:44, 15 August 2008 (UTC)

Yes. JIMp _talk·cont 07:24, 16 August 2008 (UTC)

Thanks. I must have missed that when I checked back. CambridgeBayWeather Have a gorilla 15:46, 16 August 2008 (UTC)

Removal of convert template due to page load time

A user removed conversions and suggested that the template increases page load times. See User_talk:Lightmouse#Transcluded_protected_templates_in_articles. What is the answer to this suggestion? Lightmouse (talk) 09:31, 16 August 2008 (UTC)

In the overhaul of the template one of I my main objectives was to minimise the pre-expand include size (this was last year). I've gone to what could be called great lengths to achieve this—we've got over 2,000 subtemplates, it could've been far fewer if pre-expand include size had not been a concern. The template couldn't be much trimmer (I don't think) and do what it does. If the template is replaced with conversions in plain text, there's no cause for alarm. As you suggest, Lightmouse, the best way to prevent the insertion of {{convert}} is to type the conversion in as raw text. JIMp _talk·cont 13:28, 16 August 2008 (UTC)

Agreed with Jimp. I can personally note that it used to be horrendous at some point last year, and there have been marked improvements in the time since (I sometimes muck around with substs etc in userspace for other reasons). Orderinchaos 13:36, 16 August 2008 (UTC)

Can anyone produce quotable statistics? Lightmouse (talk) 15:59, 16 August 2008 (UTC)

Yes ... well, just about anyone who can use a computer. Go to an empty page, type a transclusion in, save it, look at the page's html code (on IE click on View then Source) and find the NewPP limit report. Here's one I prepared earlier.

{{convert|100|mi}}
NewPP limit report
Preprocessor node count: 226/1000000
Post-expand include size: 391/2048000 bytes
Template argument size: 447/2048000 bytes
Expensive parser function count: 0/500

JIMp _talk·cont 10:55, 17 August 2008 (UTC)

I do not understand that. Can you explain it in terms of the burden that the template causes? Lightmouse (talk) 10:57, 17 August 2008 (UTC)

Isn't that page now cached on the servers? (WMF uses squid caching doesn't it?) So isn't the load "pushed forward" so that when you make a change to the template arguments, the cached article page gets invalidated and regenerated, just like any other page edit? And if you change the template itself, of course, many many article pages get invalidated and regenerated. I'm no expert, but templates and page edits don't really affect the average viewer looking up something on Misplaced Pages, do they? Franamax (talk) 11:06, 17 August 2008 (UTC)

I wish I could explain things better. What I do know is that these wp:template limits were put in place to keep pages from taking too long to load. So, I'm guessing that the higher the numbers the greater the burden. JIMp _talk·cont 11:21, 17 August 2008 (UTC)

It is important that we find a way of explaining this to ordinary users. I do not want metric units removed from too many articles. See: Special:Contributions/Marcia_Wright. Regards Lightmouse (talk) 17:23, 17 August 2008 (UTC)

Didn't Marcia write that she'd cosider Option 2 (on your talk page)? Yet she seems simply to be reverting you outright. JIMp _talk·cont 17:55, 17 August 2008 (UTC)

Marcia is now making the point that the template does not permit '1.1. million acres (xx km²)' and I had to change it to '1,100,000 acres (xx km²)'. This sounds like a case for 'e6acre'. Is this possible? Lightmouse (talk) 15:42, 21 August 2008 (UTC)

Centimetres

Why do we not abbreviate centimetres to the symbol cm? — OwenBlacker (Talk) 16:18, 16 August 2008 (UTC)

Who says we don't? Lightmouse (talk) 16:35, 16 August 2008 (UTC)

Not I.

{{convert|4|in|cm}} → "4 inches (10 cm)"

JIMp _talk·cont 10:48, 17 August 2008 (UTC)

Superscripts

WP:UNIT#Unit_symbols says 'Avoid the unicode characters ² and ³' and use  instead. This template seems to use the unicode characters. Will changing it produce any problems? JMiall₰ 16:21, 17 August 2008 (UTC)

No, no problems. But the subtemplates are largely protected. JIMp _talk·cont 17:47, 17 August 2008 (UTC)

I temporarily lowered the protection on the subtemplates of m2, km2, m3, and km3. Some of the others like mm2, cm2, and cm3 were already unprotected. Edit them as needed. —MJCdetroit 02:11, 18 August 2008 (UTC)

It seems somewhat obvious that acres are converted in m* rather than m, no? Thus most readers can easily identify m2 for these. Adding superscript to all conversion just messes up the line spacing. -- User:Docu

This is not the forum for Unicode characters vs  since WP:MOSNUM#Conventions now recomends that the former not be used. I brought this change to talk. Consensus seemed generally in support. JIMp _talk·cont 01:00, 19 August 2008 (UTC)

Sure, but the MoS concedes " can produce irregular line spacing, that is usually a less serious problem", but as it is here, we are better off leaving in the unicode. -- User:Docu

Are you sure that's still relevant? I thought the old line spacing problems were more or less fixed by a CSS change quite some time (months if not years) ago. —Ilmari Karonen (talk) 11:19, 19 August 2008 (UTC)

Indeed, <sup> no longer produces irregular spacing, which was very apparent to me as an old signature of mine used superscript and caused that spacing. Now those sigs look perfectly normal. Just for the sake of interest, the fix was implemented on 21 March 08 with this diff. — Huntster (t • @ • c) 16:47, 19 August 2008 (UTC)

I think the unicode to <sup> conversion still needs to be done for conversions to square kilometres and square miles etc. Eg {{convert|6|ha|km2 sqmi}} gives 6 hectares (0.060 km; 0.023 sq mi).--JD554 (talk) 09:58, 20 August 2008 (UTC)

converting '|ft2|' to '|sqft|'

As a result of other discussions on this page, I have made a start on converting '|ft2|' to '|sqft|' and other non-metric squares and cubes. So far I have tried to do: 'in2', 'in3', 'yd2' and 'yd3'. However, when I do 'what links to' the relevant templates, there are still lots of articles. I am sure that this is because of infoboxes or something but I can't work it out. Can anyone see where they are? Lightmouse (talk) 21:52, 20 August 2008 (UTC)

Thanks. The 'something' has to do with redirects and default unit outputs (as best that I can explain it). I think, I've taken care of the cubic inches' template redirects and default unit outputs (this thing: |o=cuin). I'll do more when I get a chance. —MJCdetroit 14:57, 21 August 2008 (UTC)

The 'what links here' will be a shorter list and more accurate when you have finished. This will be much easier for Lightbot. Let me know as you complete each unit. Incidentally, there is still something weird with cubic inches. If you run 'what links here for 'Template:Convert/in3', you get 55 articles and I still can't work out why. Lightmouse (talk) 15:28, 21 August 2008 (UTC)

I think it maybe a cache thing. Go to any article in the 'what links here' page. Then, click edit and go all the way to the bottom and you'll see 'Template:Convert/in3' in amongst the other templates. Next click, "Show preview". You'll notice that the 'Template:Convert/in3' is no longer there. That's the only explanation that I have. Good luck Light. —MJCdetroit 17:13, 21 August 2008 (UTC)

That 'preview' test is a neat trick. I have also seen delays of a few hours with infobox updates. Let us see what happens here. Lightmouse (talk) 17:19, 21 August 2008 (UTC)

Thanks for your work on that MJCdetroit. I was making progress but somebody stopped my bot questioning its approval for its edits, see User_talk:Lightmouse#Please_stop_Lightbot_until_its_behavior_is_documented. I am going back for approval again with a more generic wording. If anyone wants to view the wording and support it, please speak up at: Misplaced Pages:Bots/Requests_for_approval#Lightbot_3. Regards Lightmouse (talk) 23:30, 21 August 2008 (UTC)

The template:

• Template:Convert/list of units/area/SI

is still using in2, ft2, mi2. Can somebody fix that please? There are also several monobook scripts that are out of date. Some are adding '|ft2|' and '|knot|' etc. See this. If these are still active, we need to ask them to update. Lightmouse (talk) 10:17, 24 August 2008 (UTC)

significant figures on input

Is it possible to specify that the input value be rounded (i.e. a higher precision value be used than displayed? For example: {{convert|1.070344|e6acre|km2|sigfig=2}}: 1.070344 million acres (4,300 km); {{convert|1.1|e6acre|km2}}: 1.1 million acres (4,500 km); I would like "1.1 million acres (4,300 km)". The problem arises when the mantissa of the converted value is greater than that of the original (i.e. 4.3 > 1.1) and when we don't want to display the source value to the highest precision known for aesthetic reasons --Random832 (contribs) 14:30, 22 August 2008 (UTC)

I don't believe it is possible to modify the source figure in output, however, why not simply use {{convert|1.07|e6acre|km2}} (1.07 million acres (4,300 km))? If the exact number is 1,070,344, and the output is giving an undesired precision, then 1.07 seems perfectly acceptable compared to 1.1. You don't have to reduce it to two significant digits...three or even four is okay, especially if the source number really is an exact figure. At least, that is my feeling on it, though to be honest, if the source is long but precise, I wouldn't round in any situation...I'd use that exact number. — Huntster (t • @ • c) 19:00, 22 August 2008 (UTC)

Well, the exact figure (well, not so much exact as a whole hell of a lot more precision than "1.1 million") does get used - but it's a bit verbose to put in the lead paragraph. --Random832 (contribs) 05:34, 23 August 2008 (UTC)

Inches to Centimetres

Take a look at the height of Jacques Anquetil. I came across this before looking at footballers heights. Why is 5 foot 8 inches (5' 8") equal to 176cm (1.76m) on this Converter? When everybody knows when they look at a tape measure, that 5' 8" = 1.73m ?? and 5' 9" is 1.75m. So this converter is out by nearly 3cm !! - Culnacreann (talk) 21:47, 22 August 2008 (UTC)

How are you getting 176? {{convert|5|ft|8|in|cm|0}} comes out as 5 feet 8 inches (173 cm). — Huntster (t • @ • c) 00:25, 23 August 2008 (UTC)

It's not 5' 8", it's 5.8 feet, i.e. 5 feet 9.6 inches, which is technically correct. The person who entered it claims to be a native speaker of Estuary English, so you're lucky he didn't convert the weight to stones...RockyMtnGuy (talk) 00:58, 23 August 2008 (UTC)

Haha, nice catch. I've since change the page to convert into feet and inches, which is more usable for most people. — Huntster (t • @ • c) 14:45, 25 August 2008 (UTC)

converting a range of °C to °F on my sandbox page

Could someone either let me know if I'm doing something wrong, or implement converting a range of °C to °F?--Rockfang (talk) 13:15, 25 August 2008 (UTC)

I am guessing that range conversions aren't implemented for temperatures yet, as it is calling on the non-existent template {{Convert/Dual/LoffT}}. — Huntster (t • @ • c) 15:03, 25 August 2008 (UTC)

Could someone please implement it?--Rockfang (talk) 20:19, 27 August 2008 (UTC)

Ditto. I would find it most useful right now. --Wizard191 (talk) 13:11, 29 August 2008 (UTC)

Will get to it but time is short these days ... or if anyone else can figure out how, be my guest ... JIMp _talk·cont 19:07, 1 September 2008 (UTC)

Template:Infobox Islands: help needed

Would a knowledgable person have a look at {{Infobox Islands}} and see if he or she can figure out why the "elevation" parameter in the infobox, which makes use of the {{convert}} template, is producing expression errors on the infobox's documentation subpage? You may wish to continue the conversation on the template talk page. Thanks. — Cheers, JackLee 06:40, 29 August 2008 (UTC)

Solar masses

Any chance of adding support for solar masses (1.98892 x 10 kg)? —Alex (ASHill | talk | contribs) 21:59, 30 August 2008 (UTC)

Every chance ... but exactly how big is the Sun? ... Okay 1.98892×10 kg looks like a conventional value according to the article, let's take that. But how do we do the symbol? JIMp _talk·cont 19:14, 1 September 2008 (UTC)

The International Astronomical Union style guide (dated 1989, but apparently still current) recommends 1.9891×10 kg, so that's probably the number to use. (I don't think it much matters at that level of precision; quantities that are measured in solar masses are rarely known to as many as 3 significant figures.)

M_⊙ (''M''_&#x2299;) should work for the abbr=on version of the symbol. (I italicized the symbol because it is sort of a variable, representing the mass of the Sun; a quick look finds that 2 leading journals (Astrophysical Journal and Astronomy & Astrophysics) do it this way, while Monthly Notices of the Royal Astronomical Society uses M_⊙.) —Alex (ASHill | talk | contribs) 20:01, 1 September 2008 (UTC)

Done: the code is solar mass e.g. {{convert|4.5|solar mass}} → "4.5 solar masses (8.9×10 kg)". JIMp _talk·cont 22:58, 1 September 2008 (UTC)

Though I'm not too certain of the italisation. Whilst it's based on an experimental value (which is slowly being reduced), it is still a unit with a conventional value attached. The Earth, Lunar & Jupiter masses mentioned on the article are not italised, should this be? JIMp _talk·cont 23:43, 1 September 2008 (UTC)

I don't care; I was trying to explain the pros and cons without taking a strong position. Again, there's no uniform convention in the field. We should pick italicized or not and go with it. —Alex (ASHill | talk | contribs) 00:16, 2 September 2008 (UTC)

Units are not italised. Though this could be used as a variable, it's used as a unit here. I'm going for nonitalisation unless there be objections. JIMp _talk·cont 00:21, 2 September 2008 (UTC)

I believe that there is a guideline or standard that says italics should not be used. It may be ISO or SI. If Gene Nygaard were here, he would tell us in no uncertain terms. Lightmouse (talk) 08:39, 2 September 2008 (UTC)

Lightbot: please support latest approval

Many of you will know of the activities of Lightbot. It has touched over 140,000 articles with edits relating to dates and units. I've made a new request for bot approval that is largely a clarification/extension of two previous approvals and has wording that should be easier to understand. The bot approvals group is not necessarily aware of what Lightbot does so I would be grateful if you could add a few words in support at Misplaced Pages:Bots/Requests for approval/Lightbot 3. I would also be happy to answer any questions here or on my talk page. Regards Lightmouse (talk) 08:55, 1 September 2008 (UTC)

Plurals

Gun calibre measurements are usually quoted in the singular rather than the plural (eg, a 120 millimetre gun rather than a 120 millimetres gun). Is there a way to remove the plural from the units? I couldn't see this on the page anywhere. EyeSerene 16:45, 1 September 2008 (UTC)

Never mind: adj=on. :P EyeSerene 16:55, 1 September 2008 (UTC)

Can somebody remind me of the difference between adj=on and sing=on? Lightmouse (talk) 17:00, 1 September 2008 (UTC)

They appear to do the same thing (I've just tried it out). Which is preferred? EyeSerene 17:16, 1 September 2008 (UTC)

Lightmouse, nothing. adj is prefered ... or at least by me. JIMp _talk·cont 19:11, 1 September 2008 (UTC)

Thanks. Well, I think you know that I don't like conflating the 's' with a hyphen. My ideal would be two parameters: sing=on (makes it singular); and hyph=on (adds a hyphen). Then adj=on can be deprecated. My second best would be to keep adj=on as a shortcut for 'sing=on|hyph=on}}'. We have been through this before and I know I am a minority on this. Lightmouse (talk) 19:22, 1 September 2008 (UTC)

Yeah ... hey ... JIMp _talk·cont 19:30, 1 September 2008 (UTC)

I've always used sing=on just out of habit and I am sure that there are others that do the same. —MJCdetroit 13:18, 2 September 2008 (UTC)

Units of radioactivity

How about adding Becquerel (Bq) and Curie (Ci) to this template (including kBq, mBq, µCi, nCi and so on)? ––Bender235 (talk) 08:18, 2 September 2008 (UTC)

Documentation change - range conversions

Based on the limitations in range conversion listed by Jimp here, I've updated the docs to hopefully head off some questions hitting this talk page. If the situation has changed since then or I'm wording it wrong, hack away! Franamax (talk) 06:57, 3 September 2008 (UTC)

Update on templates vs, page load time

After this discussion (semi-permalink}, I took this question to the VP (technical) wizards (semi-permalink) and here is my summary as best I can glean the pearls:

• For the vast majority of our readership, template complexity doesn't matter at all. Other than the unlucky first unregistered reader who requests a page just after it has been changed (and one per week thereafter, when the cache has expired) the page they see is served up very efficiently from a cache which cares not about how complex the page is, it just gives out the exact same version as last time. This is 90-95% of our viewership and I would submit is really the only people we care about - average people coming to Misplaced Pages to learn something.
• Contrary to what Marcia thought, the number of templates on a page have no effect at all as far as being on a high-speed vs. dial-up line. The number of bytes going "across the wire" are the same. The difference is that a template-heavy (and especially a complex-template-heavy) page makes the servers fetch many pages from the database and mull and chew on the template output. Again though, this is more of a problem for us peons who are the first to view the pages while editing.
• The "NewPP limit report" as exemplified by Jimp in the first link I've provided can be used as a rough gauge of how heavily loaded the page is, by comparing the first numbers (numerators) against their denominators. In the example case, the template load is trivial. A further indication is the display below the edit box after you preview, beginning at "Templates used in this preview:" - each one of those will/may cause a database fetch to retrieve the (sub-)template text, adding to the page load time. Again though, this has more of an impact on us editors, and less on our readership. We must balance that against the convenience, flexibility and elegance of the {{convert}} template.
• Flattening and simplification of the {{convert}} template structure would certainly lessen the load. I'm definitely not going to stand here and insist that should be done though, since I'm still awestruck by the whole thing.

In general, I'm not convinced that using this template causes significant problems (problems worse than those we all find when the servers get slow just because the servers are slow right now), but I suppose I should try some experiments. I hope some small part of this screed will be useful going forward! Franamax (talk) 08:22, 3 September 2008 (UTC)