rice.shawn

The image you posted was the "Please Wait" subtext, which means the script was running but hadn't output anything yet. The API is a bit slow, and if your internet connection is a bit slow, and if you turned on a lot of languages, then it will take a while longer to process everything. So, you probably just need to wait a bit longer.

Unfortunately, Domainr changed their API. So, a rewrite is needed. The new version of the API also requires an API key, which means users will have to register for the API, etc... It's kind of a pain.

It's some weirdness with the metadata. I promise you that it will never actually "downgrade" a workflow because it will always get the most recent copy from the github repo. There's just a weird metadata mismatch between the master manifest and workflow right now that might sort itself out (based on a periodic cron job that does a correction for this problem). The problem actually comes from when workflow authors update the workflow and then go back and update the workflow version because updating the text fields doesn't queue the expensive backend processing on the server that re-packages the workflows and re-builds the manifest files. Hopefully I'll be able to roll-out the newer version of Packal sometime soon that will take care of these problems, but, for now, it's nothing to worry about. It's just annoying.

Since Packal uses Github as a backend for the repository, you can usually find older versions in the version history for the file. Here's the one for skimmer, if you want to try to downgrade and see if that fixes your problem.

Well, if you want quick way to copy the date, then you could make a workflow that has a hotkey that leads to a bash script that leads to a copy to clipboard action. The bash script would just need to be something like date +%Y-%m-%d For more on the date command, see the man pages.

What you've done, theoretically, should work. Have you tried changing the script to an osascript instead of a NSAppleScript to see if it solves the problem of non-running applications launching? For the double launching, you could try something like: if application "MacVim" is running then tell application "MacVim" activate do script "" end tell else tell application "MacVim" to activate end if It's longer, and, again, theoretically, there should be no difference, but I've seen that it sometimes does make a difference.

Added it in and tested it out. It's available in v1.22 on Packal now.

If you have a basic understanding of PHP, then you could use my Alphred PHP library (documentation) and put this together fairly quickly. Basically, you'd create a Script Filter that would be PHP, and then you'd import the TSV file into an array and then use the filter functionality with that and the typed query. After that, you'd just throw the remaining results through a foreach loop and populate them with the script filter functionality. Just make sure you match the URL to the arg, and then you connect it to the open URL action, and you're done. Here's some untested code for the script filter: // You might need to uncomment the next line // ini_set( 'auto_detect_line_endings', true); // require Alphred library require_once( __DIR__ . '/Alphred.phar' ); // create an alphred object $alphred = new Alphred([ 'error_on_empty' => true ]); // Read the TSV file called "urls.tsv" into the $data array $count = 0; if ( FALSE !== ( $handle = fopen( __DIR__ . '/urls.tsv', 'r' ) ) ) { // I'm using a tab as the third argument, which is the separator while ( FALSE !== ( $row = fgetcsv( $handle, 0, ' ' ) ) ) : $data[ $count ]['title'] = $row[0]; $data[ $count ]['url'] = $row[1]; $count++; endwhile; fclose( $handle ); } // {query} will be set via Alfred $query = "{query}"; $data = $alphred->filter( $data, $query, 'title' ); foreach ( $data as $d ) : $alphred->add_result([ 'title' => $d['title'], 'arg' => $d['url'], 'autocomplete' => $d['title'], 'valid' => true ]); endforeach; $alphred->to_xml();

Any OS updates shouldn't matter (I've updated, and it still works on mine). Previous versions of the workflow will not work because Google changed the API endpoint, which should give you that strange redirect. If you open the page, then it will be a captcha challenge that leads no where. The new one should give some malformed JSON data (that the workflow reworks into valid json).

Yes. That's what it's supposed to have. It runs a PHP script with the query. If you can, would you try to open a terminal in the workflow directory and run the command "php filter.php testing" and see what comes out of it? Or open the debug window and run the workflow and see if there is anything informative there. The API is fairly slow, and so it might just be slow running.

You might be double-executing the command: bin=$(`type -p qrencode`) Just try bin=$(type -p qrencode) The $(cmd) creates a subshell that runs the command and returns the text. Another possibility would be that Alfred loads a neutral shell (this isn't the right term), but that means it doesn't load your .bashrc or .bash_profile files. Instead, you could do something like: if [[ ! -f /usr/local/bin/qrencode ]]; then # Do whatever failure you need to here because the program isn't installed exit 1 fi because thats where Homebrew puts everything.

The keyword is "trans" not "tr"

I just pushed an update that should fix those settings and also fix an icon.

It seems to work. The API is a bit slow, so if you have a spotty internet connection, then the results might not show up for a while. Those are my only thoughts.

It seems like the first thing to do is to check your workflows directory to see if the workflow was installed. Alfredworkflow files are actually just renamed zip files, and Alfred unzips them into the correct directory. Then, it modifies the info.plist file to migrate hotkeys and keywords (in the note). Depending on how many workflows you've installed, it might take a little while. If you're comfortable using the terminal, then just go to the workflows directory and type grep -R "Yannick" * Since "Yannick Galatol" created that workflow, the string should show up in an info.plist file. If it doesn't, then that means that the workflow wasn't unzipped into the directory. If it does, then it might point to a corrupted info.plist file. This might indicate a bug with Alfred.

Okay. It can work. I just updated mine. The endpoint has changed slightly, so the URL needs to be corrected. Also, the trick to get good JSON that Dean pointed out a few posts back no longer works, so you have to scrub the data. Next, the keys seem to have changed in that they're all just numeric arrays. Here's what I did (it is truly an inelegant hack, but I just wanted to get it working again), so you can crib from it to get this one working again. foreach ( $languages as $code => $name ) : $query = "http://translate.google.com/translate_a/single?client=json&ie=UTF-8&oe=UTF-8"; $query .= "&dt=bd&dt=ex&dt=ld&dt=md&dt=qca&dt=rw&dt=rm&dt=ss&dt=t&dt=at"; $query .= "&q=" . urlencode( $text ); $query .= "&hl=en&sl=auto&"; $query .= "tl=" . $code; $trans = file_get_contents( $query ); while ( false !== strpos( $trans, '[,' ) ) : $trans = str_replace( '[,', '[null,', $trans ); endwhile; while ( false !== strpos( $trans, ',,' ) ) : $trans = str_replace( ',,', ',null,', $trans ); endwhile; $trans = json_decode( $trans, true ); $string = ''; foreach ( $trans[0] as $t ) : $string .= trim( $t[0] ) . ' '; endforeach; $w->result( '', $string, $string, "$name: $text", "icons/$code.png", 'yes', '' ); endforeach; (Note: mine lets you use multiple languages at once, so that's why there is the big foreach loop. I haven't updated this to use Alphred yet, so it still uses David's Workflows library) The while loops scrub the response into something that json_decode can read.

Fixed it. So, v1.2 (now available on Packal) should work. Updates away.

Actually, I think I found a way around it. I need to do some more testing to make sure, but there is some hope.

It looks like Translate Shell (which used the same path) found a new way to use it. It should easily be adaptable. So this means that they didn't close it; they just changed it....

I don't think it is new. The endpoint that this (and my) workflow used was unofficial, and the paid translation API has been around for quite a while. So, these just used a sort of backdoor that Google had left open. Now, the URL leads to a redirect captcha challenge that redirects nowhere. It's a pity that they closed the endpoint, but we can't be too mad because it was never official to begin with.

Maybe. Look around in the Evernote workflow thread. You can find better information there.

It looks like it's receiving a 503 Service Unavailable Error, which means that Google has changed the way it's done things. The endpoint that this and the other Google Translate workflow was using was never official, so they might have just shut it off. The official one is paid. If you know of another way to access an unofficial endpoint, then I can look into fixing this one.

Opening Google search is just the "fallback" search, which means that the workflow failed to produce any usable results for Alfred. This happened to me as well at some point with some upgrade. To fix it, just open the file battery.sh in the workflow and, around line 81, change <title>$TEMPERATURE° C</title> <subtitle>Temperature</subtitle> <icon>temp.png</icon> </item> to <title>${TEMPERATURE}° C</title> <subtitle>Temperature</subtitle> <icon>temp.png</icon> </item> So, probably some Yosemite upgrade changed a version of Bash, and that version of Bash chokes when the degree symbol is next to a variable.

If I remember correctly, the Evernote workflow doesn't work if you installed it via the Mac App Store; instead, you have to install Evernote from the Evernote website itself. Look for the Evernote workflow thread in the "Share your Workflows" forum here, and you'll see a lot more information.

Try the following: This code: set theURL to "http://www.google.com" tell application "Google Chrome" set newTab to make new tab at end of tabs of window 1 set URL of newTab to theURL end tell will open Google in a new tab in Chrome. The address for Google is saved as a variable (`theURL`), which is the same variable name that the workflow uses (if I remember correctly). So just adapt that code where relevant above.