rice.shawn

There might be, but I don't know of one. However, if you just type `caff` with no argument, then the first item should tell you if caffeinate is active and for how much longer.

My initial tests with cURL failed, so I wrote it off, but I forgot about specifying the useragent. But, yeah. Setting the useragent worked. Okay, here are two PHP based solutions: If you're going the Alphred route (see above), then download that and put it in the root of your workflow directory. Then, in filter.php, add these two lines near the top: require_once( 'Alphred.phar' ); $a = new Alphred; And the new $trans line is: $trans = $a->get( $query, [ 'useragent' => 'alfredworkflow' ], 2419200, true ); If you don't want to use Alphred, then add in this code to replace the $trans line: $ch = curl_init( $query ); curl_setopt( $ch, CURLOPT_USERAGENT, 'alfredworkflow' ); curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true ); $trans = curl_exec( $ch ); curl_close( $ch ); The Alphred version has the added benefit of caching the result for about a month. Since they're translations, they shouldn't change. The caching speeds things up and shouldn't take much disk space.

So, for everyone who this workflow isn't working for, try this: Open filter.php in the workflow. Somewhere around line 60, you'll see the line $trans = file_get_contents( $query ); Change that to $trans = exec( "ruby -r open-uri -e 'puts open(\"{$query}\") { |io| io.read }'" ); Let me go ahead and make it clear that this is the hackiest hackery of a hack that I've ever put out there. But it seems like it should work until I get time to rewrite it. Please get back to me and let me know if the hack works for you.

Haha. It's obviously the one this thread is devoted to. Duh. So, it looks like: (1) both work for the part of Germany Dean is in (or at least where his VPN is registering him to be), (2) the Ruby version works everywhere tested, (3) the PHP version works only in certain places. This is such a weird bug.

I meant the original workflow. If you don't have it installed (I know you wrote your own solutions for this problem). Can you test this one-liner: php -r "print_r( file_get_contents('http://translate.google.com/translate_a/single?client=json&ie=UTF-8&oe=UTF-8&dt=bd&dt=ex&dt=ld&dt=md&dt=qca&dt=rw&dt=rm&dt=ss&dt=t&dt=at&q=hello+there&hl=en&sl=auto&tl=no' ) );" It should spit out the same garbled, pseudo-json.

PHP doesn't work but the Ruby one does?

The geographic problem makes sense. I think that the API is really just something that Google uses, so maybe it's used mostly for internal reasons (but left open) for US servers. Maybe? Let's confirm this more: can people outside of the US try the Ruby one-liner? ruby -r open-uri -e 'puts open("http://translate.google.com/translate_a/single?client=json&ie=UTF-8&oe=UTF-8&dt=bd&dt=ex&dt=ld&dt=md&dt=qca&dt=rw&dt=rm&dt=ss&dt=t&dt=at&q=hello+there&hl=en&sl=auto&tl=no") { |io| io.read }' If that one doesn't work, then I think we've found the problem.

I don't think that it has a problem to do with Dropbox because I also sync my workflows with Dropbox (and it works just fine for me). I really can't understand what's going on with this because I can't find the consistency in the problem yet to solve it. Can you tell me the difference between the two Macs?

Oh, yeah. The fix for the PHP version is only for 10.10.5 right now. Apple just used the wrong name for the dylib, and so when you tried to execute PHP it would send an error that said that it couldn't find that particular dylib. So, if any PHP command works (i.e. php -v), then it's fine. So, now I'm even a bit more confused as to why it's working just fine for me but not working for either of you. I try to keep my system pretty stock so that it's easier to debug. And we're all using php 5.5.24. ( PHP 5.5.24 (cli) (built: May 19 2015 10:10:05) ) I had a thought that it might be geography based (because sometimes companies do that sort of thing), but that would have meant that the Ruby call would have died too. I'll try to brainstorm more tomorrow as to what could be going wrong.

Dammit. So I have to conclude that the bug exists in the way that Google is denying the request object as built by PHP 5.2.20, for reasons that are far beyond me. I'll go ahead and note that the workflow relies on an unofficial API, so there is really no documentation on it whatsoever, and it's basically a backdoor for the service. It would make much more sense to me if the API endpoint threw the same error consistently rather than just the 503 when requested by PHP 5.2.20. So, two options currently exist to fix it (because the code is, technically fine). 1. Upgrade OS X. I'm currently on 10.10.5, which packages PHP 5.2.24. But, as I brought up earlier, Apple borked the PHP build.* 2. Wait for me to rewrite this thing in Ruby, which will probably take a bit because my plate is a bit full currently. So weird. Sorry there isn't better news. * The way to fix it is to run the following command from the terminal: sudo ln -s /usr/lib/libnetsnmp.30.dylib /usr/lib/libnetsnmp.25.dylib There might be unforeseen problems with this solution, but I haven't run into any of them yet.

Actually, let's see if the Alphred get methods work better (they seem to be fine on my computer). So, help me out with a simple test. Download Alphred (https://github.com/shawnrice/alphred/raw/master/build/Alphred.phar) and place it in the workflow directory. (Easiest way to find that it so ctrl+click the workflow in Alfred preferences and select "Reveal in Finder"). Then, open `filter.php`, and add in these two lines near the top: require_once( 'Alphred.phar' ); $a = new Alphred; Then replace the line: $trans = file_get_contents( $query ); with $trans = $a->get( $query, 86400, true ); Then try the workflow again to see if that works.

Okay... so, the problem is that Google is rejecting however PHP 5.5.20 constructs the request and sends a 503 status error. I think it's working for me because I'm using 5.5.24 (this is at least a difference). Let me write up another script in a minute to test another approach to constructing the request with PHP to see if that will work with PHP 5.5.20.

Okay, that is strange. There's something weird going on somewhere between Google and PHP. Let's see if Ruby throws the same error. Can you try this one-liner in the terminal? ruby -r open-uri -e 'puts open("http://translate.google.com/translate_a/single?client=json&ie=UTF-8&oe=UTF-8&dt=bd&dt=ex&dt=ld&dt=md&dt=qca&dt=rw&dt=rm&dt=ss&dt=t&dt=at&q=hello+there&hl=en&sl=auto&tl=no") { |io| io.read }'

Can you also try to do the test that I mentioned in my last post and let me know if that works?

That output helps a bit. Google is sending you a 503 HTTP status error (service unavailable). But, it kind of is still available. So, the first URL that it queries doesn't work, for instance, if you use `curl` directly from the command line. It also doesn't work if you just paste it into address bar in Chrome. Here's something else to try. Open a terminal and copy/paste the following line: php -r 'print_r(file_get_contents("http://translate.google.com/translate_a/single?client=json&ie=UTF-8&oe=UTF-8&dt=bd&dt=ex&dt=ld&dt=md&dt=qca&dt=rw&dt=rm&dt=ss&dt=t&dt=at&q=hello+there&hl=en&sl=auto&tl=no"));' It should say something like: [[["hei der","hello there",,,0]],,"en",,,[["hello there",1,[["hei der",1000,true,false],["hello there",0,true,false],["hei på",0,true,false],["hei på deg",0,true,false],["hei",0,true,false]],[[0,11]],"hello there",0,2]],0.036865726,,[["en"],,[0.036865726]],,,,,,[["Hello there!","there","hello"]]] Let me know if it says something else.

It still is working for me, which means the API endpoint is still functioning. Can you open the Alfred Debugger, run the workflow, and let me know what it says? (Open Alfred Preferences, click Workflows, Select the Translate workflow, click the little bug icon in the upper-right hand corner, then run the workflow).

If you just reinstalled Yosemite, then it might be an error with PHP itself. In the most recent Yosemite build, Apple broke PHP (seriously Apple?). So, first thing to try: open a terminal and type `php -v`. If it gives you an error saying that some 'dylib' cannot be found, then it's the PHP problem. I can't remember the name of the one off the top of my head, but it wanted a copy of it with a number, but symlinking the version without the number to the one that PHP wants fixes it. Past that, I need a bit more info. Can you open the Alfred debugger and run the workflow and let me know if it throws any errors there?

Just steal the code from the ruby version of the bundler. It's all there and works.

There was an update for OS X that broke the PHP cli, which means that all of your php workflows and scripts will have broken. (To fix this, you just need to symlink a dylib). But, if you head to the GH repo for this workflow, you'll also see this:

The file is at "~/Library/Application Support/Alfred 2/Workflow Data/com.spr.translate/config.json" Make sure that you don't open it with TextEditor, and, if you do, then make sure that you turn it onto plain text mode. The JSON will be broken by Smart Quotes, etc.

This was one of the reasons that I created Packal. So many good workflows ended up getting 404's, and so Packal was insurance that everyone could keep finding them. Alas.

This is a problem with character encoding. It's receiving a unicode character but wants an ascii character, so you have to convert the charset. Pretty much each scripting langauge has a way to do this, so just look for the relevant docs on it.

I've never seen Amphetamine before (mostly because I never looked because caffeinate works well enough for me not to install extra things). But, if you don't use the fancy scheduling features of Amphetamine but just manually invoke it and the like, then you can just use the workflow that @homever referenced (I wrote it and use it daily, so I'm, perhaps, biased). You can set some config options about hds sleeping and whatnot.

Dean's workflow that he referenced is really good. Use it.

If you'd rather work in PHP, then you can use this. (Documentation). Even though it says "not quite ready for public consumption, it really is.