rice.shawn

Try adding a new API key to the Google project and then plugging that one in.

While this doesn't address the problem of why it's not working, you could always just attach the hotkey to a Run Script (type Bash) with the contents: open /Applications/iTerm.app

The 403 error is happening because Google is denying you access to the translation. Read through the (short) introduction and then follow the setup instructions here: https://cloud.google.com/translate/v2/getting_started. After that, set the API key correctly in the workflow.

I just updated it on Packal to have a default of six words and a max chars count of 60 (which made the six words come out more consistently). I thought about using SecureRandom instead of rand, but since it's just picking random words, it seemed to be overkill.

Can you open up the debugger and tell me what the console says? There should be some helpful errors there. It is working for me:

Based on your specs, this php snippet (not fully tested) should do the trick: <?php // Only deals with first level directories // Get all the directories in the main directory, excluding '.' and '..' foreach ( array_diff( scan_dir( $main_dir ), [ '.', '..' ] ) as $dir ) : // check to make sure that the dir is a dir and that item.html exists if ( ! ( is_dir( $dir ) && file_exists( $dir . '/item.html' ) ) ) { continue; } // grab the contents of the file $contents = file_get_contents( $dir . '/item.html' ); // regex pattern to catch stuff with weird spacing. Add in more quotation types // if you need them $pattern = '/test[ ]*=[ ]*[\'"]([0-9]{4})-([0-9]{2})-([0-9]{2})[\'"]/'; // match all the contents preg_match( $pattern, $contents, $matches ); // the first match isn't what we want array_shift( $matches ); // we could use a join, but there is a possibility that more things would match further down, // so we'll just manually use the first three. $name = $matches[0] . '-' . $matches[1] . '-' . $matches[2]; // If you want a dry run, comment out the "rename" functions and uncomment the next two lines: // print "Renaming {$dir}/item.html to {$dir}/{$name}.html\r\n"; // print "Renaming {$dir} to {$name}\r\n"; // rename the file rename( $dir . '/item.html', $dir . '/' . $name . '.html' ); // rename the directory rename( $dir, $name ); endforeach; Read through the comments to understand it better. Unless you use this often, then you needn't create a workflow but can just run the script. If you're doing the latter, then just copy/paste that into a file called, say, "renamer.php" and drop it into the directory above all the other ones. Then open a terminal and run "php renamer.php", and you should be done. If you want to test it out first to make sure it does what you want, then comment out the "rename" lines and uncomment the "print" lines above it. The regex used should account for the minor variation that Vítor mentioned in his 2a.

Look at the first pinned item in this forum to see a thread about how to do this. The concept is actually pretty simple once you break it down: Pick a "separator" character, something unique like "|" or ">" or " > " (it can be a string). Then, when the script filter runs, break apart the string based on the separator. So, if you chose ">", then the query: "first option>second option" would break into (1) first option (2) second option Next, make sure that you set the option to be invalid and have no argument. If it's valid or has an argument, then pressing enter on it will cause Alfred to pass the argument (or null) through to the next workflow object (or to /dev/null). Have the autocomplete field be the full option. So, if the user types "keyword fir", you would filter against an array (or dictionary) of possible "first-level" options and display only what is needed. There would be an xml entry for "first option" that would be invalid with no argument and have the auto-complete set to "first option". The same goes for "second option". Invalid, no argument, autocomplete "first option > second option". Dean's Python Alfred Workflows library takes care of the filtering and all the hard stuff for you. Use that one.

You can't run a script filter without a keyword. Andrew wrote it this way to ensure performance; otherwise, the script would run on every key press, slowing down Alfred as it waited for the script to finish. If you installed a few workflows that ran like that, then it would slow everything down. However, there is a hack. You could set the keyword to 'http://' or to 'www.' or something like that. If you wanted it closer, then you could set the keyword to either 'h' or 'w'. If you want to query domains that might start with any letter, then you could set 26 keywords (one for each letter of the alphabet) that all run the same script filter. If you do it that way, then there are three things to remember: (1) make sure that there is no space needed to run the script (checkbox in the keyword settings) (2) remember that the first letter won't be in {query}, so for each script filter, make sure you prepend it to the query. (3) exit early and often so that you don't slow Alfred down immensely.

In the workflow, set it to Bash and have the command be: osascript activate.scpt "<INSERT URL HERE>" Create a file called "activate.scpt" and place it in the root of the workflow directory. on run argv set theUrl to item 1 of argv tell application "Google Chrome" if (count every window) = 0 then make new window end if set found to false set theTabIndex to -1 set theWindowIndex to 0 repeat with theWindow in every window set theWindowIndex to theWindowIndex + 1 set theTabIndex to 0 repeat with theTab in every tab of theWindow set theTabIndex to theTabIndex + 1 if the URL of theTab contains theUrl then set found to true exit repeat end if end repeat if found then exit repeat end if end repeat if found then set theWindow's active tab index to theTabIndex activate window theWindow tell application "System Events" to tell process "Google Chrome" delay 1 perform action "AXRaise" of window theWindowIndex end tell set the index of theWindow to 1 else tell window 1 to make new tab with properties {URL:theUrl} end if end tell end run This gets you there. It sometimes doesn't bring up the main window if multiple ones are there. I just haven't had time to debug it.

I'm going to leave it up there in case anyone has any interest in the code. A newer version of Packal (yet to be released; sorry, so busy), has a deprecated flag that can be set as well as a deprecated_for flag that will notify the users as to which one to download.

Translate API has been updated to v 1.10, which includes multiple language support. If you update to this version, then you'll have to reset the languages again (even if you want to use only one). Packal: http://www.packal.org/workflow/translate-api

I force-cleared the caches, so they should be fine. Let me know if they're not.

Are you using the Translate workflow or the Translate API workflow? The first one (keyword: trans) no longer works because Google shutdown that API. The second one (keyword: tr) should be working quite well, but you need to get an API key from Google before it can work.

I've been way swamped. Too much so to get back to this right now. The code isn't too hard to write, but the UX part is more difficult to work out.

When you first start typing, it should tell you that there is no API key installed. Just press enter, and it will bring up an AppleScript dialog box that you can paste your API key into. After that, it's stored in the OS X Keychain, so you can either manipulate it there, or just delete it from there.

I could re-implement that logic. I took it out because the new one is paid, and I didn't want users to blow extra characters on the problem, but, again, I can re-implement it. Give me a couple of days. Work is crazy right now.

See the above posts for a better explanation. The regular translate workflow is no longer working because Google shutdown the API. You can grab the "Translate API" workflow (again see above) for a version that works with the paid API.

Yes. This behavior is expected. If you read back through the last few messages in this thread, you'll see that Google shutdown the API that the Translate workflow relied on, so there is nothing that I can do to fix this. Instead, you can download the Translate API workflow that does basically the same thing, but, instead, it uses the official Google Translate API (which is a paid API, although it is dirt cheap).

Yeah, there are new pubkeys and other metadata generated for the workflows. I have a migration path to move all of your Packal workflows from the old one to the new one. It's just a single selection in the workflow, so it should be painless. You'll just have to select, press enter, and wait for a bit (depending on how many you have installed).

Theoretically, it should work, but even after I "allow" 10.11 to work on my computer... it doesn't actually work. I've narrowed the possible problems down a little bit, but I haven't isolated the problem yet. So, as a larger update, I've rewritten Packal, and it's undergoing a testing phase right now. (There are still a few more kinks to work out). The Packal Updater has been completely redone in order to work with the new backend. The code for both are much more solid this time around, and the updater is now a more general update / search / install for workflows as well as themes. I have yet to re-implement the GUI for the updater for the new version (although there is a very handy cli utility that's included). Generally, how many of you prefer to use the GUI? I can re-implement it, but I don't want to do so if it isn't widely used. Let me know.

Okay, so if you look here: http://www.packal.org/workflow/translate-api, you'll find a new copy of this workflow that uses the paid translation API. It seems to work just fine with my tests. You'll have to get an API key from Google. The workflow has a different bundleid, so it won't replace the old one, and the keyword for this one is just "tr". I changed the behavior so that it outputs only one language at a time so that you don't pay for what you don't need. Also, the workflow is setup so that translations are cached for about a month, so if you keep translating the same word over and over, it won't actually hit the Google API after the first time. Lastly, the "speak" action was taken out because that was also part of the unofficial API that is no longer working. I'll see if I can get that back in there sometime.

It might just be that you're trying to translate strings that you already translated with the old ones. The newer version of the workflow caches the translations for some added speed, so it's probably just grabbing that information. I'm pretty sure that the unofficial API is dead, or, at the very least, I haven't figured out a way to get around it, and I haven't seen anyone else find a reliable way to do it either. I did rewrite the workflow to use the Official (paid) translation API, but I haven't posted that anywhere. While it's cooler if it's free, using the API doesn't cost too much. It works out to $20 / 2 million characters, and you're just charged for what you use. I can post that version somewhere soon if people are interested.

This question also has multiple answers based on how you're setting up the workflow. If you want to use a Script Filter to show the results instantly, then you really should use Dean's Alfred-Workflow library because it makes generating Alfred XML feedback much, much simpler. Otherwise, you need to generate the XML yourself. If you are just running a keyword -> script action -> copy to clipboard / show notification / large text, then you just need to print a string in the script, and that printed output will be passed to the next item in the workflow as `{query}`.

It looks like Google may have changed the behavior of the API endpoint. Let me know if you run into problems. The debugger will probably say something like: [STDERR: alfred.workflow.input.scriptfilter] [11:54:42][filter.php:103][ERROR] Request completely failed, and no cached data exists. cURL debug information follows: [11:54:42][filter.php:103][ERROR] cURL error number: 22 [11:54:42][filter.php:103][ERROR] cURL error message: `The requested URL returned error: 503 Service Unavailable`. If this error is widespread, then Google did change the API (or the API behavior).

Well, transliterating should be just as easy as having php run code as simple as: $args = json_decode( $argv[1], true ); print iconv( mb_detect_encoding( $args['translation'] ), "ISO-8859-1//TRANSLIT", $args['translation']); but it doesn't seem to be working so well. I keep getting some esoteric errors about characters not found in the charsets (of which they are a part), so there might be a bug in the iconv builds, which has happened before. I'll play around a bit more and see if I can figure out a way around the problem without having to write a transliteration map.