Unit converter (no longer maintained)

[jason0x43]

Note: This workflow is no longer maintained.

 

This is a really simple workflow that performs unit conversions. Conversion commands look like:

 

    u {value} {in units} > {out units}

 

You can include a space after the u keyword, but it's not required. Units can generally be abbreviated or not, as long as the input is unambiguous. Here are some valid commands:

• u 5km > miles
• u 5km > mi
• u5km>mi

You can also do unit math (again, spaces are generally optional):

• u 1cm * 1in
• u 1in^2 / 2mm^2
• u1cm+2.5in-3mm>ft

Just remember that units matter. You won't get any output if you try to do something like 1cm * 1in > in, because multiplying two lengths gives an area (like in^2).

 

The calculator is called as you type, so it'll give you an answer whenever you type a query it can process. Actioning the result will copy the value (just the number) to the clipboard. That's it!

 

Well, there are also a couple options you can configure. You can open the configuration file with the command u>. The options are:

• "separator" - what separator to use between the input value and output units
• "precision" - how many decimal digits to include in the output (set to null for unlimited)

 

More info and source is available here.

 

 

Download

 

 

Update 2014/05/22:

 

You can now use a space between a number and its units (e.g., "5 km" in addition to "5km").

 

Update 2014/02/06:

 

Unit math is back!

 

Update 2013/12/07:

 

Add output precision option (see above)

 

Update 2013/12/01 (again):

 

Bug fix

 

Update 2013/12/01:

 

Added support for using "space" as the unit separator, so you can do queries like "1mile km".

 

Update 2013/11/30:

 

Added Euros to the currency list. I also added a couple extra commands, accessible with the 'u>' command,

 

Update 2013/11/29:

 

Currency conversion is back.

 

Update 2013/11/25:

 

At last, I pushed out an update that should have this back up and running. It's using a local library now, so it's faster and not subject to the whims of Google. Sorry it took so long.

 

Update 2013/11/5:

 

Google shutdown the API this workflow was using on November 1, so it's broken until I switch it to something else. Sorry about that. I'll have it back up and running in a day or two.

 

Update 2013/10/11:

 

Bugfix

 

Update 2013/8/14:

 

It should now work with Snow Leopard (Python 2.6).

 

Update 2013/8/13:

 

Now with Alleyoop support!

Edited November 16, 2016 by jason0x43
Update workflow status

[gekkoh]

Very useful and perfectly executed extension. Thank you so much for sharing! 

[jason0x43]

Very useful and perfectly executed extension. Thank you so much for sharing! 

 

Thanks, I'm glad you like it!

[Southgirl]

Works great so far, thanks!

[poganinja]

HI i am new to this forum ................

[spacecadet9]

Great workflow, thanks

[pixelbrain]

Brilliant! Thanks.

[RodgerWW]

Handy, thank you for this!

[jason0x43]

Couple of updates today to handle values with scientific notation and with spaces (Google uses spaces as thousands separators). Thanks to mganjoo for pointing the issue out (and for submitting a fix that I didn't see until I pushed my own).

Edited August 13, 2013 by jason0x43

[jason0x43]

Yet another text reformatting fix -- the workflow now handles fractional extra info. For instance, if you query "1 cm in ft" you get back "0.032808399 feet (25/64 inch)".

[jason0x43]

I just added a new freeform query mode to the workflow. Now you can use the uq keyword to do crazy things like:

 

1cm * 1in

1in^2 / 2mm^2

1cm + 2.5in - 3mm > ft

[jason0x43]

Now with Alleyoop support!

Edited August 13, 2013 by jason0x43

[Southgirl]

So, I started using this one in Snow Leopard recently (never had a problem in Lion). And it just won't work as it is happening a lot lately with many workflows

 

As you can see, it is installed (I changed the keyword to uc)

 

 

But then...

 

 

I tried clearing the cache and reinstalling, but nothing's changed so far.

[jason0x43]

So, I started using this one in Snow Leopard recently (never had a problem in Lion). And it just won't work as it is happening a lot lately with many workflows

 

As you can see, it is installed (I changed the keyword to uc)

 

---

 

I almost replied before I noticed the "I changed the keyword to uc" bit.

 

Let me take a look at it and I'll see what's up...

[jason0x43]

So, I started using this one in Snow Leopard recently (never had a problem in Lion). And it just won't work as it is happening a lot lately with many workflows

As you can see, it is installed (I changed the keyword to uc)

...

And now I've actually processed the rest of your post. It apparently takes several passes for me to actually read something. /sigh

Anyway, the problem was that I hadn't tested the workflow with Python 2.6, which is what Snow Leopard comes with. I fixed a few incompatibilities, so it should work now.

Edited August 14, 2013 by jason0x43

[Southgirl]

And now I've actually processed the rest of your post. It apparently takes several passes for me to actually read something. /sigh

Anyway, the problem was that I hadn't tested the workflow with Python 2.6, which is what Snow Leopard comes with. I fixed a few incompatibilities, so it should work now.

 

Wow, that was fast. It works now! Thanks

[jason0x43]

I just pushed an update that fixes a show-stopping bug (internal XML parsing issue), if anyone was having issues.

[jason0x43]

Google shutdown the API this workflow was using on November 1, so it's broken until I switch it to something else. Sorry about that. I'll have it back up and running in a day or two.

[jaster]

I will eagerly wait since I've enjoyed using your workflow the most amongst the other unit converters.

[rice.shawn]

There might be some python libraries or scripts that are already written that can handle this sort of thing natively. Maybe you can look to see if those exist to get this thing up and running again and to make it work offline.

[jason0x43]

Ok, it's been way too long since I updated this. I've pushed out an updated version that uses a local library rather than a web service. I was a bit worried about input processing (that was half the fun of using Google -- I could just throw stuff at Google and get back a reasonable answer), but I found a library that's pretty flexible, Hernan Grecco's excellent Pint (https://github.com/hgrecco/pint).

 

I simplified the interface a bit. There's only a single command now, u, and a single query format, "u {input value} > {output units}" (like "u 1mile > km"). You can still do unit math with queries like "u 1mile + 220m > km", and you can drop spaces that don't make the input ambiguous ("u1mile+220m>km").

[jason0x43]

There might be some python libraries or scripts that are already written that can handle this sort of thing natively. Maybe you can look to see if those exist to get this thing up and running again and to make it work offline.

 

This was, indeed, the way to go.

[rice.shawn]

I'm glad you found a good library to do this. It helps ensure that the workflow won't break again, it'll probably go much faster because you don't need a web request, and you can also use it when an internet connection isn't available.

 

Ok, it's been way too long since I updated this. I've pushed out an updated version that uses a local library rather than a web service. I was a bit worried about input processing (that was half the fun of using Google -- I could just throw stuff at Google and get back a reasonable answer), but I found a library that's pretty flexible, Hernan Grecco's excellent Pint (https://github.com/hgrecco/pint).

 

I completely understand that fun of writing something just to play with an api; it's definitely something I've done more than once. It's similarly fun to do the same with a library though. Update looks great. Thanks!

[glgray]

Ok, it's been way too long since I updated this. I've pushed out an updated version that uses a local library rather than a web service. I was a bit worried about input processing (that was half the fun of using Google -- I could just throw stuff at Google and get back a reasonable answer), but I found a library that's pretty flexible, Hernan Grecco's excellent Pint (https://github.com/hgrecco/pint).

 

I simplified the interface a bit. There's only a single command now, u, and a single query format, "u {input value} > {output units}" (like "u 1mile > km"). You can still do unit math with queries like "u 1mile + 220m > km", and you can drop spaces that don't make the input ambiguous ("u1mile+220m>km").

 

This looks great! Is there a place we can see what units it supports? I have looked at https://github.com/hgrecco/pint and at https://github.com/jason0x43/jc-units and haven't been able to find this information.

 

Thank you!

[jason0x43]

This looks great! Is there a place we can see what units it supports? I have looked at https://github.com/hgrecco/pint and at https://github.com/jason0x43/jc-units and haven't been able to find this information.

 

Thank you!

 

The built-in list of units is here: https://github.com/hgrecco/pint/blob/master/pint/default_en.txt. My additions are here: https://github.com/jason0x43/jc-units/blob/master/unit_defs.txt. I just added "C" and "F" for temperature (different names) and a definition for hectare (just for fun).

 

The unit system is easy to extend, although it doesn't seem to automatically handle unit name clashes. I have some simple logic in the workflow to deal with situations like "u 1cup>oz", where the unit name "oz" refers to weight ounces, but we mean fluid ounces. Basically I have a table of alternate possibilities for some unit names. If a conversion fails and either the source or destination units are in the table, the converter tries again with the alternate units.