juliosecco

Translate between hundreds of languages with Glosbe.com.
 

By default, the workflow is set up to translate between German and English:
.ende English query — show German translations of English query. .deen German query — show English translations of German query. ENTER — copy selected translation to the clipboard. CMD+ENTER — open translation in browser. glosbehelp — open the included help file in your browser. glosbelang [query] — view and search supported languages. To use other language pairs, you will have to edit the workflow, either changing the included English <-> German Script Filters or adding your own using them as a template.  
For more information and to download the workflow, see the Packal page or grab it from GitHub.

Audio Switch
==================================================================================
 
Switch between your input sources and output devices.
 
To install just download (or my github) and doble click the .alfredworkflow file.*
 
To change your input source type input (it could take a little bit to load your sources), then select the one you desire
 

 
The same for the output device, just type output then select your choice
 

 
Since I don't have any audio device or source connected to my laptop only 1 (the default) device and source are shown.

A workflow that could help us write CSS faster and without errors.   You can browse the list of CSS parameters selecting a category (Animations, Borders, Text, Fonts etc...) or you can filter the CSS properties list typing letters contained in the property name, or the starting letters of their abbreviation. Then you continue filtering to assign the CSS property one or more values.
When ready, action the item to have it pasted on the frontmost text application, or Cmd C to copy it on the clipboard.   Some examples, using an hotkey to start it:



Here LCC will paste also the vendor variants (if set to 'y' the respective environment variables):
  -webkit-transform: matrix(4,5,4,5,4,5); -moz-transform: matrix(4,5,4,5,4,5); -ms-transform: matrix(4,5,4,5,4,5); transform: matrix(4,5,4,5,4,5);
Yo can set various environment variables, such as:   tabBeforePasting - to add a tab before the pasted css text to indent it into the CSS sheet; newLineAfterPasting -  to add a new line after pasting the css: startAgain - to start again the workflow after pasting the CSS, ready for another one; webkitVendor - add the -webkit- vendor variant when needed (animations, transitions...), there are also the -moz- and -ms- options; addToClipboardHistory - to add the pasted CSS to Alfred's clipboard history or not;   you can download it from packal:   http://www.packal.org/workflow/little-css-cookbook   When installed, type littlecsshelp in Alfred to open an html help page, where you'll find more detailed instructions and an explanation of the environment variables.   Giulio

Note: This post is out of date as of Alfred 3.6 (which introduced AppleScript functions to set and remove variables).

There is an updated version on my own site: Workflow/environment variables in Alfred.

This post will not be updated due to the difficulty of editing complex posts using the forum software. Sorry.
 
 
This is a brief look at how to get, set and save variables in code (i.e. in Script Filters, Run Script Actions, etc.).

In Alfred 2, you had one single variable to work with: the {query} macro. Alfred 3 adds the ability to specify as many variables as you want. Alfred's own help provides a great description of working with variables in Alfred's own UI. I'm going to look more closely about getting and setting workflow/environment variables in your own code within a workflow.

First of all, it bears mentioning that all variables are strings. Sure, you can set a variable to a number in JSON, but when it reaches your next script or one of Alfred's Filter Utilities, it will be a string. If you set a variable to an array (e.g. [1, 2, 3, "mach dat Mäh mal ei"]), Alfred will turn it into a single, tab-delimited string ("1\t2\t3\tmach dat Mäh mal ei").

Setting variables

There are several ways to set variables. The most obvious ones are in the Workflow Environment Variables table in the workflow configuration sheet and using the Arg and Vars Utility. The configuration sheet is largely without magic, but in an Args and Vars Utility, you can use variable expansion macros: {query} expands (as always) to the input (which may be a user-entered query or the output from a previous Action), and you can use {var:VARIABLE_NAME} macros for your own custom variables.  This is described in detail in the above-mentioned help pages.

More interestingly, you can also set variables via the output of your scripts (i.e. dynamically) by emitting appropriate JSON. How you set variables depends on whether you are using a Script Filter or a Run Script action.

You must use the appropriate mechanism, or it won't work.

From Run Script actions

Let's say your script outputs a URL, e.g. https://www.google.com. Normally you just do print('https://www.google.com') (or echo or puts) and that gets passed as the input to the next action. To also pass variables, you instead emit JSON in a very specific format:
{"alfredworkflow": {     "arg": "https://www.google.com",     "variables": {"browser": "Google Chrome"}}} The root alfredworkflow object is required. If it's missing, Alfred won't parse the JSON, but will pass it as-is as input to the next action (which can also be very useful). Your output (i.e. the next Action's input/{query}) goes in arg, and any variables you wish to set go in the variables object.

From Script Filters

You can also set workflow variables via Script Filter feedback at three different levels: the root level, the item level and the modifier level. (Note: This only applies to JSON feedback; XML feedback is now deprecated and does not support the features described here.)

In each case, variables are set via a variables object at the appropriate level (feedback root, item or mod).

Root-level variables

Root-level variables are always passed to downstream elements regardless of which item is actioned. They are also passed back to the same Script Filter if you've set rerun, so you can use root-level variables to implement a progress bar.

browser is set to Safari for all items:
{"variables": {"browser": "Safari"},  "items": [{"title": "Google",    "arg": "https://www.google.com"}]}
Item-level variables

Item-level variables are only passed downstream when the item they're set on is actioned, and they override root-level variables. Root-level variables are also passed downstream when you action an item.

browser is set to Safari by default, but Google Chrome for Reddit:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com"},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Modifier-level variables

Modifier-level variables are only passed downstream when the corresponding item is actioned with the appropriate modifier key pressed. They replace item- and root-level variables (i.e. if a modifier sets any variables, Alfred ignores any root- and item-level variables).

As above, browser is set to Safari by default and Google Chrome for Reddit. But you can also pass browser=Google Chrome for Google by holding ⌘ when actioning it:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com",      "mods" {"cmd": {"variables": {"browser": "Google Chrome"}}}},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Using variables

So you've set a few variables, and now you want to use them. Within Alfred elements like Arg and Vars or Filter Utilities, you use the above-mentioned {var:VARIABLE_NAME} macros. Very simple.

Where it gets a little more complicated is in your own code. First and foremost, {var:VARIABLE_NAME} macro expansion does not work in Run Script Actions (or Run NSAppleScript).

When Alfred runs your code, it does not use {var:...} macros, but rather takes any workflow variables and sets them as environment variables for your script. Using the above example again, Alfred would pass "https://www.google.com" to my script as input (either via ARGV or {query} depending on the settings) and it would set the environment variable browser to Safari or Google Chrome. How you retrieve environment variables depends on the language you're using.

Accessing environment variables in different languages

In bash/zsh, the variables are already in the global namespace. Just use $browser

In Python, use the os.environ dictionary or os.getenv('VARIABLE_NAME'):
import os browser = os.environ['browser'] # Or browser = os.getenv('browser')
In AppleScript, use system attribute:
set theBrowser to (system attribute "browser")
In JavaScript (JXA), use $.getenv():
ObjC.import('stdlib') var browser = $.getenv('browser')
In PHP, use getenv():

(Please see this comment by juliosecco on why you should use getenv() over $_ENV.)
$browser = getenv('browser'); // Or $browser = $_ENV['browser'];
In Ruby, use ENV:
browser = ENV["browser"]
Saving variables
 
NOTE: This section is out of date as of Alfred 3.6. Please see the updated version linked at the top of the post.
 
As amoose136 points out, any variables you set in a running workflow are not saved. They exist as long as the workflow is running and then disappear. Any Workflow Environment Variables will "reset" to their values in the workflow configuration sheet on the next run.

Generally, this is what you want, but sometimes you want to save a variable's value. For example, you might have an API_KEY Workflow Environment Variable in the configuration sheet. The user can enter their API key for the service in the configuration sheet, but you'd also like to add the ability to set it from within your workflow, e.g. with a setapikey Keyword and corresponding Run Script action.

WARNING: As of Alfred 3.4.1, Alfred takes several seconds to notice when info.plist has been updated by something other than itself. As a result, relying on altering info.plist programatically can be problematic, as Alfred won't notice the changes for several seconds (5–10 seconds is typical on my machine). If you update a workflow variable in info.plist and run your workflow again immediately, it is unlikely that Alfred will have picked up the change.

The Workflow Environment Variables are contained in the variables section of info.plist. Consequently, to update them, you need to update info.plist.

Regardless of which language you're using, you can call the PlistBuddy program to alter Workflow Environment Variables:
# Set a variable /usr/libexec/PlistBuddy -c "Set :variables:API_KEY \"ABC-XYZ\"" info.plist # Delete a variable (i.e. remove it entirely from Workflow Environment Variables) /usr/libexec/PlistBuddy -c "Delete :variables:API_KEY" info.plist
In Python, there's no need to use an external program, as it has the built-in plistlib library:
from plistlib import readPlist, writePlist # Read info.plist into a standard Python dictionary info = readPlist('info.plist') # Set a variable info['variables']['API_KEY'] = 'ABC-XYZ' # Delete a variable del info['variables']['API_KEY'] # Save changes writePlist(info, 'info.plist')
(Note: plistlib only works with XML property lists, which is fine for info.plist, but using PlistBuddy is generally more robust.)

Don't forget: any changes you make to info.plist only take effect the next time the workflow is run. This likely doesn't matter in most cases, but if you need a variable to be updated immediately (i.e. also for the current workflow run), you must also set it "live" using one of the methods described in the Setting variables section above.

 

Solved    (well, it seems to...)
 
here you have the workflow:
 

 
since a way to set multiple variables seems to be the 'JSON Config' object, I have simply setup a script that outputs a 'JSON config' object, after handling the input and splitting the query as desired...
 
so my working workflow now has;
 
1) a keyword object for the input, so you launch it calling on alfred something like prova2 idproj^^projectName;
2) a script tha handles {query}, splits it with ^^ delimiter and then outputs the JSON to set the variables:
 
sorry, it is php at the moment, it is the language I find more quick along with javascript, here the code:
 
<?php $query = $argv[1]; $vars=explode('^^',$query); echo '{   "alfredworkflow" : {     "arg" : "{query}",     "config" : {     },     "variables" : {       "idp": "'.$vars[0].'",       "name": "'.$vars[1].'"     }   } }' ?>   the code simply sets $query to the input, then puts the splitted values on an array $vars then echo ( outputs ) the JSON setting the variables   3) the large type shows the variables, outputting {var:idp}-{var:name}   I'm sure it can be easily rearranged in phyton       obviously it should be refined, for example to correctly escape single quotes on project name, or other things that doesn't come in mind at this hour, but it works...   now the question is: am I doing something that works for casuality, or is it a good and stable approach?   regards,        Giulio

OK,
please forgive me,
but you know, I'm italian,
and some kind of a respectful chatting is in my DNA,
 
I'll shut up now  

well, at least a little sign of  appreciation...
 
In have seen Vero and Andrew answering you like two little Gandhi...
 
please, try to be 'amazing' a little you too, just some little 'thanks' or 'regards' or 'cheers' or 'hi' or 'thanks' while you are posting your questions would be appreciated ( from me at least, but maybe I'm  too much sentimental )
 
    Giulio

Just guessing,
but CMD space is the default combo for spotlight,
did you try to  uncheck or change it on Mac OS X preferences?