User talk:Jimp/Archive V

Still need to simplify Convert Imp, USre and USer

This thread moved to top due to unclosed markup at end of talk-page

Jimp, I know you have been gone a few days, but long-term, we still need to simplify those 3 subgroups of "-Imp" and "USre" or "USer" to just use the basic Convert subtemplates. Again this week, User:Peter_Horn has noticed missing subtemplates (removed in August 2011) for options "lk=on" and "lk=in" with ranges of unit-codes "impgal" and "usgal". As a first step, I have recommended to use Template:Convert/2 for unusual ranges. However, let's change "impgal" and others to use the basic subtemplates (no more "-Imp"):

See [Template:Convert/impgal/sandbox] - embeds "imp" and "imperial".
{{convert|7|impgal}} → 7 imperial gallons (32 L; 8.4 US gal)
{{convert|7|impgal/sandbox}} → 7 imperial gallons (32 L; 8.4 US gal)
{{convert|7|-|9|impgal|lk=on}} → 7–9 imperial gallons (32–41 L; 8.4–10.8 US gal)
{{convert|7|-|9|impgal/sandbox|lk=on}} → 7–9 imperial gallons (32–41 L; 8.4–10.8 US gal)
Fix Template:Convert/Dual/LonUSre to put nbsp space "US {{{u}}}".

Soon, all of those "-Imp" imperial subtemplates (Template:Convert/L*Imp) can be eliminated by embedding the words "imp" and "imperial" and the hyphenated "h=imperial-<unit>" for each kind of unit name or unit symbol. Also change all multi2 to omit "-Imp" (such as Template:Convert/L_impgal or Template:Convert/usgal_impgal). Every time a new option has been added, then all the Imp or USre or USer subtemplates have fallen behind. Meanwhile, more other-language wikipedias are copying Template:Convert and whichever 3,000 subtemplates they find. -Wikid77 (talk) 22:20, 7 May 2012 (UTC)[reply]

Doing things that way allows us to get rid of the Imp, USer & USre subtemplates which is great but it also means that it no longer links to both the system and the unit page. I've been meaning to get back to the rewrite I'd started a year ago. If sucessful, this will kill both birds with one stone, but I couldn't guess how long this will take. So, in the meantime, killing one bird at a time is probably not a bad idea. In the light of the fact that this stuff in general really shouldn't be linked anyway I reckon you're aiming at the right bird. Yes, let's ditch these. JIMp_talk·cont 23:36, 7 May 2012 (UTC)[reply]

Each multi2 used in about 100 articles: I think the usage of "L impgal" and similar multi2 units is limited to less than 100 articles for each combination. Omitting the "-Imp" will mean the "imp" or "imperial" will disappear in the output and the corresponding u/n/h in the multi2 must be changed to embed "imp" or "imperial" just as in Template:Convert/impqt.

Plan 5 changes for each imp unit-code or multi2 (or multi3):

For each Special:PrefixIndex/Template:Convert/imp, etc.
Remove "-Imp" so "{{{d}}}Imp" becomes "{{{d}}}"
Fix "u=imp qt"
Fix "n=imperial quart"
Add "h=imperial-quart"
Except in multi, add parameters 5-7: "|{{{5|}}}|{{{6|}}}|{{{7|}}}"

Plan 5 changes for each US{r} unit-code or multi2 (or multi3):

For each Special:PrefixIndex/Template:Convert/us, etc.
Remove "-US{{{r}}}" so "{{{d}}}US{{{r}}}" becomes "{{{d}}}"
Fix: "|u={{#ifeq:{{{r|re}}}|re|US|U.S.}} gal"
Fix: "|n={{#ifeq:{{{r|re}}}|re|US|U.S.}} gallon"
Add: "|h={{#ifeq:{{{r|re}}}|re|US-|U.S. }}gallon"
Except in multi, add 5-7: "|{{{5|}}}|{{{6|}}}|{{{7|}}}"

The current multi2 or multi3 parameters 1-4 are enough, even for ranges, where "disp=x" currently works fine:

{convert|5|-|9|L|impgal usgal|disp=x| (precisely |)|4}} → 5–9 litres (precisely 1.0998–1.9797 imp gal; 1.3209–2.3775 US gal)

The "impgal" is in 960 articles (cars, trains, ships, canals). See:

The fixed version of Convert/usgal is Template:Convert/USgal, which has been used with several different options and seems to work well. Later, we can update Simple Wikipedia which has decided to copy all "3,000" subtemplates as they are currently, even though many will likely never, ever be used in the Simple WP articles. Of course, that means few users will notice any difference there, when "-Imp" is removed. Here, beware "Panama Canal" (viewed 4,800x per day) for use of gallons. -Wikid77 10:44, 8 May 2012 (UTC)[reply]

I moved the impgal sandbox onto the live subtemplate. If you're having problems getting around protection, give me a yell. JIMp_talk·cont 15:40, 8 May 2012 (UTC)[reply]

Unprotecting rare imperial subtemplates: We are now down to updating the rare imperial units, such as Convert/imppt to also handle fractions, and unprotecting the multi2 or multi3 forms. In fact, only 18 articles now use the basic "Convert/L*A*DbSoffImp" (for "imppt"):

Special:WhatLinksHere/Template:Convert/LoffAoffDbSoffImp

Most of the multi2 or multi3 can be unprotected:

Special:PrefixIndex/Template:Convert/imp

After I have finished updating them, I will let you know. Usually vandals take months to find unprotected templates, as when all the string-handling templates were unprotected and were still fine until months later. -Wikid77 14:51, 9 May 2012 (UTC)[reply]

I've made some in-roads into this. Whilst at it I've been eliminating the dots-according-to-spelling-parameter option (lower case "us"). These never were such a great idea and are now mostly unused. I'm wondering what the most efficient way of finishing the job off would be. My going and unprotecting, your following and correcting then my going back and reprotecting seems somewhat inefficient. We'd probably both save time if I just do it myself. Also, if you've got a sandbox version of a subtemplate, I can move it onto the live version like we did with the US gallon subtemplate. JIMp_talk·cont 01:57, 11 May 2012 (UTC)[reply]

Keep fixing all Convert/imp*: Just continue in the manner you fixed C/usgal_impgal, next moving other fixes into place, for the reversed "impgal_usgal" and "impgal_L" then "imppt":

Those will update 800 more articles. Eventually, all the articles will delink from the "-Imp" subtemplates:

Very few links remain now. -Wikid77 10:14, 12 May 2012 (UTC)[reply]

New Convert sub-template

Like User:Ohms law/Convert?

By the way, I was using LoffAoffDbSoff (and the 10 and km values) to try to make the page an example. I thought that's what was being talked about on the Wikipedia:Advanced Convert coding#Defining new conversion subtemplates page. Didn't seem to work out, though. *shrug*
— V = IR (Talk • Contribs) 00:29, 22 June 2011 (UTC)[reply]

No, it wouldn't ... haven't time to explain now. JIMp_talk·cont 00:30, 22 June 2011 (UTC)[reply]

Take you're time, I've other things to do as well. :)
— V = IR (Talk • Contribs) 00:33, 22 June 2011 (UTC)[reply]

Well, I moves the code to the actual Template:Convert/mift page, and added a test use at User:Ohms law/Sandbox, but it's not working out correctly, at all. I'm at a loss. b is the base conversion (to the small unit size, right?), and a is the divisor for the value given by the base to generate the larger unit... correct? I'm not sure where the 1,128 figure is coming from, converting from 10 kilometers... *scratches head*.
— V = IR (Talk • Contribs) 02:47, 22 June 2011 (UTC)[reply]

Ah, this is what Wikid77 was talking about here: User talk:Wikid77#Need to create Template:Convert.2Fmift but fix .2FoutAnd Interesting.
— V = IR (Talk • Contribs) 03:12, 22 June 2011 (UTC)[reply]

Well spotted of Wikid. I've fixed it ... (I hope) ... JIMp_talk·cont 03:26, 22 June 2011 (UTC)[reply]

awesome. Thanks for the help, I learned a lot! :)
— V = IR (Talk • Contribs) 03:35, 22 June 2011 (UTC)[reply]

x to y template

Templates like '{oz to g}'

Hi,

Just to let you know. I haven't forgotten about the old conversion templates. My bot is waiting for BAG approval to do weights at Wikipedia:Bots/Requests_for_approval/Lightbot_14. I'm also waiting for approval to do several other units. Go ahead as you're doing. But as soon as I can, I'll set Lightbot on to the task. Lightmouse (talk) 16:56, 27 June 2011 (UTC)[reply]

Thanks. I think I've killed as many off as I'm up for by hand (though I suspect I've had help). JIMp_talk·cont 17:00, 27 June 2011 (UTC)[reply]

Don't forget M3_to_yd3

I might've created the templates, but if they're redundant, it's all about the clean-up. Take it away, Jimp! Mike Vitale 01:21, 28 June 2011 (UTC)[reply]

Thanks for the thumbs up. Sorry I didn't mention it on your talk page. It looks like we're finally going to stream-line the whole conversion biz. JIMp_talk·cont 01:29, 28 June 2011 (UTC)[reply]

No problem at all. Best of luck with the conversion template. I'm mostly idle these days anyway. :) Mike Vitale 03:53, 30 June 2011 (UTC)[reply]

m3 to yd3 is gone, by the way. Best of luck with being idle ... sounds great. JIMp_talk·cont 04:20, 30 June 2011 (UTC)[reply]

Returned from wikibreak

Wikid77 here, finally back, but I got spoiled with the freedom on wikibreak. I will try to fix Convert/hand to seem like the precision in other conversions. Sorry, I got so lazy on wikibreak. T:Precision/2010 nests 10 of 40 deep, while new T:Precision nests 5 deep, or 4 deep with fractions. I see you are doing an awesome job working on hundreds of other specialized conversions. Fantastic work. -Wikid77 16:11, 1 July 2011 (UTC)[reply]

DONE. Forced 14.1 hands as "(57 in)" by forcing rounding in {{{4}}} to "0" when the conversion is hands-to-other units. -Wikid77 17:57, 1 July 2011 (UTC)[reply]

Some empty parameters will not default in subtemplates

I think the MediaWiki markup is highly accurate (except for the precision bug in "round -5"), but I swear that some empty parameters do not accept their default values, such as {{{4|0}}} not defaulting to 0, when empty in nested subtemplates. I have noticed this problem for months, and I might still be wrong about it (where perhaps an "empty" parameter has a newline in it to botch the "empty" status), but I have had to force, by using #if, to check for an empty parameter and then force the default value as part of the if-logic.
This happened in Template:Convert/hand, today, where I tried "{{{4|0}}}" to default the round "|0" as zero, but it would not work until I forced it by checking if-then-else of empty:

{{#if:{{{4|}}}|{{{4|0}}}|0}} ← if {4} exists use {4} else 0.

Using that #if, when {{{4}}} was omitted, it was treated as 0; otherwise, it would not accept the "0" in {{{4|0}}}. Perhaps this is a logged bug in Bugzilla. Anyway, just giving a heads-up, in case you are trying to default parameters, in nested subtemplates, such as using {{{4|0}}} which sometimes fails to default to 0. -Wikid77 17:57, 1 July 2011 (UTC)[reply]

Colours/Colors

For the horse template, I don't see any way to make your proposal of TWO horse coat color templates workable. We'd have to put both versions on every color article, but nearly all the colors (other than the gray/grey spelling) are universal in the English-speaking horse world. Not sure why all that was needed? Montanabw^(talk) 18:31, 1 July 2011 (UTC)[reply]

Why would we need to put both on every article? Use one or the other depending on the spelling used in that particular article. Tricoloured (horse), for example, uses "colour". We should be consistant. JIMp_talk·cont 11:42, 3 July 2011 (UTC)[reply]

(talk page stalker) Color & gray are AE; colour & grey are BE (Oxford American Dictionary). See WP:ENGVAR for the ruling - generally, if it's an international topic, it depends on the style used by the creator or first major contributor. If it is a country specific topic, then the orthography of that country should be used. If it's a quote from an original text, it should remain unchanged. --Kudpung กุดผึ้ง (talk) 12:57, 3 July 2011 (UTC)[reply]

Yes. JIMp_talk·cont 13:00, 3 July 2011 (UTC)[reply]

No one is debating that issue I don't think-- the problem is, I think, that we now have TWO navbox templates doing the same thing (Template:Equine coat colors‎ and Template:Equine coat colours . This is my concern. I see no reason to have to have two templates, I for one am not mortally offended by sometimes having to navigate UK English when I am a US English user, in fact, it's probably good for me! Montanabw^(talk) 00:57, 4 July 2011 (UTC)[reply]

I'll tell you what. I'll just delete the second version & make the original work via a spelling parameter. I thought you might have liked the simplicity of using {{Equine coat colours}} without the need for the additional parameter. JIMp_talk·cont 01:09, 4 July 2011 (UTC)[reply]

OK with me as long as we have just one template. I can't say I'm fond of the spelling parameters at all (I think people should learn to deal with the UK and US forms both, personally) but if you can make the syntax work, I'm OK with it. Montanabw^(talk) 19:56, 5 July 2011 (UTC)[reply]

Yes, people should learn to deal with it but it's still bad style to have them both on the one page. JIMp_talk·cont 22:54, 5 July 2011 (UTC)[reply]

re: Fortnight

Hello, Jimp. You have new messages at Talk: Fortnight.
Message added 16:12, 19 July 2011 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

when you stated the ratio 1477:50, I scratched my head for a bit, then a lightbulb went off. Thanks for taking the time to help me understand the issue. --TimL (talk) 22:03, 19 July 2011 (UTC)[reply]

Infobox basketball player

Did you know that by changing it to the ^{[convert: needs a number]} it now gives the wrong weights for the basketball players? It is now wrong, because it is not converting the weights properly. The same with the basketball team rosters. Just so you know.173.216.232.76 (talk) 09:05, 24 July 2011 (UTC)[reply]

How is it wrong? JIMp_talk·cont 22:55, 26 July 2011 (UTC)[reply]

DB-A1 and DB-A3

Hi. Would it be possible to either create new templates or modify the existing templates so when an article is tagged DB-A1 or DB-A3, it is only added to the speedy deletion category after an hour has passed? Maybe even add a message similar to the PROD template saying "An hour has passed since this article was tagged"? I've seen quite a bit of discussion that A1 and A3 get tagged too quickly. However, if we wait an hour there is a chance the articles will slip through NPP. What do you think?--v/r - T P 00:00, 27 July 2011 (UTC)[reply]

It would require the db template to be dated. Users probably wouldn't be bothered dating them but a bot could do it (like Smackbot does). JIMp_talk·cont 00:50, 27 July 2011 (UTC)[reply]

I see. I thought it could automatically apply the timestamp, but I guess it'd have to be subst: which db-templates arn't.--v/r - T P 01:14, 27 July 2011 (UTC)[reply]

Re: Convert

Could you look at the last few comments at Template talk:Convert#Trouble with sortable=on and update the template if you think it's a good fix. Thanks. –droll [chat] 18:52, 28 July 2011 (UTC)[reply]

Nomination for deletion of Template:Nihongo/Help

Template:Nihongo/Help has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. —Farix (t | c) 22:23, 28 July 2011 (UTC)[reply]

Template:Nihongo/Help listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Template:Nihongo/Help. Since you had some involvement with the Template:Nihongo/Help redirect, you might want to participate in the redirect discussion (if you have not already done so). —Farix (t | c) 22:25, 28 July 2011 (UTC)[reply]

I think you may have broken Template:Convert/3

Something seems to have broken Template:Convert/3, and it now generates links to non-existent templates. For example, {{convert/3 |5|by|6|by|7|m|ft}} now gives 5 by 6 by 7 Template:Convert/LoffAnoneDunitSoff (Template:Convert/LoffAnoneDoutput number onlySoff by Template:Convert/LoffAnoneDoutput number onlySoff by 23 ft). I have a feeling that it has something to do with this edit of yours, as it only seems to have happened since then, but I could be wrong; I don't have the privileges to edit the page, so can't undo the edit to make sure. If possible could you take a look at it and try to fix it (whether your edit caused it doesn't really matter, it needs to be fixed one way or another). I have also posted a message similar to this on the talk page, so you may well be beaten too it. Thanks, Alphathon /'æl.f'æ.θɒn/ ^(talk) 00:37, 3 August 2011 (UTC)[reply]

Thanks. I've reverted the edit till I can look into it further. JIMp_talk·cont 00:43, 3 August 2011 (UTC)[reply]

Currently: {{convert/3|5|by|6|by|7|m|ft}}

'abbr=none' versus 'abbr=off'

Please comment at Wikipedia:Bots/Requests for approval/Lightbot 17 so I can finish off migrating 'abbr=none' to 'abbr=off'. Regards Lightmouse (talk) 18:40, 4 August 2011 (UTC)[reply]

metric tons and tonnes

Hi,

I just noticed HMS Prince of Wales (R09) says 'metric tons' rather than 'tonnes'. I'd like to do a bot run on British English articles and set them to tonnes. It's a bit tedious to track them down via the Wikipedia database. Is there an easy way via 'what links here' from one of the convert sub templates? Lightmouse (talk) 18:24, 8 August 2011 (UTC)[reply]

I think the following is the full list of subtemplates which produce "tonne"/"t"/"metric ton".

Template:Convert/t (edit | talk | history | links | watch | logs)
Template:Convert/t(TNT) (edit | talk | history | links | watch | logs)
Template:Convert/t-f (edit | talk | history | links | watch | logs)
Template:Convert/tTNT (edit | talk | history | links | watch | logs)
Template:Convert/t LT (edit | talk | history | links | watch | logs)
Template:Convert/t LT ST (edit | talk | history | links | watch | logs)
Template:Convert/t ST (edit | talk | history | links | watch | logs)
Template:Convert/t ST LT (edit | talk | history | links | watch | logs)
Template:Convert/tf (edit | talk | history | links | watch | logs)
Template:Convert/toe (edit | talk | history | links | watch | logs)
Template:Convert/ton (edit | talk | history | links | watch | logs)
Template:Convert/tonTNT (edit | talk | history | links | watch | logs)
Template:Convert/tonne (edit | talk | history | links | watch | logs)
Template:Convert/MT (edit | talk | history | links | watch | logs)
Template:Convert/MTON (edit | talk | history | links | watch | logs)
Template:Convert/LT ST t (edit | talk | history | links | watch | logs)
Template:Convert/LT t (edit | talk | history | links | watch | logs)
Template:Convert/LT t ST (edit | talk | history | links | watch | logs)
Template:Convert/ST LT t (edit | talk | history | links | watch | logs)
Template:Convert/ST t (edit | talk | history | links | watch | logs)
Template:Convert/ST t LT (edit | talk | history | links | watch | logs)

JIMp_talk·cont 23:39, 8 August 2011 (UTC)[reply]

Times

I believe template:minus should be deleted for the same reason as template:times. In fact, that one nearly (if not entirely) unused. 198.102.153.2 (talk) 22:33, 8 August 2011 (UTC)[reply]

I agree. At least there doesn't seem to be templates for plus and divided by. Though I did find {{div}}, which, after five years is unused. JIMp_talk·cont 23:07, 8 August 2011 (UTC)[reply]

Guidance in mosnum about upper/lower case

Hi, I noticed you editing one of the two sections about upper/lower case:

Unit names, even those named after people, are common nouns. They are not capitalised when written in full, except where common nouns take a capital. Write The pascal is a unit of pressure, not The Pascal is a unit of pressure. The kilogram calorie is no exception. In degree Celsius and degree Fahrenheit, the d is not usually capitalised, but the C and the F are. (The common noun is degree, Celsius being a proper adjective.)
Unit symbols/abbreviations, apart from those listed below, are written in either non-alphabetic characters or in lower-case letters unless they are derived from a proper name, in which case the first letter is a capital letter.[4] (This applies to the unit itself, not its prefix).

Those two sections add value only where the 'Specific units' table and statements about the SI brochure are insufficient. You and I have both contributed to the text but now I notice it goes well beyond:

documenting the outcome of a dispute that may reoccur
defining how to fix a common and significant problem that wouldn't be fixed by the wiki
making a difference to what editors actually do

I'd like to replace those two guidance bullets with something like:

"Units names and symbols/abbreviations should be written in lower case unless otherwise specified in the SI brochure or this manual of style."

or simply delete them and say nothing. What do you think? Lightmouse (talk) 11:01, 10 August 2011 (UTC)[reply]

Sounds good to me though I would include the bit about "except where common nouns take a capital" otherwise we might see editors taking things too literally. JIMp_talk·cont 11:09, 10 August 2011 (UTC)[reply]

Oh dear. I can't think of how to make that succinct.

"Unit names are common nouns. Write them in lower case except where: common nouns take a capital; otherwise specified in the SI brochure; otherwise specified in this manual of style. Unit symbols/abbreviations should be written in lower case except where: otherwise specified in the SI brochure; otherwise specified in this manual of style.

How about I put that at mosnum talk? Lightmouse (talk) 11:55, 10 August 2011 (UTC)[reply]

Template:Sup2/doc

Following your deletion of sup2 and sup3. I see there is [Template:Sup2/doc] and [Template:Sup3/doc] that no longer have any value. I don't know if there are any more associated templates. Lightmouse (talk) 23:31, 14 August 2011 (UTC)[reply]

Thanks. JIMp_talk·cont 00:26, 15 August 2011 (UTC)[reply]

I've disposed of them and looked through "Special pages" couldn't see any other related pages. JIMp_talk·cont 00:30, 15 August 2011 (UTC)[reply]

Thanks. Lightmouse (talk) 13:12, 15 August 2011 (UTC)[reply]

Edittools

Hi Jimp. Could you read this please? I thought you might help me. --Zack (talk) 18:53, 23 August 2011 (UTC)[reply]

Template:Convert/list of units/area/Middle Eastern/varsp

Do you still need this? — This, that, and the other (talk) 01:15, 3 September 2011 (UTC)[reply]

Nope. I s'pose there's got to be a better way of listing such things. Of course, this is just one H
₂O molecule in the iceberg of unused subtemplates of convert (not even your extensive list covers it all). I'm working on it, slowly but surely, as I try restructuring the template. I've already axed hundreds but there are hundreds (maybe thousands) to go. JIMp_talk·cont 17:54, 3 September 2011 (UTC)[reply]

Infobox lake

Please could you attend to the request at Template talk:Infobox lake#Edit request from Lightmouse, 28 September 2011. Thank you — Martin (MSGJ · talk) 12:33, 30 September 2011 (UTC)[reply]

Yes, I'd had a look at it. I was trying to figure out what's going on. JIMp_talk·cont 23:35, 2 October 2011 (UTC)[reply]

Parser function error

Can you work out why Rosental an der Kainach is giving a parser function error? Thanks. Lightmouse (talk) 09:09, 3 October 2011 (UTC)[reply]

I don't see the parser function error (in IE). JIMp_talk·cont 00:51, 4 October 2011 (UTC)[reply]

It was apparently in 'Infobox Ort in Österreich'. I see it that was edited by user:Frietjes a few hours before you got there. Thanks. Lightmouse (talk) 09:41, 4 October 2011 (UTC)[reply]

List of elevation extremes by country

In converting the List of elevation extremes by country from Template:Moft to Template:Convert you managed to destroy the table sorting capability. Please try to be more careful.

As an aside, trying to turn Wikitext into structured code seems to be an exercise in futility. Yours aye, Buaidh 16:56, 13 October 2011 (UTC)[reply]

When you move a template, you are responsible for updating all of the template documentation and all of the template invocations. If you do not know how to do this, please ask me before you start moving things about. All of your changes were strictly cosmetic, and yet you really messed several templates and tables up. Please be more discerning. Yours aye, Buaidh 22:00, 17 October 2011 (UTC)[reply]

Thanks, I've had a look. I see what you mean. I'll be on the look out for sorting errors. JIMp_talk·cont 23:16, 17 October 2011 (UTC)[reply]

Template:Weather box

Hey, just so you know, after your last update it appears the yearly average high, mean, and low temperature boxes have lost their coloring. See Salina, Kansas#Climate or Norman, Oklahoma#Climate. Also, I left a question at Template talk:Weather box#Sandbox. Thanks, Ks0stm ^{(T•C•G•E)} 02:36, 26 October 2011 (UTC)[reply]

I'll check it out. JIMp_talk·cont 03:08, 26 October 2011 (UTC)[reply]

There's a problem with the precision of conversion and with averages being calculated. Can you look at Template talk:Weather box#Rainfall conversion and Template talk:Weather box#Issues with recent overhaul. Cheers. CambridgeBayWeather (talk) 21:23, 6 November 2011 (UTC)[reply]

Disambiguation link notification

Hi. In Australian English phonology, you recently added a link to the disambiguation page Pitch (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. For more information, see the FAQ or drop a line at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 13:42, 6 December 2011 (UTC)[reply]

Template:College Athlete Recruit Entry

At Jabari Parker, {{College Athlete Recruit Entry}} is giving an error because the commitment date is TBA. Is there anything I can do?--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 21:00, 14 December 2011 (UTC)[reply]

I put an {{#iferror:}} in there. It looks like it's fixed the problem. Let me know if I've broken something else. JIMp_talk·cont 06:39, 15 December 2011 (UTC)[reply]

Looks good. Thanks.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 07:38, 15 December 2011 (UTC)[reply]

Disambiguation link notification

Hi. In St. Johann in Tirol, you recently added a link to the disambiguation page Barrack (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:53, 15 December 2011 (UTC)[reply]

Disambiguation link notification

Hi. When you recently edited Jalopy, you added a link pointing to the disambiguation page American slang (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:54, 26 December 2011 (UTC)[reply]

Disambiguation link notification

Hi. When you recently edited Variation in Australian English, you added links pointing to the disambiguation pages Pitch and Articulation (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:48, 8 January 2012 (UTC)[reply]

Template:Convert

Hi, Am quite a novice in Wikipedia. I was working on some pages and I stumbled upon Template:Convert. Could you please explain the coding of it. It was very complicated and I was at loss in understanding the functionality of it. Specifically, if you can explain the convert|value|kg|lb, it would be very helpful. Thanks in advance. - Pasaban (talk) 12:30, 11 January 2012 (UTC)[reply]

First of all, thanks a ton for your prompt reply! Am sorry that I could not make myself clear. I think I know how to use that template, my question was about the coding. Am a regular translator to Bengali (bn) wiki. And I was trying to replicate Template:convert over there. now the problem is the numerics in Bengali are not latin so 1 is ১, 3 is ৩, 5 is ৫ and so on. So if I directly copy that template and try to use, say, {{convert|150|kg|lb}} it should give me ১৫০কেজি (৩৩০ পাউন্ড) (in English 150 kilograms (330 lb)). Instead it is giving me ১৫০কেজি (. পাউন্ড). It seems to me that the convertion from 150kg to 330lbs are not happening because of this numeric mismatch. My question is to know how this complex Templete works. I see there are lot of nested templates that are getting called from within this template. I tried to travarse and got lost! Please help so that I can create one for my mother tongue. - Pasaban (talk) 08:50, 13 January 2012 (UTC)[reply]

Sorry to disturb again. [I told you am novice ;)] I saw those subtemplates but they are not leading me to anywhere. I might be missing something. I would prefer to "step debug" through the code. Tried with the Special:ExpandTemplates but did not help me much. The problem is say, {{Convert/kg}} gives me the code as, {{convert/{{{d}}}|{{{1}}}|||||||s=|r={{{r}}} |u=kg |n=kilogram |o=lb |b=1 |j=0-0}}. All I can understand is within 3 curly braces are the variables, d, 1 and r. Apart from that rest is Hebrew to me. e.g. What does u=kg means? If I change the expression of j=0-0 to any other value how it will affect? This problem I am having for the other subtemplates that you mentioned as well. I know it would be tidious for you to explain in this detail. Is there any dev environment that I can use to test my templates( please don't tell me about the sandbox, am uncomfortable there.)? Else can you just give me one flow in every minute detail? May be we can have this - {{convert|150|kg|ib}}. Too much asking. Apologies for that upfront... - Pasaban (talk) 08:59, 17 January 2012 (UTC)[reply]

Great idea! I was also thinking in the same line. Saw the transwiki is not complete. But, given the size and complexity of {{Convert}} its an herculean task! If you guide me a little in that; I would be happy to help. - Pasaban (talk) 09:13, 19 January 2012 (UTC)[reply]

Thanks a ton that you took the pain to look into the {{Convert}} in Bengali wiki. I tried to reply in the talk (আলোচনা) page of the same to your queries. Please help. - Pasaban (talk) 07:42, 16 February 2012 (UTC)[reply]

Glad to help. JIMp_talk·cont 07:50, 16 February 2012 (UTC)[reply]

More unneeded Convert subtemplates

I see you have reused many unused subtemplates. I found another 9 unused for "!!" - see: Special:PrefixIndex/Template:Convert/!. My focus in removing templates is to avoid confusion. I formerly thought Convert's 3,000 subtemplates as being a lot, until I found people creating thousands of "lookup templates" such as 9,950 templates for ISO 3-character location codes, perhaps headed to 17,000 templates someday. Hence, now, I just worry about templates that lead people astray. It is getting difficult to convince people to not create 4,500 templates for any set of special codes or flags of cities, etc. Heck, people could easily create 55,000 templates to show a U.S. town name for each postal template {ZIP_code_43210}, so there's no stopping people from hashing every id code as one of thousands of similar template names. Meanwhile, I am still working to "fix" Convert problems, such as the e3/e6/e9 engineering units in ranges for water-flow volumes. Every time I see a "{u}" I recode to default {u} to {n} or "{{{n}}}s" so that "acre" can be handled without needing the "Na" subtemplates (Convert/LoffAoffDbSoffNa, etc.). If we rid Convert of the "Na" subtemplates, that will be a whole subset gone, while still retaining the other super-sleek Convert subtemplates. -Wikid77 (talk) 02:15, 17 January 2012 (UTC)[reply]

Yes, instead of just deleting them I'm recycling. This way the history is still there as is the coding, just in case there's an interest in or a need for it. Yes, the Nas can eventually be disposed with but it seems to me that we ought not just scratch away at these three thousand subpages bit by bit but rebuilt the whole thing. As you know, I'd made a start on this. I've been meaning to get back to it. JIMp_talk·cont 03:23, 17 January 2012 (UTC)[reply]

Disambiguation link notification

Hi. When you recently edited List of acronyms and initialisms: L, you added links pointing to the disambiguation pages LB and LBS (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 11:21, 1 February 2012 (UTC)[reply]

Template move

You moved Template:Convert/Dual/LoutAnoneDcommaSoff to TTemplate:Convert/m3/ha (note the double TT). Can you check if that was correct of if you mean to move it to Template:Convert/m3/ha. -- WOSlinker (talk) 07:47, 7 February 2012 (UTC)[reply]

Well spotted. Thanks. JIMp_talk·cont 16:47, 7 February 2012 (UTC)[reply]

MSU Interview

Dear Jimp,

My name is Jonathan Obar user:Jaobar, I'm a professor in the College of Communication Arts and Sciences at Michigan State University and a Teaching Fellow with the Wikimedia Foundation's Education Program. This semester I've been running a little experiment at MSU, a class where we teach students about becoming Wikipedia administrators. Not a lot is known about your community, and our students (who are fascinated by wiki-culture by the way!) want to learn how you do what you do, and why you do it. A while back I proposed this idea (the class) to the community HERE, where it was met mainly with positive feedback. Anyhow, I'd like my students to speak with a few administrators to get a sense of admin experiences, training, motivations, likes, dislikes, etc. We were wondering if you'd be interested in speaking with one of our students.

So a few things about the interviews:

Interviews will last between 15 and 30 minutes.
Interviews can be conducted over skype (preferred), IRC or email. (You choose the form of communication based upon your comfort level, time, etc.)
All interviews will be completely anonymous, meaning that you (real name and/or pseudonym) will never be identified in any of our materials, unless you give the interviewer permission to do so.
All interviews will be completely voluntary. You are under no obligation to say yes to an interview, and can say no and stop or leave the interview at any time.
The entire interview process is being overseen by MSU's institutional review board (ethics review). This means that all questions have been approved by the university and all students have been trained how to conduct interviews ethically and properly.

Bottom line is that we really need your help, and would really appreciate the opportunity to speak with you. If interested, please send me an email at obar@msu.edu (to maintain anonymity) and I will add your name to my offline contact list. If you feel comfortable doing so, you can post your name HERE instead.

If you have questions or concerns at any time, feel free to email me at obar@msu.edu. I will be more than happy to speak with you.

Thanks in advance for your help. We have a lot to learn from you.

Sincerely,

Jonathan Obar --Jaobar (talk) 07:23, 12 February 2012 (UTC)[reply]

Population density

Hello! I saw that you added a new code in this template. However, there are now too many decimal places for the population density. Example: for Rajasthan, population density= 200.48854/km2. I think that two digits are enough. 200.50 would be good. Maybe you can fix this. Thank you very much! Mightymights (talk) 10:57, 24 February 2012 (UTC)[reply]

I've tweaked the code a little. JIMp_talk·cont 15:12, 24 February 2012 (UTC)[reply]

Thank you! Mightymights (talk) 17:06, 24 February 2012 (UTC)[reply]

area in hectares or acres

hello Jimp. I have been working on Template:Infobox Townlands/sandbox as a replacement for the current version, and one thing that came up is that template:Infobox settlement does not have support for area in acres or hectares. I thought I remembered you mentioning this before, so I was wondering if it would be possible to add say 'area_total_ha' to 'infobox settlement' and have it default to converting this unit to acres, and conversely for say 'area_total_acres'. If it's not possible, then my current version does work, so we can probably work around it. thank you. Frietjes (talk) 21:56, 28 February 2012 (UTC)[reply]

Of course it would be possible to add this. I'll see whether I can have a look. JIMp_talk·cont 23:39, 28 February 2012 (UTC)[reply]

I've added hectares and acres to the template. It doesn't as yet have the capacity to calculate density from these though. JIMp_talk·cont 05:00, 2 March 2012 (UTC)[reply]

template:chem

Documenting a template stuff

Instead of making "See also" sections in Special:PrefixIndex/template:chem/disp templates, would you explain in which conditions and with which parameters have these to be called? I tried to fix one of your bugs, but bogged for a hour due to complete lack of documentation on the {{chem}} internal structure. Incnis Mrsi (talk) 22:15, 28 February 2012 (UTC)[reply]

Well, since you ask so nicely ... JIMp_talk·cont

Revert

You should revert this, for now; Uranium#Aqueous chemistry is broken; another example on the chem talk page. It's not handling sup-tags and whatever this is with italics. Alarbus (talk) 12:51, 1 March 2012 (UTC)[reply]

Done. Thanks. JIMp_talk·cont 12:58, 1 March 2012 (UTC)[reply]

Good luck with it. Alarbus (talk) 13:07, 1 March 2012 (UTC)[reply]

Thanks again. Actually the Uranium calls were incorrect but the italicized subscripts are another beast. Well, I got 'em working once ... JIMp_talk·cont 13:12, 1 March 2012 (UTC)[reply]

No problem; I'm not familiar with this template or its use, I'd done some other edits on the U page and happened to notice the red, then found the template had changed. The italics was apparent on the talk. Alarbus (talk) 13:17, 1 March 2012 (UTC)[reply]

I see what you mean (at template:chem/testcases). I think I've found a solution. JIMp_talk·cont 13:25, 1 March 2012 (UTC)[reply]

It's looking better now. JIMp_talk·cont 13:33, 1 March 2012 (UTC)[reply]

Glad you got it sorted-out. I'll keep this in mind and drop it in anywhere I find ham-handed formula. Alarbus (talk) 13:46, 1 March 2012 (UTC)[reply]

Beaut. JIMp_talk·cont 14:30, 1 March 2012 (UTC)[reply]

Worried about unprotected subtemplates

Perhaps full-protect more. As proven when the string-handling templates were unprotected, then vandalized within months, an unprotected subtemplate is a magnet for troubles. Some fraction-subtemplates in the following might need full protection:

Template:Convert (view source) (protected)
Template:Convert/LoffAoffDbSoff (view source) (protected)
Template:Convert/LoffAonSoff (view source) (protected)
Template:Convert/ft (view source) (protected)
Template:Convert/m (view source) (protected)
Template:Convert/numdisp (view source) (protected)
Template:Convert/numdisp/frac (edit) (semi-protected)
Template:Convert/numdisp/frac1 (edit) (semi-protected)
Template:Convert/outsep (view source) (protected)
Template:Convert/round (view source) (protected)
Template:Convert/test/A (view source) (protected)
Template:Max (view source) (protected)
Template:Order of magnitude (view source) (protected)
Template:Order of magnitude/x (view source) (protected)
Template:Precision/2010 (view source) (protected)
Template:Precision/a (view source) (protected)
Template:Rnd (view source) (protected)
Template:Rnd/- (view source) (protected)

I guess look at the edit-history of fraction subtemplates to ensure no vandalism already. -Wikid77 (talk) 04:07, 13 March 2012 (UTC)[reply]

I agree. JIMp_talk·cont 13:44, 13 March 2012 (UTC)[reply]

Dts

Your edits to this template seem to be perfectly fine, but have uncovered all the pages using it improperly. If you check Category:ParserFunction errors you will see that it went from around 30 pages to over 200. I have fixed some of them, but I probably don't have time to fix them all. I am going to see if there is an intermediate template calling dts that could be fixed to reduce the number. 129.237.222.129 (talk) 18:16, 25 April 2012 (UTC)[reply]

It looks like a bunch could be fixed by modifying Template:NRHP row to bypass {{dts}} if the input is not a date. The manual work around is to change the bad ones from |date= to |date_extra=. 129.237.222.129 (talk) 18:27, 25 April 2012 (UTC)[reply]

It looks like there is no manual work around, but we can fix the template, see Template talk:NRHP row. 129.237.222.129 (talk) 18:40, 25 April 2012 (UTC)[reply]

Thanks, I hope the modification fixes the problem. JIMp_talk·cont 23:11, 25 April 2012 (UTC)[reply]

Hello. It seems that what the template previously presented as "July 25, 2012" is now being presented as "Jul 25, 2012", i.e. the month name is truncated. Could you please have a look?

Thanks. HandsomeFella (talk) 13:59, 27 April 2012 (UTC)[reply]

It's the same for the intnational format: "25 Jul 2012" instead of "25 July 2012". HandsomeFella (talk) 14:10, 27 April 2012 (UTC)[reply]

Are you going to do anything about this? HandsomeFella (talk) 16:49, 6 May 2012 (UTC)[reply]

No ... I've already reverted this change. JIMp_talk·cont 16:51, 6 May 2012 (UTC)[reply]

Help, if you have the time

Hi Jimp! Sorry to bother you, but I could use a bit of your background knowledge on something. I'm trying to figure out the status of Convert subtemplates on the Simple English Wikipedia. We recently finished importing pretty much all the subtemplates, but we now have about 360 more templates than you guys do over here (but about 1200 less redirects).

I've compiled a set of four lists at User:Osiris/convert lists. Basically I'm looking to find out which of our extras we can delete as being obsolete. Wikid77 told me that simplewiki was sometimes used as a testing ground for updates, so I'm not about to go deleting hundreds of templates without the nod from you guys. But I also want to get rid of any old ones lying around that have been completely replaced.

I'd also love to know which redirects I can skip over, but I realise that's probably not something anyone is able to answer.

This is very much a "when you have time" issue in the most literal sense, but any direction you could give me on this would be really helpful. Best regards, Osiris (talk) 05:16, 27 April 2012 (UTC)[reply]

I have been working on another rewrite but (of course) progress is slow so I can promise anything but if I get it up & running, thousands of subtemplates can be expected to to become redundant. I've already started deleting many. One set of subtemplates I'm currently attacking are the ones for slashes e.g. {{convert/LoffAoffDsSoff}}, {{convert/LoffAoffDslashSoff}} {{convert/LoffAoffD/Soff}} (three different ways of getting that useless slash). Basically, though, pretty much anything that isn't used is up for deletion. Perhaps you could use the "what links here" and if a subtemplate is hardly used or not used at all on this wiki you probably don't need it. There are hundreds (thousands) of pages for options that nobody has ever needed. This also might be useful.

JIMp_talk·cont 06:02, 27 April 2012 (UTC)[reply]

Oh cool, it'd be good to see the numbers reduced. If you think it's okay then to delete the ones in this list, none of which are obviously in use here, then I'll probably go ahead and do that after I've checked their usage. I just wanted to make sure I wasn't getting rid of anything you guys might've needed. Thanks, Jimp! Osiris (talk) 15:05, 27 April 2012 (UTC)[reply]

Currently we're eliminating a bunch of special templates for imperial and US capacities. JIMp_talk·cont 07:44, 13 May 2012 (UTC)[reply]

Please include an edit summary

Hi, just a reminder to please use an edit summary on your edits, preferably something specific. Thanks! --Dennis Bratland (talk) 21:21, 11 May 2012 (UTC)[reply]

Fix single-brace in Template:Convert/l_usgal ‎

A recent change to protected Template:Convert/l_usgal added 3 typos of single-brace "U{#ifeq" which should be double-brace U{{#ifeq for all 3 if-expressions. -Wikid77 (talk) 05:55, 13 May 2012 (UTC)[reply]

thanks JIMp_talk·cont 05:57, 13 May 2012 (UTC)[reply]

Fixed unclosed markup in talk-page

Above, in the thread "x to y template" of your May 2012 talk-page, there had been an invalid, unclosed markup curly bracket which was eating text down at this level. It was an unclosed template call (coded in "Templates like '{{oz to g|'"), and I changed it to use single curly brackets ("{oz to g}") instead. It is now safe to archive that thread, and it will not eat later template-example topics appended into the archive. Examples of Convert will work here now:

{{convert|3|-|7|impgal|lk=out}} → 3–7 imperial gallons (14–32 L; 3.6–8.4 US gal)

In general, if lower threads disappear, it is often caused by an unclosed template call near the final line displayed before text disappeared. However, it is triggered by a lower thread containing an unmatched "}}" which most users would not likely put in the text. -Wikid77 14:57, 15 May 2012 (UTC)[reply]

Thanks. JIMp_talk·cont 08:17, 16 May 2012 (UTC)[reply]

Template:Template:Convert/Nm lbfft

did you mean to move this template to Template:Template:Convert/Nm lbfft? seems like one too many templates. 198.102.153.2 (talk) 21:45, 16 May 2012 (UTC)[reply]

Thanks for that. No, that wasn't right. JIMp_talk·cont 07:39, 17 May 2012 (UTC)[reply]

New Template:Convert/pre54USnmi replaces 3

In updating to the current options of Convert, I created shorter unit-code "pre54USnmi" which handles "sp=us" to allow removing the 3 unused variations:

The trick, in new Template:Convert/pre54USnmi, was to allow "sp=us" by the typical {{#ifeq:{{{r}}}|re|US|U.S.}}. I changed the one article "Outer Continental Shelf" and updated the documentation in Template:Convert/list_of_units/length/maritime (padding for the rowspan=7). No hurry on removing the 3 unused alternate subtemplates, just whenever. -Wikid77 07:35, 31 May 2012 (UTC)[reply]

Yes, ... mmm ... here's the thing ... um ... I'd got to thinking that maybe this whole sp=us for dots was a kind of convoluted not-qiute-so-sensible idea in the first place ... I'd got to thinking that it kind of made things simpler to put dots in if you want dots and to leave them out if you don't ... is it worth the extra template on our end? The extra template saves a bunch of code ... I'd been getting rid of those lower-case us templates when I'd come across unused ones ... I dunno do you think this is actually the way to go? Looking more to the future, might we even have a dots parameter (dots=on for "U.S.")? JIMp_talk·cont 08:24, 31 May 2012 (UTC)[reply]

Americans have spelled as "U.S." - I know the "times they are a changin'" but historically, the spelling as "U.S." (versus "US") has remained in the USA, like "color" versus "colour". The early books about the RMS Titanic sinking used the spelling as: R.M.S. "Titanic" or S.S. "Titanic" where I am not sure when undotted "RMS" became preferred in the UK. I think, to Americans today, "US" looks a lot like "US Magazine" (Us Weekly), but now the USGovt has "US Army" and "US Navy" so the dots might be fading faster in American culture, as well. Fortunately, Wikipedia is "not trendy" because articles contain old quotes from Ye Olden Tymes, where "U.S." was very common. We might need to run a Google Ngram (or such) to see if spelling "US" is gaining fast in the USA. So far, I think the option "sp=us" was wise. -Wikid77 09:07, 31 May 2012 (UTC)[reply]

Yes, and that's more or less why I made the us options in the first place ... however,

I don't think it really took off, judging by numbers of transclusions the US and U.S. options seem more popular.
This is perhaps because they are simpler (and the template is already somedeal on the complex side)
The us options can't really replace the US and U.S. options.

Dots vs no dots is not as clear-cut as "litre" vs "liter". WP may not jump on the newest trend but there is a trend towards dropping the dots. It's more advanced outside of North America but it's not unknown in US English. We could well imagine that an article written in US English but with "US". In such an article you'd want "375 milliliters (12.7 US fl oz)". On the other hand, you could imagine an article in Canadian English with dots where you'd want "375 millilitres (12.7 U.S. fl oz)". This would be impossible if we only had the us options. JIMp_talk·cont 18:26, 2 June 2012 (UTC)[reply]

I have got rid of {{convert/pre54USnmi}} along with {{convert/pre1954usnmi}} and intend to continue depricating using the sp parameter to dot or undot "US". JIMp_talk·cont 04:09, 20 September 2012 (UTC)[reply]

Recreated Convert/LinAinDbSoff and /Dual

I have recreated Template:Convert/Dual/LinAinDbSoff (plus non-Dual), this time with doctext to explain examples, for another user request in wanting to use both "abbr=in" with "lk=in" with a conversion. Logically, it is a very good option, for showing conversions to both old and novice readers who might want a wikilink for only the input unit symbol. -Wikid77 07:35, 31 May 2012 (UTC)[reply]

Fair enough. I'd been just shaving off the excess. I'd basically made the assumption that lack of use indicates lack of usefullness. Sometimes this is not true and we incur collateral damage. Thanks for fixing things up. JIMp_talk·cont 08:28, 31 May 2012 (UTC)[reply]

Template:Bbl to t

Hi. Could you take a look on Template:Bbl to t. Can't fix the vandalism by anon user. Beagel (talk) 13:43, 2 June 2012 (UTC)[reply]

sure. JIMp_talk·cont 13:44, 2 June 2012 (UTC)[reply]

Template vandalism is nasty. Thanks to both of you for finding the problem and fixing it! ☮Soap☮ 13:49, 2 June 2012 (UTC)[reply]

The vandalism to {{sigfig}} (used by {{bbl to t}}) is reverted, the page protected & the anon blocked. Has that solved the problem? JIMp_talk·cont 13:51, 2 June 2012 (UTC)[reply]

Thank you for your keen eye and speedy work! I appreciated Cruel Mrs. Tyrant, but not when her bondage school distracts me from editing. Have to wonder if IPs should be editing templates at all. - ʄɭoʏɗiaɲ ^τ _¢ 13:54, 2 June 2012 (UTC)[reply]

Thank you. Beagel (talk) 14:04, 2 June 2012 (UTC)[reply]

No worries. JIMp_talk·cont 18:04, 2 June 2012 (UTC)[reply]

Time Zones and Time Offsets

Hi, Jim. I'm glad to have a collaborator on the time zone templates, especially the ones that make calculations or show different text based on "if-then-else" logic. And I don't want to ignore Australia.

My plan is to start with my own time zone, move west to finish the US states, then go east to finish North America (Canadian provinces). After that, I'd like to tackle the rest of the Americas, or maybe work on other parts of the English-speaking world. Oh, yes, may as well do Europe too.

Finally, I would like every time zone that observes daylight savings time to be fixed up. The goal in all of this is to minimize the amount of time it takes a reader to figure out:

what time is it, in a certain (major) location
what daylight saving rules are in effect there (or soon will be)
what's the time offset from where I am to where my friend is

I hope we can work together on these things, or anything else of mutual interest. --Uncle Ed (talk) 15:38, 4 June 2012 (UTC)[reply]

Sounds great. The before-after daylight savings template could be extended (did I mention that) to the whole Northern Hemisphere (note, of course, it would make no sense down south since it's never before DST; you'd want a before-after standard time for the Southern Hemisphere). Also the time zone infobox could be globalised. Now I've started wading through the time and date templates and I notice is that there's a lot of cleaning up to do. JIMp_talk·cont 09:51, 5 June 2012 (UTC)[reply]

Cool

Thanks for the update of {{ISOCALENDAR}}. I would have preferred that {{CURRENTCALENDAR}} was kept (didn't see this before now ) since the name is much more common than ISOCALENDAR. Would you restore it with history? It's still linked by no:CURRENTCALENDAR. Great that the PHP 5.1 functionality has been added as requested here Request #time-parameter o - ISO-8601 year number! {{#time:o-\WW-N}}: 2024-W47-2 Nsaa (talk) 09:41, 7 June 2012 (UTC)[reply]

I restored the template and moved it to your user space (hope you don't mind my meddling in your space). If CURRENTCALENDAR is a better name than ISOCALENDAR, let's move it. On the other hand, calling it ISOCALENDAR does justify the week numbering and beginning the week with Monday (where calendars in English-speaking regions traditionally start the week with Sunday) and makes it less likely to be confused with {{calendar}}. Then on the other other hand, the name ISOCALENDAR might be taken to imply that we're reproducing a calendar according to ISO specifications and are we or are we just making a calendar of our own design featuring some ISO elements? JIMp_talk·cont 23:09, 7 June 2012 (UTC)[reply]

Spotted missing parameters 7-8 for Convert ft-in

Okay, I finally noticed Convert is missing {{{7}}} and {{{8}}} inside Template:Convert/and/in, so it should have "|{{{6|}}}|{{{7|}}}|{{{8|}}}" on line 1. Then, the following will pass parameters 7 and 8:

{{convert|6|ft|3|in|cm|1}} → 6 feet 3 inches (190.5 cm)

{{convert|6|ft|3|in|cm|disp=x| high [|] here|1}} → 6 feet 3 inches high [190.5 cm] here

When working correctly, then "here" will show at the end, and cm will have 1 decimal digit as "190.5". No hurry on this, because the conversion is inside a long "boring" quotation, as a painting's height, in article "Walter Lofthouse Dean" just edited. -Wikid77 (talk) 11:53, 7 June 2012 (UTC)[reply]

Done. Isn't 6 ft 3 in → 190.5 cm pushing it a little? 191 cm is already more precise than 6 ft 3 in. Might

"9 feet long by 6 feet 3 inches high [274 cm × 191 cm]"

instead of

"9 feet long [274 cm] by 6 feet 3 inches high [191 cm]"

do? It seems to flow better to me; I think it's clear enough that we're still talking height by length. JIMp_talk·cont 23:40, 7 June 2012 (UTC)[reply]

Rolled back your Onion edits

I rolled back your Onion edits as the term used by the Henderson MC is euthanasia, if I remember right. Also, this is the term used by most animal professionals to describe the killing of an animal. As to the rest of the language, it's all about tense. Either way is fine and the most recent edits were just fine. Quill and Pen (talk) 03:48, 18 June 2012 (UTC)[reply]

Thank you for the note on my talk page. Allow me to reply on the article's talk page. JIMp_talk·cont 03:57, 18 June 2012 (UTC)[reply]

You are most welcome. I will post a portion of the code to the discussion page. Quill and Pen (talk) 04:00, 18 June 2012 (UTC)[reply]

Rolled back one of your Onion (dog) edits as the ref tag was bad. The current page shows clean ref tagsQuill and Pen (talk) 05:02, 21 June 2012 (UTC)[reply]

Sorry about that, a bit of a typo, didn't have time to check that the edit would come out properly. It's fixed. P.S. I think the Wiki-jargon you're after is "revert", "rollback" has a special meaning. JIMp_talk·cont 06:34, 21 June 2012 (UTC)[reply]

Template:Convert/mpgus/sandbox for ranges

The "natives are restless" in wanting ranges of mpg, which is a very common unit, so the easiest fix has been to add {{{n}}}, {{{l}}} & {{{t}}} into new Template:Convert/mpgus/sandbox (also added parameters 5-8). Currently, because mpgus uses "{{{d}}}F" for output, the range showed a missing "{{{n}}}}s" which the sandbox version has now. After update, the following should look correct:

Expected: {convert |15|to|32|mpgus|l/100 km} → 15 to 32 miles per US gallon (16 to 7.4 l/100 km)
Currently: {convert |15|to|32|mpgus|l/100 km} → 15 to 32 miles per US gallon (15.7 to 7.4 l/100 km)

The 3 below should show "32 miles", singular "1 mile" and lk=on as "40 miles per US gallon" when fixed:

{convert |15|to|32|mpgus|l/100 km mpgimp} → 15 to 32 miles per US gallon (15.7 to 7.4 l/100 km; 18 to 38 mpg_‑imp)
{convert |15|to|1|mpgus|l/100 km mpgimp|sp=us} → 15 to 1 mile per U.S. gallon (16 to 235 l/100 km; 18.0 to 1.2 mpg_‑imp)
{convert |35|to|40|mpgus|l/100 km mpgimp|lk=on} → 35 to 40 miles per US gallon (6.7 to 5.9 l/100 km; 42 to 48 mpg_‑imp)

The sandbox fix is quick, simple, and people just expect "mpgus" ranges to be as simple as metres to feet, so this seems the easy way. Feel free to make adjustments, or another solution for ranges. Thanks. -Wikid77 (talk) 15:50, 20 June 2012 (UTC)[reply]

I've moved it onto {{convert/mpgus}}. JIMp_talk·cont 17:50, 20 June 2012 (UTC)[reply]

ENGVAR

Hi, whatever you do: stop your disruptions. You are spoiling a WORKING template system. At least you could start a talk. -DePiep (talk) 02:49, 22 June 2012 (UTC)[reply]

I wonder whether you may be over stepping the bounds of civility here. You certainly would not be if you can show that my edits to {{infobox element}} was indeed disruptive. If I'm being disruptive, please do show me where so that I can mend my ways. The plan was to fix this infobox. I offered to do so if it still remained unfixed. I came back and found the job half done. I decided to finish it off. I don't believe I was spoiling anything. Indeed after I'd finished "spoiling" this "working" system the infobox at Phosphorus was using centre, vapourisation and vapour as we should have hoped. Now that my disruptive edits are reverted it's back to the American center and vapor and the mongrel vaporisation. So, please, tell me who's spoiling what again. JIMp_talk·cont 03:10, 22 June 2012 (UTC)[reply]

P.S. I don't quite get what you mean by "start a talk". This whole thing stems from discussions currently in process. Of course you know this since we are both participating in these discussions. JIMp_talk·cont 03:16, 22 June 2012 (UTC)[reply]

(edit conflict)There was no talk at all about changing parameter names. ENGVAR was only about the text shown. You changed invisible parameter names from en-US to en-UK -- useless and senseless. Also, my {{engvar}} functions well. So you better cooperate to improve. Whatever your ideas are: they are not free. As for civility, going your own way like you did, without talking about a working, tested, and intended solution, I have no remorse for you. -DePiep (talk) 03:17, 22 June 2012 (UTC)[reply]

No, there was only talk about fixing the template. I came and found that it still needed fixing. I fixed it. Useless and senseless it may have been to fix it via parameter names but I did fix it. Now it's broken again. JIMp_talk·cont 03:31, 22 June 2012 (UTC)[reply]

Anyhow, there is an even better solution than either of these approaches. JIMp_talk·cont 03:37, 22 June 2012 (UTC)[reply]

No, there was only talk about fixing the template. I came and found that it still needed fixing. I fixed it. Useless and senseless it may have been to fix it via parameter names but I did fix it. Now it's broken again. JIMp_talk·cont 03:31, 22 June 2012 (UTC)[reply]

(edit conflict)

One. Here you change parameter names into en-UK spelling. Absolute nonsense, these are internal to the template, and will never show up in the article. And, of course, this is NOT what the talk page discussion was about. At all. NOONE asked to change the internal parameter names. Noone.

Two. Here you abuse {{engvar}}, clearly without knowing what it is about (while I wrote the tempate and the documentation today). Putting it in an #if: construct is nonsense. Your usage of {{engvar}} this way is stupid. Just read the documentation first, I'd say. And then really tell me what it does not solve.

Three. Here you are ranting and talking in a section that has a clear title: What words we should separate? Your talking does not answer a single question nor explain a single word in US-UK. If you do know something about say Canadian English in this -- write it down there. -DePiep (talk) 03:39, 22 June 2012 (UTC)[reply]

Four. No, there was nothing to fix. It worked yesterday, it worked after I introduced {{engvar}} (plus the feature), and in between it solved the request for 2-linguality. If anything might be broken, it was AFTER and BECAUSE you edited. -DePiep (talk) 03:45, 22 June 2012 (UTC)[reply]

One I've already conceded that it may have been useless and senseless to fix the template via parameter names. For infoboxes in general this would be a decent solution, use the parameter name to determine the spelling of the header. It's quite logical. What you see in edit mode is what you get. Of course, what I hadn't quite taken into account is the very perculiar set up we have here whereby the whole thing is tucked away on an element-specific infobox. No, noone asked me to do this, no. Noone asked me to contribute to Wikipedia at all. Did anyone ask you to create {{engvar}}? I did read the talk page. The discussion arrived at the idea that the template should be fixed. No, there was no disscussion about how it should be fixed. I had said I'd help out if it still needed fixing when I got back. I found that it did. I implimented a solution.

Two That edit in no way "abused" your template. It removed {{engvar}} altogether. I didn't put template {{engvar}} in an #if I put parameter {{{engvar}}} in the #if. Yes, I have read the documentation and the code. You'd like me to tell you what it does not solve. With due respect I will. It does not solve anything that couldn't be solved more simply with a #switch.

Three Sorry if I wasn't more clear. Things are straight-forward in America: it's -or (color, vapor, etc.), -er (centered) and -ize (ionize, etc.). Outside of America things aren't so simple. We use -our (colour, vapour, etc.) -re (centred) but -ize vs -ise (ionise, etc.) is optional. In Canada -ize is prefered wheras in other Commonwealth countries it's usually -ise though the Oxford Dictionary prefers -ize. So there are three possibilities not two.

US	(centered,	color,	vapor,	vaporization	& ionization)
Canada/Oxford	(centred,	colour,	vapour,	vapourization	& ionization)
UK/Aus/NZ/etc.	(centred,	colour,	vapour,	vapourisation	& ionisation)

There exists Germanium, Europium, Polonium, Francium, Americium, Californium, etc. maybe one day they'll rename um-dee-dum-ium "Canadium" ("Quebecium" or "Newfoundlandium"), we'd want vapourize.

Four If you noticed anything I broke, do point it out. As far as I can see my edits finished off the job you started. Yes, only started. I'm not sure how I'm failing to make myself clear but there was something to fix. Yes, it worked yesterday, it worked better after you introduced {{engvar}} and I worked better still after my edits. You improved things but didn't solve the whole probelm. The phosphorus infobox still had US spelling. My edits fixed that.

JIMp_talk·cont 07:27, 22 June 2012 (UTC)[reply]

Dram

The link also says "Dram is also used informally to mean a small amount of spirituous liquor, especially Scotch whisky". -- Ian Dalziel (talk) 02:02, 2 July 2012 (UTC)[reply]

English on a Diet? Not here...

Your changes are in the wrong Wikipedia. You want the Simple English Wikipedia. Of course, you could try changing every occurrence of 'calorie' into 'Food energy' everywhere here. I wonder how far you would get if you did it less quietly... 70.112.178.121 (talk) 03:38, 20 July 2012 (UTC)[reply]

Not wrong: there is energy you get from food called "food energy", and there are units we measure it with, one of which being the calorie. Perhaps you want the Colloquial English Wikipedia this one is meant to have a formal tone. JIMp_talk·cont 20:44, 24 July 2012 (UTC)[reply]

Finally reduce Convert expansion depth

Well, this is it today, the fix for Convert's 28-29 depth levels, which have caused people to complain endlessly. We have talked about it for years, so let's just update the major format templates and solve the problems quickly:

Template_talk:Convert#Reducing Convert depth for precision

Later, we can make similar fixes for ranges, and temperatures, but let's solve the major 85% of cases with just fixing /LoffAoffDbSoff & /LoffAonDbSoff now, to reduce those 273,000 articles within a few hours. -Wikid77 (talk) 18:47, 2 September 2012 (UTC)[reply]

Can reduce Convert to 17 or 22 levels: Wow, I have run some intricate formula tests by checking magnitude of result in both {Convert/round/sandbox} and also, higher, in {Convert/LoffAonSoff/sandbox} to avoid nesting into Convert/round if {~/pround} can handle the precision. The results were shocking, because using {~/pround} will run 17 deep, but using {~/round} will run only 22 deep, such as for rare precision "30 um (0.0012 in)". Here are 2 live results, using parameter "disp=p" to trigger the /sandbox versions:

{{convert|368|ft|m|disp=p}} → 368 feet (112 m)^* - uses {~/pround}

prec of 368: 0 Depth: 17
1-magnitude of 112: -1

{{convert|30|um|in|disp=p}} → 30 micrometres (0.0012 in)^* - uses {~/round} for tiny result

prec of 30: -1 Depth: 22
1-magnitude of 0.0012: 4

The updated subtemplates will need extra comments to explain the magnitude formula, because they no longer call {order_of_magnitude}, and the logic looks like just a mysterious math formula:

{{#ifexpr: {{{5}}} >= 1

- floor( (ln ( ( {{{2}}} )/{{{b}}} )/ln 10)+1E-14) |p}}round

Also, I want to run your other examples, which formerly returned result "0 cm" and similar. Then, we can prepare to update both Convert/LoffAonSoff and Convert/round, to use the one-line magnitude formulas and drop 6-11 more depth levels. Feel free to run other sandbox tests, if you have time, with "{{convert |xxx|ft|m|disp=p}" to check if any poor results. -Wikid77 (talk) 15:03, 3 September 2012 (UTC)[reply]

You introduce a fudge factor of 10⁻¹⁴ to sidestep the truncation error, avoid having to use the error check subtemplate {{order of magnitude/x}} and save three levels of transclusion depth.

The elephant

{{#ifexpr:{{{1|0}}}=0<!-- 
                   -->|0<!-- 
                   -->|{{order of magnitude/x<!--
                               -->|{{{1}}}<!--
                               -->|{{#expr:floor(ln(abs({{{1}}}))/ln10)}}<!--
                               -->}}<!--
                   -->}}

can be wittled away to a hippo

{{#ifexpr:{{{1|0}}}=0
   |0
   |{{#expr:floor((ln(abs({{{1}}}))/ln10)+1E-14)}}
}}

There is a very slight ... negligable ... trade-off here. For values 0.99999999999998 to 0.99999999999999994 the current {{order of magnitude}} correctly returns −1 whereas the new code gives 0. This error is far out-weighted by the reduction in depth, of course.

By putting the code in directly instead of calling external {{order of magnitude}} we reduce the depth by another level and the hippo becomes a cow (three levels deep).

Remember that {{order of magnitude}} pretends that the order of magnitude of zero is zero (allowing convert to treat 0 °C and 0 °F to be rounded to the nearest degree). There's one level. We're not going to want to get rid of this.

It looks good. I've just had a thought, though. We're treating 0 as if it were of order of magnitude 0. We should, then, treat 0.0 as if if were of order of magnitude −1, 0.00 as order of magnitude −2, etc., right? Maybe

{{#ifexpr:{{{1|0}}}=0
   |{{#ifexpr:{{{1|0}}}1=1
      |0
      |{{#expr:floor((ln({{{1}}}1)/ln10)+1)}}
    }}
   |{{#expr:floor((ln(abs({{{1}}}))/ln10)+1E-14)}}
}}

JIMp_talk·cont 11:38, 6 September 2012 (UTC)[reply]

I have put that algorithm in new {Template:magnitude}, to use in the /sandbox versions, where we could test a value of "0.000". -Wikid77 (talk) 11:34, 12 September 2012 (UTC)[reply]

How about moving {{magnitude}} to {{order of magnitude/sandbox}} since the above algorithm isn't really an alternative to the current one but more of a replacement? JIMp_talk·cont 08:01, 13 September 2012 (UTC)[reply]

I've created a test page for comparision of the old and new algorithms. JIMp_talk·cont 08:55, 13 September 2012 (UTC)[reply]

I have deleted {{magnitude}} and put its algorithm onto {{order of magnitude}}. JIMp_talk·cont 00:03, 27 September 2012 (UTC)[reply]

Deletions and protections

When you're deleting {{convert}} components to accomplish pagemoves, please be careful to reprotect them after deletion and undeletion are done; an IP vandalised Template:Convert/LoffAoffDbSoff today, and all I can guess is that you accidentally removed protection when you performed a histmerge there a few days ago. Nyttend (talk) 22:08, 6 September 2012 (UTC)[reply]

Thanks, there was another subtemplate in the same boat. I've reprotected it. JIMp_talk·cont 23:25, 6 September 2012 (UTC)[reply]

Disambiguation link notification for September 14

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited English wine cask units, you added a link pointing to the disambiguation page Wine cask (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 11:07, 14 September 2012 (UTC)[reply]

convert/table

see the edit request Template talk:Convert/table. 198.102.153.1 (talk) 00:11, 28 September 2012 (UTC)[reply]

Convert/g oz

It looks like there is a typo in this template? mulit2 -> multi2 ? I made an edit request on the talk page. Frietjes (talk) 15:57, 4 October 2012 (UTC)[reply]

Additional convert request

I posted an additional convert request at Template talk:Convert#Fuel consumption. Peter Horn User talk 21:48, 13 October 2012 (UTC)[reply]

links for km/hs and mph/s

there is a request on my talk page to change the links for these two conversions. I believe the issue is that they are measures of acceleration, not speed. I will see if there is a suggested target link, unless you know of a good one. thank you. Frietjes (talk) 14:36, 2 November 2012 (UTC)[reply]

Acceleration it is. Peter Horn User talk 19:23, 2 November 2012 (UTC)[reply]

That makes sense. JIMp_talk·cont 00:12, 3 November 2012 (UTC)[reply]

the default output for Template:Convert/mph/s should not be |o=km/h but |o=km/hs. Frietjes (talk) 19:20, 13 November 2012 (UTC)[reply]

So it should. JIMp_talk·cont 05:54, 14 November 2012 (UTC)[reply]

thank you. Frietjes (talk) 01:31, 15 November 2012 (UTC)[reply]

precision

see Template talk:Infobox settlement#10 hectares. thank you. Frietjes (talk) 17:17, 14 November 2012 (UTC)[reply]

okay, I think this will fix it. I basically copied the code used for the precision problem with km2. thank you. Frietjes (talk) 01:29, 15 November 2012 (UTC)[reply]

Additionally, there is a parallel thread at Template talk:Infobox settlement/areadisp#Zero acres returned when ha is 1 or 10 or 100 (may be other instances). Could you please post a response there, also at Template talk:Infobox settlement#10 hectares, because I don't seem able to satisfy Johnmperry (talk · contribs) in either case. --Redrose64 (talk) 10:00, 16 November 2012 (UTC)[reply]

Rare sigfig bug in near-zero-ended range

I am reporting a very rare Convert sigfig bug for range n-0, here, rather than Template_talk, because it is a low-priority bug, so perhaps some week when you have more time to consider it. Rounding a zero-ended range by "|1" works fine, but when "sigfig=2" then it finds a "" tag (like an x10 notation span-tag) with the zero at end of range:

{{convert|0|mm|in|1}} → 0 millimetres (0.0 in)
{{convert|0|mm|in|sigfig=2}} → 0 millimetres (0.0 in)
{{convert|6|-|0|mm|in|1}} → 6–0 millimetres (0.2–0.0 in)
{{convert|6|-|0|mm|in|sigfig=2}} → 6–0 millimetres (0.24–0.0 in)
{{convert|3|-|0.0004|mm|in|sigfig=3}} → 3–0.0004 millimetres (0.118–1.57×10⁻⁵ in)
{{convert/2 |3|-|0.0004|mm|in|sigfig=3}} → {{convert/2 |3|-|0.0004|mm|in|sigfig=3}}
{{convert|45|-|32|F|C|sigfig=2}} → 45–32 °F (7.2–0.0 °C)

The near-zero problem is totally rare, because how often does a range, even a temperature range, end near 0 with sigfig? Two easy workarounds are: round a range by "|1" or else use {convert/2} with sigfig=n. However, I wonder if the issue might cause wider problems in ranges near zero, so it is something to think about in the coming weeks/months. Meanwhile, I am working on many templates with worse problems. -Wikid77 (talk) 13:19, 21 November 2012 (UTC)[reply]

Another rounding issue in Template:Infobox settlement/areadisp

Hello. Since you recently fixed a problem in Template:Infobox settlement/areadisp involving over-rounding in the conversion of hectares to acres, perhaps you could take a look at Template talk:Infobox settlement/areadisp#Edit request: Fix over-rounding in conversion of square miles to km2. I have an edit request there for a similar problem where the template converts an area of 10,000 sq mi to 0 km². Thanks. -- Zyxw (talk) 15:02, 15 February 2013 (UTC)[reply]

Please disregard, another admin responded and made the correction. -- Zyxw (talk) 10:25, 17 February 2013 (UTC)[reply]

Okay. JIMp_talk·cont 17:14, 17 February 2013 (UTC)[reply]

Template:Infobox settlement/densdisp

I'm hoping you might help repair Template:Infobox settlement/densdisp. Please refer to the discussion at Template talk:Infobox settlement#Problem_with_auto_density. —Stepheng3 (talk) 00:56, 23 February 2013 (UTC)[reply]

Proposed quick fix adding "))" in template: I have a fix ready to install, as a first step, to just fix the invalid round-count, then next month, we can redesign as a simpler template. See edit request:

Template_talk:Infobox_settlement#Fixed unclosed "))" to get /densdisp/sandbox2 to work

I know the result is not perfect, but this bug has dragged on all week, and there is always a "better idea next month" so we could just install the fix, now, and experiment more next month. -Wikid77 (talk) 12:03, 28 February 2013 (UTC)[reply]

silent e

See talk:silent e 4.238.1.122 (talk) 19:21, 8 March 2013 (UTC)[reply]

Infobox settlement Chile

Hi Jimp,

I would appreciate to know your opinion in the case of merging {{Infobox settlement Chile}} to {{Infobox settlement}} as proposed in {{Infobox settlement/sandbox}}. The discussion is in Template_talk:Infobox_settlement#Infobox_settlement_Chile. Feel free to ask more information that isn't given in the discussion.

--Best regards, Keysanger (what?) 18:46, 13 March 2013 (UTC)[reply]

Template:Convert/test/Aon

Hi. You moved Template:Convert/test/Aon but I notice that hundreds of articles are still linking to it. Any idea if this is an issue? Thanks. SFB 18:19, 8 April 2013 (UTC)[reply]

It shouldn't be. I was using the "What links here" to keep track of which pages use the template in specific ways. The other day I changed to hidden categories instead. So none of those pages should actually be linking to the test pages. It usually takes a while for the system to catch up with changes. If you open one of those pages in edit mode and then hit "Save", the link should be gone. JIMp_talk·cont 00:34, 9 April 2013 (UTC)[reply]

Cool. SFB 06:45, 9 April 2013 (UTC)[reply]

Could you elaborate? There's a section on AN about this. ~ Amory (u • t • c) 20:54, 9 April 2013 (UTC)[reply]

Convert problems

Some parser-error messages related to uses of {{Convert}} started showing up in a few articles after your edits to the template on April 7—see, for example, Val-de-Ruz, Little Thetford, and Iowa Highway 210. I'm hopeless with template coding, and I don't even know whether your edits are directly responsible or there is some flaw in the articles' implementation of the template that your edits exposed. (The unparsable instances all seem to involve the use of another template to output the numeral that is to be converted.) Could you take a look and try to figure out what's going on? Deor (talk) 11:21, 9 April 2013 (UTC)[reply]

it's due to the addition of the tracking category, which prevents the number only option from being used in any computations. I fixed the Swiss ones since they were using convert in a very odd way, but the others will need to be fixed upstream. Frietjes (talk) 22:21, 9 April 2013 (UTC)[reply]

fixed several of them by doing this, which does not have exactly the same output, but does make the article readable again. Frietjes (talk) 22:40, 9 April 2013 (UTC)[reply]

Thanks to you and WOSlinker for cleaning these up. I had considered just replacing the embedded templates with the relevant values but figured that I didn't really know if that was the appropriate way of fixing them, Deor (talk) 22:52, 9 April 2013 (UTC)[reply]

Fixed {convert/f} and {convert/gaps} with {choptext}: I have written a quick text-truncation template, named Template:Choptext to default at "[", to chop away any hidden link to "[[Category:...]]" in other wp:wrapper templates which use "disp=number" inside a calculation. The results:

{{convert|8|m|ft|disp=number}} → 26
{{str_len |{{convert|8|m|ft|disp=number}}}} → 2
{{str_len |{{choptext |{{convert|8|m|ft|disp=number}}|[}} }} → 2

Currently, the {choptext} fix has been made to both the rare Template:Convert/f (option "near=50") and Template:Convert/gaps, to correct the expression errors. -Wikid77 (talk) 05:25, 10 April 2013 (UTC)[reply]

and now there is a new problem, which is that 28 cm (11 in) SK L/45 no longer generates a wikilink, due to the embedded tracking categories. Frietjes (talk) 22:24, 11 April 2013 (UTC)[reply]

Could always wrap all the tracking cats in a nocat param, e.g. {{#ifeq:{{{nocat|}}}|yes||...cats here...}} and then switch off the tracking cats with |nocat=yes on the occasional problem uses. -- WOSlinker (talk) 06:28, 12 April 2013 (UTC)[reply]

I think we should go back to tracking by transclusion. the real problem here is there is no way of finding the problem uses until someone notices them in a article, and then we get these convoluted methods for getting around a problem that shouldn't even be a problem. Frietjes (talk) 14:31, 12 April 2013 (UTC)[reply]

I think you're right. JIMp_talk·cont 14:35, 12 April 2013 (UTC)[reply]

Convert issue

This edit removed the comma formatting and inserted "or". The trouble is that now we have four measurements separated by or, and I can't seem to find a way to reformat the conversions to fix the unwieldy sentence structure the change introduced. Any thoughts on how to avoid "Both alternatives involved less wetland area (15.7 acres or 6.4 hectares or 18.3 acres or 7.4 hectares respectively vs. 24.3 acres or 9.8 hectares) ... " ? Imzadi 1979 → 08:17, 13 April 2013 (UTC)[reply]

I'll have a go but sticking the comma back wouldn't work either. "15.7 acres, 6.4 hectares or 18.3 acres, 7.4 hectares respectively vs. 24.3 acres, 9.8 hectares" wasn't really clear in the first place. How's this "15.7 or 18.3 acres respectively vs. 24.3, that is, 6.4 or 7.4 hectares respectively vs. 9.8"? JIMp_talk·cont 08:24, 13 April 2013 (UTC)[reply]

That works, I guess. I'll have to look into figuring out how to rewrite things. Thanks for looking. Imzadi 1979 → 09:03, 13 April 2013 (UTC)[reply]

Errors

Your new edits introduced errors in conversions, for example [1]. Please fix it. Subtropical-man (talk) 08:55, 14 April 2013 (UTC)[reply]

It was fixed by WOSlinker. JIMp_talk·cont 23:20, 14 April 2013 (UTC)[reply]

Template talk:Convert/STf

Jimp
Please see Template talk:Convert/STf#Edit request on 13 May 2013 and Template talk:Convert#For locomotives. Peter Horn User talk 18:06, 13 May 2013 (UTC)[reply]

Please see additional comments at Template talk:Convert/STf#Edit request on 13 May 2013 and Template talk:Convert#For locomotives. Peter Horn User talk 15:51, 14 May 2013 (UTC)[reply]

BTW tonne-force redirects to kilogram-force. Peter Horn User talk 19:08, 19 May 2013 (UTC)[reply]

Long ton-force and short ton-force still need each their own article or at least a separate section in the articles to which they currently redirected. Long ton and Long ton-force are not the same thing etc. Peter Horn User talk 14:45, 28 May 2013 (UTC)[reply]

I've created Ton-force. JIMp_talk·cont 04:25, 29 May 2013 (UTC)[reply]

Thanks Jimp, for a brilliant solution. Peter Horn User talk 01:17, 3 June 2013 (UTC)[reply]

Conversions of tonne-force

Jimp
Please see Template talk:Convert#Conversions of tonne-force. Peter Horn User talk 19:05, 19 May 2013 (UTC)[reply]

Thanks Jimp for ton-force. A very elegant solution. Peter Horn User talk 01:11, 3 June 2013 (UTC)[reply]

Please see my additional comment at Template talk:Convert#Conversions of tonne-force. Peter Horn User talk 03:07, 12 June 2013 (UTC)[reply]

Template:Convert/dam3:

the last edit you made on {{Convert/dam3}} creates an error. the "3" should be superscript "³" (as in cubed)...not a small. please advise. thanks.

1,000 acre-feet (1,200 dam³)

I've changed small to sup. -- WOSlinker (talk) 22:13, 20 May 2013 (UTC)[reply]

Thanks. The superscript & small buttons look very alike, I guess I hit the wrong one. JIMp_talk·cont 02:15, 21 May 2013 (UTC)[reply]

thanks all...much obliged! cheers. --emerson7 06:06, 21 May 2013 (UTC)[reply]

Focus on auto-correcting edit-conflicts

Wikid77 here. This is just FYI, no action needed. I've been contacting various editors that my next major focus (now that wp:CS1 Lua cites run 13x faster) is to fix most edit-conflicts, which seems to be a decision needed by community consensus. At first I thought there was a technology limit (as if "some conflicts" impossible to solve, but no), and instead all edit-conflicts could be auto-corrected according to set rules; however, we need to set some "policy" rules for how multiple edits will be applied at the same lines in a page, so the developers can make the software resolve the edit-conflicts, by default, following those rules. For example, when 2 editors try to post a reply at the same line in a talk-page, or add after the same line in a list article, then "edit-conflict" leaves the decision to the 2nd editor, rather than auto-correct and insert the 2nd reply after the 1st reply from the prior edit. I think the developers could auto-correct all edit-conflicts, if we get consensus on the rules of order.

Background: Extensive auto-correction for many edit-conflicts has existed since 2004, when re-combining separate parts of a page, such as the 1st editor changes the infobox parameters, then meanwhile 2nd editor changes a later paragraph, and the 2nd editor's paragraph is inserted with the 1st editor's infobox (conflict resolved). The next fix would be for 2 replies added after the same line, in a talk-page, or a list (etc.). However, the editor community needs to reach a consensus, so the developers would have a specific rule, to append a 2nd reply, after the 1st reply, at the same line number, which is currently treated as "edit-conflict" and extremely common in fast-moving talk-pages. I suggest to use FIFO order (first-in, first-out), so the 1st reply takes precedence over the 2nd reply, to be inserted after the 1st. The developers have already finished "90%" of the bigger, complex Edit-merge operations, and what is left is to decide the community's choice as to which order to append two replies at the same line number, such as FIFO order. Perhaps we need an RfC to decide that issue. Any thoughts yet? -Wikid77 (talk) 15:15, 21 May 2013 (UTC)[reply]

It seems to make sense. An idea I just had was that it might be good if a notice would pop up as you're editing if a change is made (perhaps even having some way to resolve the conflict just by hitting a botton, i.e. without having to copy and paste into a new edit window). I don't exactly know what would be feasible. Anyhow, it would be nice to see the end of edit conflicts. JIMp_talk·cont 05:08, 15 June 2013 (UTC)[reply]

Template:Convert/testcases/0 and Template:Convert/testcases/1

do you still need these? they are causing a bunch of templates to appear in Wikipedia:Database reports/Transclusions of deleted templates. Frietjes (talk) 16:50, 14 June 2013 (UTC)[reply]

They are largely unnecessary but may still have a use (though temporary). I'll figure out what to do with them sometime but in the meantime I've hidden the transclusions so that they should not appear on the database report page. JIMp_talk·cont 04:57, 15 June 2013 (UTC)[reply]

June 2013

Hello, I'm BracketBot. I have automatically detected that your edit to Gasoline and diesel usage and pricing may have broken the syntax by modifying 1 "()"s. If you have, don't worry, just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

|LE1.75/L <90 octane LE1.85/L <92 octane LE5.85/L <95 octane LE1.1/L diesel ('solar')
| [http://www.elperiodiquito.com/modules.php?name=News&file=article&sid=934] (fixed prices 6.30BsF/$ (2013) (at "non-essential" exch. rate)

Thanks, BracketBot (talk) 12:19, 17 June 2013 (UTC)[reply]

Disambiguation link notification for June 22

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Pièze, you added a link pointing to the disambiguation page Standard atmosphere (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:57, 22 June 2013 (UTC)[reply]

Need help on template:Convert at Bengali (bn) Wikipedia

Hi, I am from Bengali (bn) Wikipedia. Could you please help us on bn:template:convert at bn Wikipedia. Or referrer us to anyone who can help us on this template. The template is not working properly at bn Wikipedia. All the content of the template has been disappeared when page view mode. It also disappear other article page content where it used. e.g. see bn:ভুভুজেলা and bn:বাংলাদেশের জাতীয় মহাসড়কগুলোর তালিকা. Please help us and suggest us on this issue.--Bellayet (talk) 13:17, 23 June 2013 (UTC)[reply]

@Bellayet: I looked for some feedback regarding the reply that I left to your query on my talk. When I saw that you have been active here, I looked at the problem you report more closely. I cannot see why the template is truncating articles, so I tried putting convert/sandboxlua in the first problem page. It worked—the page was no longer truncated, and the conversion was correct. I looked at a few other pages that use Template:Convert and saw that the converts they contained used standard English terminology so I tried replacing Template:Convert with the Lua version. Doing that showed a lot of pages with errors because the bn wiki is using units that are not standard English. Some reasonably straightforward editing would probably fix that, and it should not take long to customize Module:Convert so it works at bn. However, I would need to know the details about things like "৪৫৫". When I saw the errors I reverted my change to the template. If Jimp can fix the template issue (could it be the tracking categories?), that might be the fastest solution. Do you know when the problem occurred? However, if Bellayet would like to try the module, please reply at my talk. Johnuniq (talk) 02:20, 24 June 2013 (UTC)[reply]

Another precision request

Hi Jimp, can you do the same at Template talk:PGR#Precision parameter as you did at Template talk:Pop density#Precision parameter? Cheers, Hwy43 (talk) 06:37, 25 June 2013 (UTC)[reply]

Hi Jimp, yet another precision request. Can you add a precision parameter to the "Change" portion of Template:Noc. Hwy43 (talk) 04:31, 14 February 2014 (UTC)[reply]

Just read at Template:Noc that it invokes Template:Change, which has a precision parameter (dec=) with a default of two. So, I amend my plea for help. Is there a way to carry forward that parameter to Template:Noc to enable override of the default value at the invoked Template:Change? I want the opportunity to round to one decimal place rather than the over precise default of two. Thanks for considering. Hwy43 (talk) 06:38, 14 February 2014 (UTC)[reply]

I've added a precision parameter. I called it dec. I don't much like the name, I'd prefer prec, but there already was a parameter pre so prec could cause confusion and {{change}} uses the name dec so it seemed to be the way to go. Jimp 08:24, 14 February 2014 (UTC)[reply]

Awesome. Thanks. Hwy43 (talk) 06:24, 15 February 2014 (UTC)[reply]

Another request regarding that template... can you create an align parameter to override the default right alignment? I'd like to center the outputs in all three columns. Hwy43 (talk) 21:52, 15 February 2014 (UTC)[reply]

Done. The parameter is align. Jimp 03:25, 17 February 2014 (UTC)[reply]

July 2013

Hello, I'm BracketBot. I have automatically detected that your edit to Torres Vedras may have broken the syntax by modifying 1 "[]"s. If you have, don't worry, just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

*[[Joaquim Agostinho]] (1943-8]), [[bicycle]] racer

Thanks, BracketBot (talk) 09:33, 5 July 2013 (UTC)[reply]

Densdisp

Hi Jimp. I have been working on a lua version of the subtemplates used by template:infobox settlement, and I believe I was able to duplicate the functionality of every template except for template:infobox settlement/densdisp, where I ended up using a different algorithm. my question is about what appears to be a bug in the computation of the precision used for rounding the result. in particular, if you look at the first rounded result:

{{rnd|{{#expr:{{formatnum:{{{pop}}}|R}}/{{formatnum:{{{km2}}}|R}}}}<!--
  -->|{{#expr:(1+ln<!--
  -->({{formatnum:{{{km2}}}|R}}^2/<!--
  -->({{formatnum:{{{km2}}}|R}}E-{{max<!--
  -->|{{precision|{{formatnum:{{{pop}}}|R}}}}<!-- 
  -->|(3-{{order of magnitude|{{formatnum:{{{pop}}}|R}}}})}}<!--
  -->+{{formatnum:{{{pop}}}|R}}E-{{max<!--
  -->|{{precision|{{formatnum:{{{km2}}}|R}}}}<!-- 
  -->|(3-{{order of magnitude|{{formatnum:{{{km2}}}|R}}}})}}<!--
  -->/ln10)round0}}}}

if I replace the pop with 222 and km2 with 13, I get,

17

now, here is the strange thing, if I just evaluate the precision part, I get

Expression error. Unclosed bracket.

which makes me wonder how this is even working at all. removing the outer #expr, we see the problem

(1+ln(13^2/(13E-1+222E-2/ln10)round0

logically, when I see ln(arg)/ln10, I think, oh this is just log10(arg), but here, it's not clear what is going on since there are two missing )s. In the version that I used in the lua module, I used something less complicated, where I say, just give me two digits significant figures in the result. this seems to be functionally equivalent to what we have right now. you can try out my lua module with

{{#invoke:infobox settlement|densdisp|/km2=auto|km2=13|pop=222}}

which should be the same as

{{infobox settlement/densdisp|/km2=auto|km2=13|pop=222}}

It would be great if you had some ideas (1) why the current method works, (2) how to improve the lua module, (3) if there is any reason to not simply round the output to two sigfigs. thank you. Frietjes (talk) 20:25, 19 July 2013 (UTC)[reply]

I just noticed the thread above and this thread, so it's a fluke that it works. still, it would be interesting to hear if there is any reason we can't simply round to two significant figures. Frietjes (talk) 20:30, 19 July 2013 (UTC)[reply]

The idea behind that algorithm was to try matching the output precision to the input. Is it really worth the bother? I don't know. I have no real objection to just going with two sig figs; anyone who isn't satisfied can break out their own calculator I s'pose. Jimp 06:12, 22 July 2013 (UTC)[reply]

I see, we could probably use the minimum precision of the two inputs, but it seems people are generally happy with two digits of precision. Frietjes (talk) 16:42, 28 July 2013 (UTC)[reply]

Convert/LoffAoffDbSoffImp

Could you fix 3.5 imperial pecks (32 L; 7.2 US dry gal), 1 impgalatm^{[convert: unknown unit]}, 1 cubic metre (1,000 L; 260 US gal; 220 imp gal), 1 cubic metre (1,000 L; 220 imp gal; 230 US dry gal), 1 cubic meter (1,000 L; 260 U.S. gal; 220 imp gal), 1 cubic metre (1,000 L; 260 US gal; 220 imp gal), 1 cubic metre (1,000 L; 220 imp gal; 230 US dry gal), 1 cubic metre (55 kenning)? or reduce the protection so I can fix them? thank you. Frietjes (talk) 16:42, 28 July 2013 (UTC)[reply]

I will see if I can have the protection level reduced. Frietjes (talk) 16:29, 31 July 2013 (UTC)[reply]

Done. Jimp 09:23, 1 August 2013 (UTC)[reply]

thank you, you can find several more broken ones if you check Template:Convert/testcases/bytype, and look for mismatches between the current template and the lua version. by the way, any idea why 1 pound per imperial gallon (0.100 kg/L) is reporting the conversion to three digits of precision? It seems to be coming from {{convert/round}} since (1 - orderofmagnitude(0.099776)) = 3, which is greater than 1. Frietjes (talk) 19:38, 1 August 2013 (UTC)[reply]

INRConvert template

Thanks for correcting the format of the year in the template. Appreciate the time and effort! Ravensfire (talk) 13:57, 7 August 2013 (UTC)[reply]

No problem. Jimp 09:16, 8 August 2013 (UTC)[reply]

Hey! I think we got another problem. The USD in INRConvert is being linked to an external spam website, [www.filmznews.com]. I can't figure out why or how this is happening! —Avenue X at Cicero (t · c) sends his regards @ 19:04, 17 August 2013 (UTC)[reply]

It's probably vandalism. Jimp 03:59, 19 August 2013 (UTC) So it was. Jimp 04:03, 19 August 2013 (UTC)[reply]

Template:JanuaryCalendar

Hi. I would like to comment your recent action. You deleted Template:JanuaryCalendar as a T3 but it is a redirect and not a template. Moreover, the redirect had uses in some talk pages. I have no problem if you delete it as long as you treat the other calenders the same way and you fix some links on talk pages that may be important. -- Magioladitis (talk) 07:47, 13 September 2013 (UTC)[reply]

Thanks for the head's up. Yes, the others should go also. I'll check the what links here for talk page transclusions. Jimp 09:22, 13 September 2013 (UTC)[reply]

I had a look and found two user talk pages transcluding these (User talk:Solitude and User talk:Ed g2s/Archive2) as part of a discussion which occurred almost nine years ago. I thought it would be safe just to delete the lot. Jimp 09:41, 13 September 2013 (UTC)[reply]

Announced Lua Convert and mass reformat

I have announced the likely October 2013 transition to Lua (people need time to prepare), with massive reformatting of all 560,000 {convert} articles whenever Module:Convert is changed; however, Johnuniq has explained how new units can be added (without reformatting all pages) by editing the Module:Convert/extra which is dynamically linked only when units are not found in the giant Convert/data. See notice:

"wp:VPT#Forcing Convert into huge Lua modules" - with discussion

The main pages of Lua Convert script are enormously complex, as 3,000 and 9,500 source lines of intricate Lua, so as Johnuniq updates them for recent bugfixes, the history of changes will pinpoint where inside to update, among the vast ocean of Lua script in the mindboggling, gargantuan modules. The prior Template:Convert/old can still be used/updated for emergency fixes, or non-numeric parameters such as {{convert/old |9:43 pm|time|24}} =

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}}.

. Of course, there is no rush to Lua, no deadline, because we can patch Template:Convert as long as needed (and no one is complaining about Convert as "slow"). The main goal: avoid Lua Convert as being another gotcha-surprise such as VE, or the 26 August red-error messages in 60,000 wp:CS1 cites, or the frantic rush into https-secure protocol (some users cannot set http-mode username upon login). -Wikid77 (talk) 16:48, 18 September 2013 (UTC)[reply]

Template:January calendar

please restore these until they have been orphaned. thank you. Frietjes (talk) 14:41, 24 September 2013 (UTC)[reply]

They have except on user pages. I don't like editing other people's user pages (except talk pages, of course). But, okay, I'll go and orphan them fully, and explain the change to those affected. Jimp 09:07, 25 September 2013 (UTC)[reply]

There are only two pages left, User talk:Ed g2s/Archive2 and User talk:Solitude, which use these but this is part of a discussion the happened six years ago so they're not actually in use. Jimp 11:16, 25 September 2013 (UTC)[reply]

thank you, this will keep the templates out of the database report for transclusions of deleted templates. you probably want to delete the subpages as well,

Frietjes (talk) 18:59, 26 September 2013 (UTC)[reply]

New Calendar Template

Thanks so much for replacing my old calendar template. LoreMariano (talk) 13:30, 25 September 2013 (UTC)[reply]

Hello, Jimp. You have new messages at Waldir's talk page.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Convert template table mode broke

I see you're the last to edit the convert template. Something looks broken when used in multi-column table mode. A snippet from List of Missouri conservation areas – Southeast region illustrates the problem:

Conservation Area	Description	Size		County	Location
Allred Lake Natural Area	The 160-acre (0.65 km²) area contains 53 acres (21 ha) of forest and the Allred Lake Natural Area. Facilities/features: 1/4-mile trail ending in a short boardwalk, viewing deck, and Allred Lake (7 acres).[2]	164 acres	66 ha	Butler	36°31′8.29″N 90°25′6.55″W / 36.5189694°N 90.4184861°W / 36.5189694; -90.4184861 (Allred Lake Natural Area)

It should say "164 acres" in the third column. Is this your doing, or at least something you're able to fix? Thanks. --Kbh3^rd talk 01:48, 27 September 2013 (UTC)[reply]

It's not my doing. I'd be able to fix it (if I can find the time). However, how about getting rid of |abbr=on and putting the units up top like this?

fixed Jimp 03:53, 27 September 2013 (UTC)[reply]

Thanks! (As for the suggestion to put the units in the column header, the computer scientist in me likes the distributive property of that, but otherwise I can find several objections: a) There were potentially scores? hundreds?? thousands??? of articles affected by the bug; b) The same units may not always apply to each row; c) Way down in a long table you can't see what the column headers are, and you're left with table entries of unexplained numbers.) --Kbh3^rd talk 02:15, 28 September 2013 (UTC)[reply]

request to create a page

hi am Amilton Jimp, is'm Brazilian writer and theologian Pastor Religious saw your page and saw you and very efficient at what you do and would like to ask you to build me a page in my name "Amilton Rodrigues de Cristo" pr.amiltondecristo@ hotmail.com thank you

User_talk:Amilton, 29 , october 2013 (UTC) — Preceding unsigned comment added by 187.26.221.51 (talk)

I'd love to help if I can. What exactly are you after? Jimp 03:09, 4 November 2013 (UTC)[reply]

Convert template gives different results

Hi Jimp, since you seem to have made several recent edits to the Convert template, I'd like to ask a question about using Convert and seek your help.

In the Yeohangsan article, it seems that Convert gives two different results. In the main text, 770 metres is converted to 2,530 ft, while in the infobox, 770 metres is converted to 2,526 ft. Can you help explain the difference? Thanks. Truthanado (talk) 11:02, 2 November 2013 (UTC)[reply]

What's going on is that there are two different templates at work. In the text {{convert}} is used but in the infobox {{infobox mountain}} is used. The infobox template then calls {{infobox mountain/convert}} to do the conversion. {{Infobox mountain/convert}} rounds to the nearest metre or foot whereas {{convert}}'s default is to match the output precision to that of the input. You can adjust the precision of {{convert}} by specifying a rounding factor, e.g. {{convert|770|m|0}} will round to the nearest foot (for more detail see the doc). If, on the other hand, you'd rather adjust the precision in the infobox, that'll be a little more tricky (involving an edit to the infobox template). Jimp 03:05, 4 November 2013 (UTC)[reply]

Suggestion for Template:Calendar

Hi there, Jimp. I was thinking if it would be possible to make Template:Calendar allow for separate control over linking days, months and years. For example, lk=on would link all three; lk_days=on would link only days, and lk_d=on + lk_m=on would link days and months, but not years. I tried looking at the source code of Template:Calendar to see if I could do it myself, but couldn't figure out a way. Do you think you can do it? --Waldir ^talk 14:44, 6 November 2013 (UTC)[reply]

Sure it would. Actually I'd had that in mind originally but thought it might end up being one of those features which nobody ever uses but if you're interested in having such a feature, it could be added without too much difficulty (I sort of left room for this). Jimp 06:53, 8 November 2013 (UTC)[reply]

I've got it working but instead of introducing new parameters I've just used lk. If you want only days, use lk=d; if you want only months, use lk=m; if you want days and months use lk=dm; if you want months and years use lk=my; etc. I've only checked the basic instances though, I haven't checked whether there might be clashes with other parameters (there shouldn't be but odd things can happen). Jimp 07:44, 8 November 2013 (UTC)[reply]

Great! I did think about that approach as well but assumed that parsing the parameter for different combinations would make it harder than having separate parameters. Thanks :D --Waldir ^talk 18:27, 11 November 2013 (UTC)[reply]

Push to force Convert into Lua version

There has been a major push to quickly force the Lua version of Template:Convert into system-wide operation, and then, only afterward, begin to fix the broken conversions which are incompatible with Lua. I have objected to this forced transition, numerous times, but I could sense, months ago, that it would be forced, regardless of the technical limitations and the fact that feature changes in the Lua module will trigger reformatting all 554,000 affected pages, for any Lua edit made to Module:Convert. The current markup-based Convert has been very flexible, while allowing new features to reformat only a small subset of articles, but the Lua version will deter complex conversions, and I think progress toward improvements will likely grind to a halt, as fear of changes in Module:Convert could instantly impact the 554,000 articles if a new change went awry. I regret that some people will target you for help, with whatever limitations the Lua version causes, but I do thank you for the prior flexible Convert architecture which made the many new features easy and instant to add (even if you did not see the use for an "abbr=~" referrent symbol!). I agree that, long-term, a feature such as "fmt2=gaps" would have been a general solution to allow flexible formatting, but I am unsure how all the Lua turmoil will disrupt further enhancements. There seems to be a growing momentum to just railroad the limited Lua version into system-wide use, and so I wanted to warn you where people might try to blame you for any related problems in the Lua version, as you had been the "goto" contact all these years for fixing Convert problems. I will try to help resolve any problems, and Template:Convert/old is still available to offer easy fixes which would not reformat 554,000 pages, but my time is severely limited during the next month. -Wikid77 (talk) 00:15, 28 November 2013 (UTC)[reply]

Confirmed old and Lua versions work well and few unit mismatches: I have burned horrendous hours confirming how the Lua version will work for the vast majority of 1.6 million cases, plus inside wp:wrapper templates, except for singular fractions which you fixed, 2 years ago, by {convert/plural}. There is still time to fix the Lua version to not say "1⁄2 feet" and I haved fixed all major {convert/old} subtemplates to show "1⁄2 foot". Current status:

{convert |1/2|ft|m}} → 1⁄2 foot (0.15 m)
{convert/sandboxlua|1/2|ft|m}} → 1⁄2 foot (0.15 m) - live

Meanwhile Johnuniq scanned for unit-mismatch pages and found only 350 articles (many fixed now), with mainly "sqft" or "kn" or "lbf" as about 1-per-5,000 mismatched. By changing {convert/numdisp} for the &minus error, I have triggered reformatting 510,000 pages, which still seems to run over 3 days, and means some pages will not reformat (perhaps being edited at the time). All this confirms how you had done an excellent job in maintaining Convert, with almost no unit errors in actual articles. Of course, most people knew the old Convert worked well, but I have spent the numerous hours to confirm it. -Wikid77 (talk) 16:20, 2 December 2013 (UTC)[reply]

Using Convert/old for temperature sets: The Lua version omits one of your interesting 2008 units for the future: 10s °F, 20s °F (etc.), which can be used still by {convert/old|10s|F|C}. The WP world has not focused yet on temperature sets, but they are an excellent idea, such as for summer highs in Houston, TX: {convert/old|90s|F|C}} as "

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}}.

". Perhaps those can become "F-set" and "C-set" temperature numbers, even in Lua Convert. -Wikid77 14:20, 4 December 2013 (UTC)[reply]

Next Lua Convert might be hybrid: I think the current Lua version will be short-lived, due to 5-day delay agony of reformatting all 554,000 pages for any Lua edit. Also, there are severe limitations, such as no compound scale factors "b=" with #if functions, nor "h=hyphen-name" where instead dashes are auto-forced into the unit name, and a complex unit calculation might take one month to add into Lua Convert. Hence, the next step might be a hybrid Lua-template where the markup runs a quick, small Lua module to assist the current markup-based Convert. -Wikid77 14:20, 4 December 2013 (UTC)[reply]

Forcing Convert to Lua early

There has been talk, today, to circumvent the 30-day RfC and immediately switch Template:Convert to use the Lua version (with known bugs), as an update on 11 December 2013 (to reformat over 2 weeks). The documentation has not been fully updated, and there has not been a systemwide announcement, so I am just warning people individually (after anger about VisualEditor installed without enough warning). Several people have tested the Lua Convert to ensure general usability, and we fixed about 600 pages with incompatible Convert options. Meanwhile, I have fixed {Convert} (or Convert/old) for precision in ranges:

Fixed 20–20 kg: "Template_talk:Convert#Fixed ranges for nonsense results"

The plans for early force to Lua are:

Lua roll-out: "Template_talk:Convert#Module switchover timetable"

After roll-out, any edit to Lua Module:Convert, to fix bugs or improve precision, will re-trigger the systemwide reformatting of all 554,000 pages, again and again. -Wikid77 20:34, 9 December 2013 (UTC)[reply]

Finally a fix for range precisions

Amidst all the turmoil in the Lua Convert sideshow, I have been able to focus on real user requests, such as to fix the default precision in ranges to seem more logical. For years, we have heard people complain about the excessive rounding, such as:

{{convert|43|-|45|lb|kg}} → 43–45 pounds (20–20 kg) <--both results same
{{convert|861|-|862|lb|kg}} → 861–862 pounds (391–391 kg) <--both same

Well after asking people, for months/years, to help think of solutions, it finally dawned on me that a range such as "800-800.06" implicitly means the number "800" is "800.00" but people write "800" as a shorter numeral, and the template needs to switch gears and consider the precision of 800 to match 800.06 when inside the range, and then people will get the results they expect. This solution has worked, and the /sandbox version of {Convert/Dual/rnd} will give logical results in the various cases:

{{convert|43|-|45|lb|kg }} → 43–45 pounds (19.5–20.4 kg)
{{convert|860|-|970|lb|kg}} → 860–970 pounds (390–440 kg)
{{convert|861|-|862|lb|kg}} → 861–862 pounds (390.5–391.0 kg)
{{convert|800|-|800.06|lb|kg}} → 800–800.06 pounds (362.87–362.901 kg)

Now, we finally have a comprehensive solution, where multiples of ten (or 100) still round to the nearest ten, but consecutive numbers 860–861 will default to an extra digit of precision to show the difference between numbers, both treated as precision "1" when close in value. These issues are explained in:

Template:Convert/Dual/rnd/sandbox - auto-adjusts precision of a range

So, the next time someone has a list of ranges with close values, then they could use {convert/old} for each range to auto-adjust the precision. We might ask for further help in fixing the Lua Convert by posting to wp:Lua_requests, or experiment with a Module:Convert/sandbox2. Meanwhile, I will run some wider tests, and then install this fix for range precision. Any other concerns? -Wikid77 14:55, 5 December 2013 (UTC)[reply]

DONE. Installed 06:16, 7 December and reformatted half of 56,000 range pages in 2 days. -Wikid77 20:34, 9 December, 15:15, 10 December 2013 (UTC)[reply]

Thanks for Convert-talk messages

Thank you for taking time to answer issues about conversions at Template_talk:Convert in early December, where the issues had been ignored, but will have those answers when archived. It seems everything is "Lua Convert" and who cares about actual conversions, just Lua regardless of results. During the next month, while Lua Convert is reformatting all 554,000 pages again, for 1 Lua edit(!), I will try to update the encyclopedia measurement-unit pages, which had been neglected for some time. It is almost Kafkaesque to imagine how Convert, which had been suboptimized to update rapidly for 6 years, became a Luasaurus updated once a month (2 weeks careful planning +2 weeks reformatting all pages), as a technological "improvement" <g>. However, long-term, the Lua version could be partially resplit, as in Template:Convert/hybrid (separate m/ft, mi/km, lb/kg) to allow faster 3-day updates to rare submodules, without the 2-week fearful planning for hideous systemwide reformat. Anyway, perhaps the talk page will re-focus on conversions after a while. -Wikid77 15:15, 10 December 2013 (UTC)[reply]

Adding brake horsepower and foot-pounds per second: In January, while Lua Convert is trying to re-reformat 554,000 pages (again) to have more of last year's features, I will revise page "Horsepower" to clarify the text. For "brake horsepower", I have created Template:Convert/ftlb/s, based on: "1 hp = 550 foot-pounds per second".
Using Template:Convert/old, I am able to test new units without complaints about expanding Module:Convert/extra. The system-wide reformatting for Lua Convert, begun 02:15 on 11 December, has been a nightmare, dragging past 13 days (10 should have been enough), and meanwhile people remember how the markup-based Convert formerly offered more features, even before the "paint is dry" on deploying Lua Convert. To check status of reformatting, I have listed Special:WhatLinksHere/Template:Convert/track/adj/ and confirmed over 20,000 of those pages still show precision or results from old Convert. The wp:CS1 cites have run over 48 days to reformat 2.2 million pages to log "month=" as deprecated (without wider consensus) in 155,000 pages. I have proposed at wp:PUMPTECH to just reformat every page, every day, as faster (perhaps skip pages with no major templates). -Wikid77 (talk) 14:27, 23 December 2013 (UTC)[reply]

Template:Infobox oil field

Hi, Jimp. There seems to be a problem with {{Infobox oil field}} (field:est_oil_t). For some reasons this field has conversion error (e.g. see the infobox at Gunashli oilfield). I don't know how to fix it. Another issue is that this field uses for conversion only the standard API value of 33.4. However, some fields have a different API value. Is it possible to add the API field to the template and to use that value (if the API value is not defined, the value 33.4 should be used instead)? Thank you in advance. Beagel (talk) 13:03, 18 January 2014 (UTC)[reply]

I've fixed the template so that the API parameter is passed on to the template {{bbl to t}}. I'm not sure what the error on Gunashli oilfield is. Jimp 09:11, 20 January 2014 (UTC)[reply]

Thank you very much. Whatever error with template was shown at Gunashli oilfield article, it was fixed by user:Frietjes. Beagel (talk) 05:17, 4 February 2014 (UTC)[reply]

Template talk:Height

Given your previous involvement in the discussion at Template_talk:Height#Centimetres, I just thought I'd bring a closely related Request for Comment to your attention (as per Wikipedia:Canvassing).--Gibson Flying V (talk) 03:52, 23 January 2014 (UTC)[reply]

arcmininute

did you mean to misspell minute here? Frietjes (talk) 17:14, 13 February 2014 (UTC)[reply]

Nope. Thanks for that. Jimp 06:19, 14 February 2014 (UTC)[reply]

Template:Dts

I'm trying to understand Template:Dts, and I can't figure out what {{#ifexpr:0*{{{1|}}}0=0 is supposed to be testing for. I thought I had it figured out, but then I noticed it only gets tested in the non-error branch of {{#iferror:{{#expr:{{{1|}}}}}, which seems to be essentially testing the same thing. Do you have any idea what's going on here? Jackmcbarn (talk) 01:34, 22 March 2014 (UTC)[reply]

It's checking for YYYY-MM-DD date format. If, for example, you input today's date in YYYY-MM-DD format, 2014-03-24, you get {{#ifexpr:0*2014-03-240=0 which will give you a negative because 0×2014−3−240≠0. Jimp 07:58, 24 March 2014 (UTC)[reply]

Translation of Template:Calendar

Hello Jimp could you help me to find the solution to my problem? I'm having some difficulties to translate this template on the Luxembourgish Wikipedia. The Template just works on pages with months that are written the same ass in English like:

Templates used

Default template

Calendar Template

From Sunday to Monday

Link on/off

Link on
Link off --Soued031 (talk) 13:01, 29 March 2014 (UTC)[reply]

I could try. What is going wrong? Jimp 08:47, 31 March 2014 (UTC)[reply]

Thanks for trying out. {{Mountkalenner|month="Monthname in Luxembourgish"}} on the Luxembourgish Wikipedia doesn't work. The month variable just works with months in English an I don't know how to make it work with Luxembourgish names. --2001:7E8:C013:3501:C88C:6FEC:F2D:853A (talk) 11:03, 1 April 2014 (UTC)[reply]

I may have got it working. Have a look. Jimp 11:54, 1 April 2014 (UTC)[reply]

PS the problem was that {{#time:}} doesn't recognise Luxembourgish (it can write but can't read). Jimp 11:57, 1 April 2014 (UTC)[reply]

Nice work and you answered very fast :), it works now but only if "month" is set could you make it work automatically (without "initialising" month) like on the english Wikipedia? Or else how could the problem of {{#time:}} be solved? Is there a way that I can change the extension or someone else? This error could be problematic. Does it depend of a translation on translatewiki.net? --Soued031 (talk) 12:39, 1 April 2014 (UTC)[reply]

I don't believe we mere mortals can change {{#time:}}. I'm no expert but it looks like {{#time:}} is based on PHP (see http://www.php.net/manual/en/function.strtotime.php). Of course, there must be someone who could fix it but they'd have to be a developer or something. I'll have a look at the template again to see what's happened to the automatic function. Jimp 08:40, 2 April 2014 (UTC)[reply]

Again the problem is that {{#time:}} can't read Luxembourgish. A crude partial solution would be to use another {{#switch:}} to translate into English. This would work okay for the twelve month articles but would hardly be worth the bother. If you want a {{#switch:}} to handle day-month articles also, it would be huge (an extra 366 lines). Then you might want to cover month-year articles too ... . A better solution would be to use a Lua module. Module:String, for example, would work. I looked for this one on the Luxembourgish WP but I couldn't find it. I'm not overly Lua savvy and my ability to write Luxembourgish is even worse so I'm not the bloke for the job but if someone could twist someone's arm to have Module:String transwikied over there, I could have a go at putting together a translation subtemplate. Jimp 10:47, 2 April 2014 (UTC)[reply]

I added the "Modul:String" to the lb.wikipedia.org. I only know Java :s. If you want to give it a try here are the translations:

Januar : January

Februar : February

Mäerz : March

Abrëll : April

Mee : May

Juni : June

Juli : July

August : August

September : September

Oktober : October

November : November

Dezember : December

--Soued031 (talk) 16:21, 3 April 2014 (UTC)[reply]

I've added a translation subtemplate. Now the page name will be automatically translated into English so that when it's put into {{#time}} it will work. Actually this new subtemplate eliminates the need for the one I previously made. I don't know the procedure for deleting templates over there but Schabloun:Mountkalenner/m is no longer needed. Is there a template like {{db-g7}} or {{db-t3}}? In fact, something like this could be used as the basis for a more general replacement for the Luxembourgish-illiterate {{#time}} parser, i.e. a template which would do on the Luxembourgish WP what the {{#time}} parser does here. Jimp 12:25, 7 April 2014 (UTC)[reply]

Really nice work Jimp, I never thought that it could be possible to trick {{#time}}. We (members of the Luxembourgian Wikipedia) are very happy about what you did there! Thanks a lot. Don't worry about the deletion the admins will take care of it. --Soued031 (talk) 13:17, 7 April 2014 (UTC)[reply]

Re: Template:dtsh

The date in the second section are not displaying correctly. I don't know if it has anything to do with the linked years.—Chris!_c/t 19:39, 1 April 2014 (UTC)[reply]

That's strange. What's even more strange about it is that some of the dates work & others don't. It hasn't got anything to do with the linked years (by the way) the problem is within the template. I'll look into fixing it. Meanwhile I reverted back to the 07:55 1 April 2014 version with the format=hide (which isn't faulty). Jimp 09:02, 2 April 2014 (UTC)[reply]

It looks like there was some strange inconsistency in the way {{#time}} works. It's fixed now. Jimp 10:11, 2 April 2014 (UTC)[reply]

Looks good now. Thanks.—Chris!_c/t 19:54, 2 April 2014 (UTC)[reply]

Updating data at template.

Hi. I noticed you created this template. Could you please update the values of the data? Thanks in advance! NiR_insanity 10:32, 4 April 2014 (UTC)[reply]

I added a 2014 value based on inflation.eu data. I'm guessing this is okay. As mentioned in the note I left on the template talk page, I basically swiped the data used in the template from someone else and so I'm not completely sure about it let alone about updating it. With any luck, though, someone will check whether things are all in order. Jimp 10:59, 7 April 2014 (UTC)[reply]

Font

If you want something different try using Firefox font Kokila (enlargened twice), full screen, and Modern skin. The standard font and setting has never been very good anyway!!♦ Dr. Blofeld 12:58, 8 April 2014 (UTC)[reply]

Thanks for the tip. The problem, though, still remains that the general public (and I if not logged in) will see this ugliness. Things might never have been good but it's still a shame to see them going from bad to worse. Jimp 13:05, 8 April 2014 (UTC)[reply]

Agreed that the main text looks crap. But then again so does the main page design IMO.♦ Dr. Blofeld 19:38, 8 April 2014 (UTC)[reply]

April 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Gabriel Garko may have broken the syntax by modifying 1 "[]"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

* ''[[Troppo caldo]]'', regia di [[Roberto Rocco]] (199])

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 11:43, 29 April 2014 (UTC)[reply]

Template:Convert/TonCwt to t

Hi,
Please see Template talk:Convert/TonCwt to t#Just curious Peter Horn User talk 20:05, 20 May 2014 (UTC)[reply]

Eduardo Berizzo

Hi there JIMP, AL from Portugal "here",

i SINCERELY apologize for my summary in this person's article, really a bit too much. In a (definitely) related matter, i have been here for eight years and i have always seen this as the correct usage for footballers (my field of editing), when it's removed and written manually it is usually immediately reverted, not just an isolated action by me that one.

I have already contacted an administrator to see if i'm in the correct (I'm 99,999999999999999% sure of what i'm saying and doing), if he tells me "stop, you're wrong" i will of course, and also apologize not only for my summary like above but for my reversions.

Attentively, happy editing and happy weekend --AL (talk) 15:27, 23 May 2014 (UTC)[reply]

The admin has replied (please see here https://wiki.riteme.site/wiki/User_talk:Always_Learning#Height_template), if you have any further comments please clear it out with him. Again, accept my apologies for the "accelerated" summary, cheers --AL (talk) 16:04, 23 May 2014 (UTC)[reply]

Thanks for the reply. For technicalities, you'll have to get in touch with the said admin (or another one, for that matter). I repeat, i have been here for eight years (and will leave for good at the end of the 2014 FIFA World Cup, getting very tired) and had never seen the height being inserted like that, and when it was it was usually reverted in a matter of hours/days, that was why i "cringed" at the sight of it and asked for mediation to see if i was doing the correct thing by reverting.

About the technical aspect of it i'm totally at a loss (regarding that guideline and many many more), maybe Matty or anyone else will shed a better light. If it's worth, i can add i agree with the current template, as it shows BOTH centimetres and feet. --AL (talk) 12:07, 27 May 2014 (UTC)[reply]

Thank you!

Wishing Jimp/Archive V a very happy adminship anniversary on behalf of the Wikipedia Birthday Committee! Anastasia (talk) 23:41, 15 June 2014 (UTC)[reply]

Nomination for deletion of Template:Convert/list of units/...

A group of "Convert/list of units/..." templates have been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Plastikspork _―Œ^(talk) 00:06, 7 July 2014 (UTC)[reply]

Just curious...

Do you have any advice on if and how I should have handled this differently? Perhaps I was a bit blasé about responding initially because it's such an obvious WP:BOOMERANG. It's a bit of a time-consuming mess (to my detriment!), so I understand if you're too busy to reply.--Gibson Flying V (talk) 03:25, 9 July 2014 (UTC)[reply]

Ligatures

This is an old edit, but it's worth mentioning since you seem to be making these edits in a semi-automated way. It's fine to change something like "feces" to "faeces" in a British-English article, but MOS:LIGATURES rules against "fæces", both in English and in Latin. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:16, 9 July 2014 (UTC)[reply]

Fair enough. I hadn't seen that. (It wouldn't have been semi-automated, though.) Jimp 10:56, 10 July 2014 (UTC)[reply]

July 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Matilde Calamai may have broken the syntax by modifying 4 "[]"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

In forma e salute" to [[Italia 7]] in 2002, "Idea" gravure news and interviews with celebrities on [[Canale 10 in 2003, "Prima serata" and "Lombarvie" Telelombardia in 2004, "L'Isola del Cinema" on [[
* 2008 – ''[[Vivi in Bellezza]]'' – [[RTV 38

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 16:14, 18 July 2014 (UTC)[reply]

Proposed deletion of Salvo (artist)

The article Salvo (artist) has been proposed for deletion because it appears to have no references. Under Wikipedia policy, this newly created biography of a living person will be deleted unless it has at least one reference to a reliable source that directly supports material in the article. The nominator also raised the following concern:

All biographies of living people created after March 18, 2010, must have references.

If you created the article, please don't be offended. Instead, consider improving the article. For help on inserting references, see Referencing for beginners, or ask at the help desk. Once you have provided at least one reliable source, you may remove the {{prod blp}} tag. Please do not remove the tag unless the article is sourced. If you cannot provide such a source within seven days, the article may be deleted, but you can request that it be undeleted when you are ready to add one. bpage (talk) 03:28, 1 August 2014 (UTC)[reply]

Wikipedia_talk:Manual_of_Style/Dates_and_numbers#Kilowatt-hour

I'm contacting everyone who has commented but who hasn't taken an explicit Support or Oppose position (or if you did, I missed it). In the interest of bringing this discussion to resolution, it might be helpful if you could do that. Thanks. EEng (talk) 12:59, 3 August 2014 (UTC)[reply]

New Zealand English

I've answered your questions on the https://wiki.riteme.site/wiki/Talk:New_Zealand_English page. I realise you might not have wanted specific answers but were simply trying to generate a clarification/rewrite of the "New Zealand English" page. I hope your question and my response lead to some sort of cleanup, because I consider the page unsatisfactory in its present form. Akld guy (talk) 02:30, 15 August 2014 (UTC)[reply]

Strine

I had to look up strine. Funny. Peter Horn User talk 17:09, 8 September 2014 (UTC)[reply]

Still pending

Hi
Still pending at Template talk:Convert/TonCwt to t#Just curious (latest post there)

{{TonCwtQtr to t|26|1|1}} {{TonCwtQtr to t|26|1|1}}
{{TonCwtQtr to t|134|18|2|lk=on}} {{TonCwtQtr to t|134|18|2|lk=on}}

Peter Horn User talk 21:52, 9 September 2014 (UTC)[reply]

September 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Lychee may have broken the syntax by modifying 2 "[]"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

fruit provides, among other [[dietary minerals]] in minor amounts, 7% of copper, 4% of phosphorus]] and 4% of potassium (for DV in a 2000-calorie diet) (table). Lychees are low in [[saturated fat]]
ref>{{cite web|title=One Lychee Equals Three Torches. Experts Call for Caution Over Fruit Illnesses)|url=http://www.jkwzw.com/article/27/2007/16423.html|accessdate=17 June 2011}}</ref>

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 08:13, 22 September 2014 (UTC)[reply]

ThinkPad X

I understand changing disp=flip to order=flip. But why replace the convert/flip4 templates with text equivalent? Kendall-K1 (talk) 11:19, 22 September 2014 (UTC)[reply]

Never mind, I should have checked the template talk page first. Kendall-K1 (talk) 16:23, 22 September 2014 (UTC)[reply]

FYI

FYI: [3]. CC.

can you clarify?

Minor talk page dustup: https://wiki.riteme.site/wiki/User_talk:Frietjes#Hands yet another conflict over technical language and a template created with a lot of disusssion and input. Montanabw ^(talk) 05:04, 17 October 2014 (UTC)[reply]

Relax M ... convert people are nice—we're not warriors! Johnuniq (talk) 07:06, 17 October 2014 (UTC)[reply]

Then discuss that with Frietjes??? Montanabw ^(talk) 07:14, 17 October 2014 (UTC)[reply]

Module:Convert/data

All the wikitext for Module:Convert/data is generated by a script, so manual edits are not desirable. The procedure is to add wanted units to Module:Convert/extra. Later, after confirming the units are wanted (WhatLinksHere for articles), the information is added to the master list of units, which is then processed. One of the drawbacks of the module is that there is no way (other than searching a database dump) of finding whether the units you added (hp/lb, shp/lb, kW/kg) are used. Another drawback is that with all the units in one megalist, I think we should avoid casual requests for new units that would be unlikely to get much use—I have no opinion on these. By the way, I left a rambling response at Talk:Malik Deenar re carpenter's rods. Johnuniq (talk) 06:59, 17 October 2014 (UTC)[reply]

Another feature of makeunits (the script which generates Module:Convert/data) is that it performs various checks, and it would have refused to generate the current data because it would anticipate the following error which is now in Supercapacitor:

{{val|990|u=kW/kg}} → 990 kW/kg

Because no one has defined "kW/kg" at {{val}}, the above ends up calling:

{{convert|1|kW/kg|disp=unit or text|abbr=on}} → kW/kg

That strange disp setting was added for val—the effect is that if the unit code is known, convert outputs its defined symbol; otherwise, it outputs the given text "kW/kg" (it can also handle unit name and links). However, convert assumes the underlying data is valid, and it performs a conversion before deciding what to output. At the moment, that unit exists and has default output PS/kg, but the latter does not exist, so a mouse-over of the above error text shows a complaint that PS/kg is not defined.

I'm providing all this unwanted detail in case it's of interest for the future, and I'm hoping you'll think of a fix, or raise it at convert talk. If you think there is a need for the units you defined, no problem, and I'll get around to adding them to the master list in due course. However, I don't feel like thinking about PS/kg, so I'm hoping you'll do that. A quick way to define units of this kind is as "per" units—search the docs visible at Module:Convert/extra for "per" unit for examples. I hope any new units get used. Johnuniq (talk) 09:07, 18 October 2014 (UTC)[reply]

Okay, so next time I'll add units to {{convert/extra}}, thanks for the info. The reason for adding kilowatts per kilogram was so that we could replace {{convert/scale}} on General Electric T700. It is a bit extravagant to add code for use on only one page but it's less extravagant than having a special template used only five times in articles (three times on General Electric T700 and twice on WAC Corporal, replaced with hard coding). {{Convert/scale}} is just one of many of these special templates which go pretty much unused (as you know). I can see no reason to keep them but the are clung onto for their special features. I hope one day we can do a tidy up i.e. deletions but perhaps some of these features are worth absorbing into the main template. For example, if we could (as input and/or output) take any two (or possibly more) units which are already defined and combine them (by division, multiplication, etc.), {{convert/per}} and {{convert/scale}} would become redundant. As for the kilowatts per kilogram default, I switched it to horsepower per pound, which I'd already added and which I think makes more sense anyway. Jimp 01:27, 19 October 2014 (UTC)[reply]

Sounds good! Cleaning would help here, and also help people who copy an article for translation on another Wikipedia as it reduces the number of templates they have to deal with. Johnuniq (talk) 02:49, 19 October 2014 (UTC)[reply]

Rod as a volume

I'm not sure how active the measurements wikiproject is, so would appreciate your comments at WT:WikiProject Measurement#Rod as a volume. There are some other recent edits from the same source that I'm not sure of, but that can be another time. Johnuniq (talk) 10:14, 18 December 2014 (UTC)[reply]

February 2015

Hello, I'm BracketBot. I have automatically detected that your edit to Conversion of units may have broken the syntax by modifying 1 "[]"s and 1 "{}"s likely mistaking one for another. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

| ≡ {[frac|100}} ch <ref name=CRC71/> ≡ 0.66 ft ≡ 7.92 in
|}

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 16:15, 8 February 2015 (UTC)[reply]

Template:dtsh

I used the DTSH template on tables of fraternity installation dates in sortable tables when the only information available was season, so if I had three fraternity installations as February 1, 1940, Spring 1940 and May 13, 1940, I'd do them as {{dts|1940|2|1}}, {{dtsh|1940|4|1}}Spring 1940, and {{dts|1940|5|13}} how can I do this without dtsh?Naraht (talk) 00:46, 23 February 2015 (UTC)[reply]

You can use |format=hide, i.e. {{dts|1940|4|1|format=hide}}Spring 1940. For more details see Template:Dts#Formatting. Jimp 12:58, 24 February 2015 (UTC)[reply]

Nomination for deletion of Template:Gapsize

Template:Gapsize has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 17:08, 3 March 2015 (UTC)[reply]

subst'ing in5

I'm curious to know about this edit at Old Rosin the Beau. {{in5}} isn't a template I know much about, and the documentation doesn't say anything about when it's supposed to be subst'ed and when it's not. Ibadibam (talk) 00:23, 10 March 2015 (UTC)[reply]

It's not a template many know much about and that's the point. It only serves to make the mark up of articles all the more arcane. It would be better if the thing were simply to vanish. I'm saying that templates which don't actually do anything of value should all be substituted and then deleted. Jimp 05:49, 10 March 2015 (UTC)[reply]

Gotcha. Thanks for taking the time to respond. Ibadibam (talk) 20:11, 10 March 2015 (UTC)[reply]

Mistake in Colorado article

Hello dear user. In the section Demographics in Colordao article there is a mistake.I guess someone tried to create a table, but he failed (look at the middle part of section). Please help. 217.76.1.22 (talk) 12:46, 20 March 2015 (UTC)[reply]

Fixed with this edit Ibadibam (talk) 21:49, 20 March 2015 (UTC)[reply]

Thanks. Jimp 08:42, 21 March 2015 (UTC)[reply]

Template:Change vs. Template:Noc, Template:Nof, and Template:Onc

I am curious as to why you feel that the following Wikicode:

|align=right| 1983185819,831,858

|align=right| 1956741019,567,410

|align=right| {{change|19567410|19831858|disp=out}}

is superior to:

{{nof|19831858|19567410}}

The later seems much more intuitive, more efficient, substantially shorter, and it is not redundant.

Yours aye,
Buaidh 20:06, 23 March 2015 (UTC)[reply]

My aim was to consolidate {{noc}}, {{nof}}, {{onc}}, {{onf}} and {{change2}} into one place. On two articles it didn't work so I cheated (until it can be got working). You're probably right, though, as long as {{change}} can't handle such long pages, it's probably best to reinstate {{nof}}. Jimp 01:20, 25 March 2015 (UTC)[reply]

It's working now. Jimp 05:48, 25 March 2015 (UTC)[reply]

I tried the same thing some years ago without success. Buaidh 14:49, 25 March 2015 (UTC)[reply]

Infobox person

Hi. Did you changes in Infobox person were discussed somewhere before you do them? Magioladitis (talk) 23:37, 30 March 2015 (UTC)[reply]

It's not required that every improvement be discussed but if you'd like a discussion, I'll start one. Jimp 23:30, 30 March 2015 (UTC)[reply]

I tried to add |weight= with value 75 kg and I get an extra g fro some reason. -- Magioladitis (talk) 23:37, 30 March 2015 (UTC)[reply]

Sorry about that. It should be fixed now. Jimp 23:39, 30 March 2015 (UTC)[reply]

No problem. Since the template is used in more than 100k pages we have to be cautious. I would like to be sure there is consensus for this addition. -- Magioladitis (talk) 23:45, 30 March 2015 (UTC)[reply]

Fair enough. Jimp 23:46, 30 March 2015 (UTC)[reply]

There is a problem at Template:Infobox person/weight/switch. There is an "in" and "cm" line that needs attention, and:

{{infobox person/weight|110 lb}} → 110 lb (50 kg)

Johnuniq (talk) 00:39, 31 March 2015 (UTC)[reply]

I think I fixed it, but someone should double check. I also wrapped a few inside #if: so we can find and review actual uses. Plastikspork _―Œ^(talk) 01:16, 31 March 2015 (UTC)[reply]

We should really have a more complete set of tests for these subtemplates, the output from {{Infobox person/weight|105 lbs}} and {{Infobox person/weight|7.6 stone}} requires attention. Plastikspork _―Œ^(talk) 01:22, 31 March 2015 (UTC)[reply]

We could probably safely use replace instead of sub, e.g. {{#invoke:String|replace|source={{{2|0}}}|pattern=lbs?|count=1|plain=false}}. Better yet, we could rewrite the whole thing in Lua. :-) Alakzi (talk) 01:39, 31 March 2015 (UTC)[reply]

I have a blue-sky plan of putting the functionality in convert for use by infoboxes. I was thinking of using parameter |input= which could specify a space-delimited set of values and units, and convert would use the first set which had a valid number as the value. Then I hit "5 ft 111⁄2 in" and put the idea lower-down on my todo list. Johnuniq (talk) 03:15, 31 March 2015 (UTC)[reply]

I had thought about lbs, meters, etc. It could be dealt with without too much difficulty. Yes, rewriting in Lua would be great if anyone is up for it ... and perhaps you, Johnuniq, will be. I'll look forward to the blue-sky plan (but I know how busy {{convert}} can keep you). Jimp 05:24, 31 March 2015 (UTC)[reply]

Here's code that will deal with such things as lbs.

ft & in ←→ m or cm

{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{{1|}}}<!--
-->|metre|m}}<!--
-->|meter|m}}<!--
-->|centi|c}}<!--
-->|feet|ft}}<!--
-->|foot|ft}}<!--
-->|inches|in}}<!--
-->|inch|in}}<!--
-->|ms|m}}<!--
-->|ins|in}}

in ←→ cm

{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{{1|}}}<!--
-->|centimetre|cm}}<!--
-->|centimeter|cm}}<!--
-->|inches|in}}<!--
-->|inch|in}}<!--
-->|cms|cm}}<!--
-->|ins|in}}

st & lb ←→ lb ←→ kg

{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{#invoke:String|replace|<!--
-->{{{1|}}}<!--
-->|kilogram|kg}}<!--
-->|stone|st}}<!--
-->|pound|lb}}<!--
-->|kgs|kg}}<!--
-->|lbs|lb}}<!--
-->|sts|st}}

Template:Val broken?

Please see my note at Template_talk:Val#Errors. —Quondum 20:33, 3 April 2015 (UTC)[reply]

It's now fixed. Jimp 05:19, 4 April 2015 (UTC)[reply]

Ntss template

Note that the ntss template has a sandbox and just started working on a set of testcases pages if you want to try to convert to using val. Noticed some errors with long which I haven't added test cases for yet. PaleAqua (talk) 02:12, 6 April 2015 (UTC)[reply]

Thanks. Jimp 04:01, 6 April 2015 (UTC)[reply]

Wow looks like you got all the remaining uses. I did fix a couple of them though. Thought about suggesting that last night but figured going through device rates would be a pain. You can consider this a non-objection to the speedy delete as the template creator. Only one other editor touched the template and only a few used it and many of those got replaced a while back as other options became more powerful. The one thing I wonder about is 10^3 vs 2^10 for kB vs kiB. For telecommunications and device rates have always used 10^3 ( 1000 B = 1kB ); as it does more recently with hard drives, in most other computing fields use 2^10 ( 1024 B = 1kB or 1 kiB ). But in most use cases won't make too much differences in sorting even if the wrong one is used. Though might make sense to support something similar to the long scale option in val to make kB etc. act like kiB. Though again that is probably not necessary. PaleAqua (talk) 16:36, 6 April 2015 (UTC)[reply]

There a parameter to sort by a different unit so, for example, {{val|12|u=kB|us=kiB}} will display 12 kB but sort as 12 kiB. Jimp 16:44, 6 April 2015 (UTC)[reply]

Thanks. PaleAqua (talk) 16:54, 6 April 2015 (UTC)[reply]

Age in days

Why insist on changing that? {{age in days nts|month1=02|day1=08|year1=2015}}+ works perfectly well and is easy to understand. There's never been issues with that (at least in the way it's used in pro wrestling championship lists). There are bound to be more errors caused by spelling mistakes, people forgetting the "sortable=on" parameter from the end etc. if we switch to writing out the dates in full. リボン・サルミネン (Ribbon Salminen) #GG (talk) 14:14, 10 April 2015 (UTC)[reply]

Ribbon Salminen,

Thanks for picking up on the errors.

Yes, {{age in days nts|month1=02|day1=08|year1=2015}} does work perfectly well but do you really think it's easy to understand? {{age in days|February 8, 2015|sortable=on}} seems so very much clearer to me; I mean, don't you agree? Okay, the |sortable=on bit is a little obscure but it's used by {{convert}} (which is a commonly used template) and it's arguably less obscure than tacking nts on anyway.

One can make a typo when entering numbers as well as when entering letters. Actually, it's nice that you pointed this out, though, since the this is another benefit of doing thing the way I'm proposing. A spelling mistake will give a visible error message whereas the wrong number will just give a wrong output.

Yes, people might forget to put |sortable=on but they might forget to use {{age in days nts}} and use {{age in days}} instead. You know, what I find? I find it easier to cope with fewer templates doing essentially the same thing but with a few minor (or sometimes not so minor) differences handled using parameters than to cope with a plethora of them going off in all different directions.

I'm aiming to make it easier for users by simplifying and standardising the use of these templates. This means fewer templates and more natural input.

Thanks again for your thoughts. Jimp 14:38, 10 April 2015 (UTC)[reply]

{{Age in years and days}} is acting up after your edits, see WP:VPT#An old problem in a table; it no longer tolerates spaces around values. -- [[User:Edokter]] {{talk}} 07:42, 11 April 2015 (UTC)[reply]

I'm getting an error even with the old code. It's strange that blank space isn't stripped away automatically. Jimp 08:19, 11 April 2015 (UTC)[reply]

"Column alignment"

Please stop, it looks terrible, the columns are much too far apart. BMK (talk) 09:44, 18 April 2015 (UTC)[reply]

Thank you for the explanation as what you see wrong with the edits. If the columns are too far apart, we can use a different value for the width parameter. Jimp 09:48, 18 April 2015 (UTC)[reply]

Template:Val/sortkey/unit

Recently I investigated an esoteric convert bug which was revealed by {{val|1|u=AU/s}}. That led me to notice that val is now transcluding the old convert templates (previewing that val in a sandbox shows Template:Convert/AU/s is used). That does not concern me, but I thought I would mention the issue in case it was unintended. I think it's due to the new {{val/sortkey/unit}}, although I can't figure out why it wants to do that. {{val/units}} calls convert with {{convert|1|AU/s|disp=unit or text|abbr=on}} which displays the defined symbol for the unit, if it is defined, or the given text if it is not. You probably know all this, but I thought I'd mention it so I can cross it off my list of things to check. Johnuniq (talk) 08:03, 30 April 2015 (UTC)[reply]

Yes, is was intentional ... sort of. {{Val}} is calling the old subtemplates to get the conversion factor for the purpose of sorting. I'd wanted to use Module:Convert/data but I couldn't figure out how to input a unit code and get the "scale" value back or whether that would even be possible. Is it? Or, on the other hand, could a |disp=scale be added to get this factor (unformatted & defaulting to 1) like |disp=unit or text gets the unit symbol? This was something I'd been meaning to ask you about. So, instead I used {{convert/{{{1}}}|b|d=projection}} which does the job by getting the "b" (i.e. "scale") from the old subtemplates. Jimp 08:42, 30 April 2015 (UTC)[reply]

Clever! Using the raw data would be hopeless for finding the scale because the SI units are calculated—for example, km is not in the data table. I could never work up the enthusiasm to investigate what has happened to {{ntsh}} since I first examined it a couple of years ago. The result is that the sort key output by convert is no longer exactly the same as that output by ntsh. If it weren't for that incompatibility issue, rather than an option to get the scale, why not an option to get the sort key? Convert now uses the technique you proposed to generate a "standard" sort key, as can be seen by the fact that the following all give the same key (except for ntsh's additions):

{{convert|1,234.56|km|km|disp=number|sortable=on|debug=yes}} → 7006123456000000000♠1,234.56
{{convert|1,234,560|m|m|disp=number|sortable=on|debug=yes}} → 7006123456000000000♠1,234,560
{{convert|1,234,560,000|mm|mm|disp=number|sortable=on|debug=yes}} → 7006123456000000000♠1.23456×10⁹
{{ntsh|1,234,560|debug=yes}} → 7006123456000000000♠

Some new syntax would have to return only the sort key, and the sort key would be based on the given value if the unit code was not known. I've put it on my todo for later contemplation. Johnuniq (talk) 10:08, 30 April 2015 (UTC)[reply]

By the way, AU/s is recognized as an automatic per unit, so it has a scale:

{{convert|1|AU/s|AU/s|disp=number|sortable=on|debug=yes}} → 7011149597870700000♠1.0
{{convert|60|AU/min|mph|disp=number|sortable=on|debug=yes}} → 7011149597870700000♠3.3×10¹¹

Johnuniq (talk) 10:31, 30 April 2015 (UTC)[reply]

It sounds promising. I noticed that the original version of the module was using the old (pre-2011) {{ntsh}} sort key but it that was updated some time ago. {{Ntsh}} hasn't been significantly changed since 2011 except for the addition of the "♠" which was to prevent the displayed numbers following the hidden part from interfering. I think an option to get the sort key might work. It'd take a little more rearrangement at {{val}} but the result would probably be an improvement. Jimp 10:48, 30 April 2015 (UTC)[reply]

I spent quite a while puzzling over the "♠" and it still does not make sense to me. The sort key is 19 digits but is used as a string, so only if two sort keys were identical would "♠" be considered. Since both sort keys would have that symbol as the 20th character, it would be skipped and have no effect on the sort outcome. I think one of the templates also padded with ampersands in a way that I could not understand, although a very quick look fails to find that now. Johnuniq (talk) 03:21, 1 May 2015 (UTC)[reply]

The problem is that it won't always get treated as a string. I can't quite remember where exactly I ran into this problem but it did come up somewhere. Jimp 03:40, 1 May 2015 (UTC)[reply]

Thank you for your work on {{val}}

		The Tireless Contributor Barnstar
		You were one of the first contributors to {{val}} in 2008 and I am very happy to see you still have time to improve it by leaps and bounds almost a decade later! With over 2000 transclusions and versions in almost 40 languages, your edits will surely improve Wikipedia as a whole: keep up the good work! — `SkyLined` (talk) 22:24, 1 May 2015 (UTC)[reply]

Template:Convert/date

Would you mind taking a look at this article and recommending a replacement example? --204.106.251.214 (talk) 05:06, 8 May 2015 (UTC)[reply]

Category:Unit subtemplates of Convert by year

Category:Unit subtemplates of Convert by year, which you created, has been nominated for possible deletion, merging, or renaming. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. DexDor^(talk) 12:09, 9 May 2015 (UTC)[reply]

Conversion of units

Are you sure this is what you meant to do? You changed several values and several uncertainties. For instance, {{val|3.08567782|e=16|6|erre=6|u=m}} became {{val|3.0856776|e=16|u=m}} , which would be 3.0856778200(6)×10¹⁶ m vs 3.0856776×10¹⁶ m. Many other changes are similarly suspicious. Headbomb {talk / contribs / physics / books} 19:34, 29 May 2015 (UTC)[reply]

Those which were changed were copied from the articles on the unit in question. Perhaps those articles were wrong and Conversion of units was right. Perhaps it was the other way around. They couldn't have both been right. Jimp 20:26, 29 May 2015 (UTC)[reply]

It most likely is that the individual unit articles are more up-to-date than the one on the conversion article. Either way, the value needs to match the reference given. Headbomb {talk / contribs / physics / books} 22:11, 29 May 2015 (UTC)[reply]

This is true. So, if the individual unit articles are more up-to-date, as is most likely, then we should use their references. Jimp 23:03, 29 May 2015 (UTC)[reply]

Done. Headbomb {talk / contribs / physics / books} 23:34, 29 May 2015 (UTC)[reply]

strange edit failure

Greetings!

I just tried to tweak the table in the Isotopes of hydrogen page, with a curious lack of result. The table somehow has a missing dividing line between the hydrogen-3 and hydrogen-4 sections, despite the (seemingly) identical table-section delimiters. I changed the "SimpleNuclide|Hydrogen|4" formatting (⁴
H
) to just [sup]4[/sup]H (⁴H), and the missing line then showed up in the edit preview, so I saved the change with an appropriate comment/explanation. However, after that save, the table's appearance is unchanged -- the line between the H-3 and H-4 parts is still missing, even after completely refreshing my browser page (to avoid caching problems).

Please tell me what is missing or wrong here...thanx.

---edited to add--- had to "de-format" the SimpleNuclide and Superscript tags to make the presentation here more clear

Silverhill (talk) 19:05, 5 June 2015 (UTC)[reply]

This is likely a failure of rendering at the browser, not a problem in the page itself; I've seen it before. Increase the view zoom, and the missing horizontal dividing line should reappear. —Quondum 20:25, 5 June 2015 (UTC)[reply]

OK, using zoom did indeed make the line show. (It remains strange that all of the other lines, created by the same graphics instructions, show up perfectly....)

I've reverted my edit. Silverhill (talk) 01:32, 9 June 2015 (UTC)[reply]

Please do excuse the belatedness of my getting back to you. I've been distracted by things horrible, ridiculous, amusing, sad, disturbing, depressing, pleasurable and so on. That is to say, life got in the way of Wikipedia ... it's such a nice holiday from this place. Also, I wasted a bit of time on YouTube. I'll have a look but it's either been fixed by now or it's not a WP problem. Jimp 16:49, 4 August 2015 (UTC)[reply]

A long time ago on Dutch WP

Ciao Jimp,

I saw a contribution of you to H-deletion's TP of more than nine years ago as an anonymous. Now you can if you want contribute everywhere with the same registered ID, but you probably know this very well. Thanks to technology improvement! :-) Klaas `Z4␟` V 08:59, 2 July 2015 (UTC)[reply]

Thanks, I should pop over one day (can't speak a word of Dutch though ... [PS] but that can be changed). Jimp 16:57, 4 August 2015 (UTC)[reply]

Request for comment

An editor has asked for a discussion on the deprecation of Template:English variant notice. Since you've had some involvement with the English variant notice template, you might want to participate in the discussion if you have not already done so.—Godsy^(TALK_CONT) 07:10, 14 August 2015 (UTC)[reply]

Convert templates (a note)

I thought I'd let you know that I removed the lvl-4 header from the convert discussion and turned the lvl-5s into 4s. The two nominations are separate entities at the moment. If in the future you decide to bundle other {{convert}} variants, simply list them all under the same heading (see Step II). Cheers, Primefac (talk) 18:23, 8 November 2015 (UTC)[reply]

ArbCom elections are now open!

Hi,
You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 13:03, 23 November 2015 (UTC)[reply]

Alteration of the "th" sounds in English dialects

Hi Jimp. It turns out that you had tried to merge the articles relating to alterations of the "th" sounds about a decade ago to Phonological history of English dental fricatives and someone undid the merge. I've tried to merge them again under Alterations in the pronunciation of English ⟨th⟩. Now that page is up for deletion. Perhaps you'd like to participate in the discussion. Wikipedia:Articles for deletion/Alterations in the pronunciation of English ⟨th⟩ I personally just thought that merging them would be good as they're basically just alterations of the "th" phoneme, just different dialects doing it different ways. Also the th-alveolarization article was pretty small. Fish567 (talk) 00:17, 24 November 2015 (UTC)[reply]

Template:Covert listed at Redirects for discussion

I've has asked for a discussion to address the redirect Template:Covert → Template:Convert. I thought you might want to participate in the redirect discussion. Si Trew (talk) 07:22, 28 November 2015 (UTC)[reply]

Invitation to a research survey

Hello Jimp,

I am Allen Lin, a computer science PhD student at the University of Minnesota - Twin Cities. Currently, we are working on a project studying the main article and sub article relationship in a purpose of better serving the Wikipedia article structure. We noticed that you've created main/sub article relationship in Paper size for Paper density. So it would be appreciated if you could take 4-5 minutes to finish the survey questions. Thanks in advance! We will not collect any of your personally information.

Thank you for your time to participate this survey. Your response is important for us!

https://umn.qualtrics.com/SE/?SID=SV_bvm2A1lvzYfJN9H — Preceding unsigned comment added by Cheetah90 (talk • contribs) 01:11, 30 November 2015 (UTC)[reply]

Th-alveolarization

I am proposing that th-alveolarization and th-debuccalization should be merged into alterations in the pronunciation of English ⟨th⟩. Maybe you'd like to participate in the discussion at talk:th-alveolarization Fish567 (talk) 23:40, 3 December 2015 (UTC)[reply]

RfC

Request for comments on the plan proposed at Template_talk:In_title#How_to_alter_this_template_and_its_wiki_landscaping.

I'm asserting that

the 9703 pages that use intitle or lookfrom templates must be changed by AWB or other bot to remove a stray bullet from a print preview.
"noprint" code fix in the intitle sandbox is the same one needed for the lookfrom code
Search links have not been allowed in article space (wp:elno rule 9), and so the missing guideline was only just written for this occasion.
Search links should be allowed in article space, but only if they follow "the missing guideline".

It's all clearly spelled out there (and at its predecessor talk-posting). Please comment. Thank you. — Cpiral Cpiral 07:53, 27 December 2015 (UTC)[reply]

Orders of magnitude

Hi.

a little over a year ago, you made this edit. some of the details do not seem right: for instance, according to your edit, a TEU cargo container has a capacity of 33.1 thousand cubic metres, which is clearly wrong. can you please go over this article again, and make sure everything (at least everything you yourself added) is correct? thanks. peace - קיפודנחש (aka kipod) (talk) 17:59, 18 February 2016 (UTC)[reply]

I'm not sure that I actually added anything (or if I did it would have been pretty ordinary). I didn't add the cargo containers. It looks like I added stuff but what actually happened was a merge. Jimp 19:40, 19 February 2016 (UTC)[reply]

Inflation data update

Hello Jimp, Template:Inflation/IN/dataset was created by you in 2013 and last updated by you in 2014. I am wondering how to update this (source). If you can help me with this, I would be glad to keep this live. Thanks, Arun Kumar SINGH (Talk) 08:15, 24 May 2016 (UTC)[reply]

No, thank you. That'd be great. The inflation temple uses these subpages to look up numbers with which to calculate. So, the template gives the subpage a year and the subpage gives a number. For the Indian rupee subpage, this number is the price in rupees of a thing that would have cost 100 rupees in 1953. So, if you give the subtemplate 1953, it'll return 100, and if you give it 1980, it'll give 493. A thing that would have cost 100 rupees in 1953 would have cost 493 rupees in 1980 due to inflation. Of course, we're talking about average things; prices don't all go up uniformly.

Anyway, that's the basics of what the subtemplate does. What it needs is an update. What would this same 100-1953-rupee thing be worth today, last year and in 2014? Yes, I updated it in 2014. I used the 2013 figure I got at Inflation.eu which was 10.92%. So I added the 10.92% to the ₹4,829.7 figure for 2013 to get ₹5357.1032 for 2014. The problem was that this was reverted. So, currently, it only goes up to 2013.

I think I know what the problem was though. I hadn't updated Template:Inflation-fn with the reference but I have now (so, I hope that works). You'll probably notice that in the revert |#default was added. This is good, we'll want to keep that. What that does is give the last value if the year is out of range instead of giving nothing which would cause an error. So, if we put in 2015, it'll give the 2013 number instead but at least it won't break.

Okay, now I'm going to redo the 2014 edit. That's done. All we need to do is the same thing for 2015 and 2016. You should be able to find 2014 and 2015 figures at the Inflation.eu (linked above). You might have a better source but you'd have to update Template:Inflation-fn (or I could, it's a bit tricky) lest you get reverted like I did.

Don't hesitate to ask for help if you need it. Also, Djr13 (who reverted me) might be able to help, he seems to know more about the template than I (I've put a note on his page). Jimp 14:34, 24 May 2016 (UTC)[reply]

Hello, fyi I responded on my talk page. Thanks for looking into updating this! djr13 (talk) 16:34, 24 May 2016 (UTC)[reply]

Hello Jimp, thanks for the quick reply. Editors like you make a lot of different to Wikipedia and I just want to thank you for your valuable contributions. I checked your reply and following is what I understood and have few comments for you and for Djr13;

I assume that average CPI numbers (and not Dec vs Dec) have been picked up from Inflation.eu. That table has data only from 1958 (perhaps they removed 1953 to 1957).
2014 update in not reflecting on a page where the template was used (check this). It still gives value till 2013.
At Inflation.eu, I noticed that 1958 CPI was 4.74%. In the template when I checked, I found that 1957 cost was 105.3 and 1958 cost was 108.4 (YoY CPI increase of 2.94%). Going by 4.74%, 1958 number works out to be 110.2912 (105.3 + 4.74%). Did I understand this incorrectly? Perhaps the inflation number obtained was from a different source, hence this difference. I checked all the years and using the method you explained, I have calculated each years cost numbers as following.

1953= 100
1954= 104.6
1955= 97.5
1956= 92.4
1957= 105.3
1958= 110.29
1959= 115.38
1960= 117.49
1961= 119.47
1962= 123.81
1963= 127.45
1964= 144.36
1965= 158.29
1966= 175.34
1967= 198.36
1968= 205.03
1969= 203.88
1970= 214.26
1971= 220.84
1972= 235.04
1973= 274.5
1974= 352.78
1975= 376.14
1976= 347.66
1977= 376.56
1978= 386.12
1979= 410.18
1980= 456.85
1981= 516.75
1982= 557.72
1983= 623.7
1984= 676.28
1985= 713.82
1986= 776.06
1987= 844.28
1988= 923.55
1989= 989.22
1990= 1077.46
1991= 1227.01
1992= 1372.78
1993= 1459.4
1994= 1608.84
1995= 1773.26
1996= 1932.5
1997= 2072.61
1998= 2345.57
1999= 2459.1
2000= 2557.95
2001= 2654.39
2002= 2768.79
2003= 2874.28
2004= 2982.64
2005= 3109.41
2006= 3289.44
2007= 3499.64
2008= 3790.81
2009= 4201.35
2010= 4710.13
2011= 5127.92
2012= 5604.82
2013= 6216.87
2014= 6612.88
2015= 7001.72
2016= 7397.32

How do you two suggest we update this up and also make sure that the template used in articles are updated with recent values? Thanks again, Arun Kumar SINGH (Talk) 16:41, 24 May 2016 (UTC)[reply]

Remember, as I mentioned in my reply, there are multiple pages which you must update in order for the data to be reflected in calculations. In particular, the template does not know that the latest year available was changed.

Regarding the inflation calculation on RLV-TD#Low cost operations, that doesn't actually use Template:Inflation directly, but rather Template:INRConvert which has its own complex set of issues. In fact I'm surprised it works at all on that page anymore. Look for example how badly this is broken: Template:Indian Rupee. Sooner or later all these inflation templates will need to be consolidated and fixed, which I proposed here: Wikipedia talk:Lua/Archive 4#Currency and inflation templates.

Unfortunately I don't at this moment have the time or mental clarity to help rectifying the two data sources. Make sure you know precisely how and why they differ before attempting to merge them. djr13 (talk) 17:15, 24 May 2016 (UTC)[reply]

@Arun:

There is no need to update the subtemplate until 2017. It has already been updated. Also, there should be no need to update the pages using the template. This should happen automatically if the template is used correctly. The RLV-TD page is working correctly. In edit mode, you'll notice that the |year= parameter in the template call is given the value 2016. So, it's calculating from 2016 to the current year. Since the current year is 2016, it calculates zero inflation. Of course, this means a pretty odd looking output, "₹95 crore (equivalent to ₹95 crore or US$14.1 million in 2016)". It should output "₹95 crore (US$14.1 million)" if the start year is the current year. {{INRConvert}} is in need of an overhaul (which I was going to do a while ago but hadn't had the time). As for the different numbers that were there before, yes, they were from a different source; I'm not sure which though because it was someone else who compiled them (I only added a year or two). Jimp 17:04, 25 May 2016 (UTC)[reply]

@Djr13:

Thanks for you help. I've replaced the plain hyperlink with a proper citation as you've suggested (using {{citation}}). Regarding the #default, I think you've made a good point that it's not desireable as it's misleading; so, let's ditch it. {{INRConvert}} could do with some work. We'll have to account for the possibility of missing years in the datasheet when doing so so as not to have it just fail. Thanks for the tip regarding updating {{Inflation-year}}. It ain't the most user-friendly template design (I should talk). You're right, the whole thing needs a rewrite and possibly a merging into a single simple template. It might as well be done using Lua. Jimp 17:04, 25 May 2016 (UTC)[reply]

I actually changed Template:Inflation to give errors instead of silently ignoring missing years. It resulted in several hundred pages being methodically fixed when these errors were loudly revealed rather than hidden away.

Of course, it also exposed errors in some other templates. Template:INRConvert and Template:PKRConvert were too complex, too fragmented and too flawed due to their reliance on a single arbitrarily-updated conversion rate rather than historical conversion data, for me to try fixing. This is one of the big things that motivated me to write the Lua proposal. If you feel like working on INRConvert anyway, look at the Template:Inflation documentation, I overhauled the documentation with a large number of test cases and caveats. INRConvert will need to readily handle those...and many more. djr13 (talk) 21:22, 25 May 2016 (UTC)[reply]

Also, I must admit, as unhelpful as it is to say without substantiation, that I have a hunch that something was mishandled in the updated inflation index using the new source. As I told the other editor, make sure you know precisely how and why they differ before attempting to merge them. If you're using a new source, and you can't figure out how or why they differ, you can completely replace the old source, but it means you can not just toss the new data on top of the old, you would need to remove all those years 1953-1958 or so which aren't covered by the new source. Like, why did 1958's index increase from 108.4 to 110.3 but 1957's index remained at 105.3? djr13 (talk) 21:30, 25 May 2016 (UTC)[reply]

Hi Jimp & djr13; wow. I did not know that I am "opening a can of worms". It's more complicated and entangled than I thought. Thanks for all your time and do let me know if I can be of some help. Being an India related subject, I would love to offer help in best of my capabilities. Cheers, Arun Kumar SINGH (Talk) 08:21, 26 May 2016 (UTC)[reply]

The can of worms was already open. Actually, if you're keen, though, we are going to need yearly updates to the template. Another thing, if you're interested, that you might like to help with would be keeping the exchange rates at {{INRConvert}} up to date. Jimp 13:57, 26 May 2016 (UTC)[reply]

Namik_(dessert)

Hi! i want to report something. This article is created by Turkish trolls. They want to name "Android N" as "Android Namık". There is no such dessert. This page also deleted in trwiki beacuse of vandalism. 85.110.54.4 (talk) 10:28, 29 May 2016 (UTC)[reply]

Can I suggest you take it up at WP:AFD? I know very little about Turkish food. Jimp 14:30, 29 May 2016 (UTC)[reply]

Template:Change

Hi there,

Thanks for enhancing the percent change template a little while ago, I've used it extensively. I'm wondering if you would be able to help me find a solution to a little glitch in the template. I'm looking to place a reference on one of the numbers, but the "suf=" doubles it, placing it on both numbers. Would it be possible to create "suf1=" and "suf2=" to create individual suffixes for the numbers?

Thanks! Mattximus (talk) 23:17, 23 June 2016 (UTC)[reply]

Done. Jimp 05:16, 25 June 2016 (UTC)[reply]

June 2016

Hello, I'm BracketBot. I have automatically detected that your edit to Decimetre may have broken the syntax by modifying 1 "{}"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

[American and British English spelling differences#-re, -er|American English]]); SI symbol '''dm''') is a [[Units of measurement|unit]] of [[length]] in the [[metric system]], equal to one tenth of a

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 05:08, 27 June 2016 (UTC)[reply]

Hello, I'm BracketBot. I have automatically detected that your edit to Redhead (bird) may have broken the syntax by modifying 1 "[]"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

by mid-March. In western North America, migrants begin arriving in Oregon, British Columbia] and Colorado in February. In central North America, migrants arrive as soon as temperatures open

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 01:53, 28 June 2016 (UTC)[reply]

DYKtalk template

You made a change with this edit to the DYKtalk template documentation.

According to the documentation, the template uses the form:

But the form that the DYK bot uses is:

Should I change the documentation back to its original form? The FACBot has to be able to parse these entires. Hawkeye7 (talk) 00:54, 23 August 2016 (UTC)[reply]

Perhaps we could talk to the operator of the bot. I guessing that it would have to be easier to get the bot to handle normal whole dates rather than forcing users to separate them into two parameters. Jimp 01:08, 24 August 2016 (UTC)[reply]

Fine for Shubinator, but it won't help me. The FACBot will still have to parse both forms. Hawkeye7 (talk) 04:23, 24 August 2016 (UTC)[reply]

Go with whichever is easier I s'pose. Jimp 10:26, 24 August 2016 (UTC)[reply]

Extended confirmed protection

Hello, Jimp. This message is intended to notify administrators of important changes to the protection policy.

Extended confirmed protection (also known as "30/500 protection") is a new level of page protection that only allows edits from accounts at least 30 days old and with 500 edits. The automatically assigned "extended confirmed" user right was created for this purpose. The protection level was created following this community discussion with the primary intention of enforcing various arbitration remedies that prohibited editors under the "30 days/500 edits" threshold to edit certain topic areas.

In July and August 2016, a request for comment established consensus for community use of the new protection level. Administrators are authorized to apply extended confirmed protection to combat any form of disruption (e.g. vandalism, sock puppetry, edit warring, etc.) on any topic, subject to the following conditions:

Extended confirmed protection may only be used in cases where semi-protection has proven ineffective. It should not be used as a first resort.
A bot will post a notification at Wikipedia:Administrators' noticeboard of each use. MusikBot currently does this by updating a report, which is transcluded onto the noticeboard.

Please review the protection policy carefully before using this new level of protection on pages. Thank you.
This message was sent to the administrators' mass message list. To opt-out of future messages, please remove yourself from the list. 17:49, 23 September 2016 (UTC)

Nomination for deletion of Template:Chem/3

Template:Chem/3 has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 14:04, 30 October 2016 (UTC)[reply]

Thanks. I'd forgotten about those. I've deleted them. Jimp 02:27, 31 October 2016 (UTC)[reply]

Two-Factor Authentication now available for admins

Hello,

Please note that TOTP based two-factor authentication is now available for all administrators. In light of the recent compromised accounts, you are encouraged to add this additional layer of security to your account. It may be enabled on your preferences page in the "User profile" tab under the "Basic information" section. For basic instructions on how to enable two-factor authentication, please see the developing help page for additional information. Important: Be sure to record the two-factor authentication key and the single use keys. If you lose your two factor authentication and do not have the keys, it's possible that your account will not be recoverable. Furthermore, you are encouraged to utilize a unique password and two-factor authentication for the email account associated with your Wikimedia account. This measure will assist in safeguarding your account from malicious password resets. Comments, questions, and concerns may be directed to the thread on the administrators' noticeboard. MediaWiki message delivery (talk) 20:33, 12 November 2016 (UTC)[reply]

A new user right for New Page Patrollers

Hi Jimp.

A new user group, New Page Reviewer, has been created in a move to greatly improve the standard of new page patrolling. The user right can be granted by any admin at PERM. It is highly recommended that admins look beyond the simple numerical threshold and satisfy themselves that the candidates have the required skills of communication and an advanced knowledge of notability and deletion. Admins are automatically included in this user right.

It is anticipated that this user right will significantly reduce the work load of admins who patrol the performance of the patrollers. However,due to the complexity of the rollout, some rights may have been accorded that may later need to be withdrawn, so some help will still be needed to some extent when discovering wrongly applied deletion tags or inappropriate pages that escape the attention of less experienced reviewers, and above all, hasty and bitey tagging for maintenance. User warnings are available here but very often a friendly custom message works best.

If you have any questions about this user right, don't hesitate to join us at WT:NPR. (Sent to all admins).MediaWiki message delivery (talk) 13:47, 15 November 2016 (UTC)[reply]

ArbCom Elections 2016: Voting now open!

Hello, Jimp. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)[reply]

Nomination for deletion of Template:Ordinal/th

Template:Ordinal/th has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 19:00, 22 November 2016 (UTC)[reply]

Nomination for deletion of Template:Numtext/0

Template:Numtext/0 has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 19:05, 22 November 2016 (UTC)[reply]

Template:Vgrsort1 listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Template:Vgrsort1. Since you had some involvement with the Template:Vgrsort1 redirect, you might want to participate in the redirect discussion if you have not already done so. Lordtobi (✉) 10:58, 3 January 2017 (UTC)[reply]