Search the Community

I try to create a workflow, that lists search_results and opens the relevant gitlab-markdown script on select. Therefore I want to use link-anchors to jump to the correct section in the markdown file. Therefore I used something like: wf.add_item(title=src['content'], icon=u'imgs/{}.png'.format(src['file'].split(".",1)[0]), subtitle=subtitle, arg='aws.md#s3', valid=True) However my link aws.md#s3 gets replaced with the ASCI-Encoding (https://www.w3schools.com/tags/ref_urlencode.asp) when used by the "open url"-step, so in this case: aws.md%23s3. This format does not work on gitlab. How can I prevent the replacement of # with %23?

I have a weird problem with my workflow. It does not show any results in Alfred but works when run from Terminal. But let me explain more on that topic. My workflow's job is to list Polish cities from webpage (get the list from JSON results from page) and download detailed weather forecast as png file. The main script is written in Python. The thing is, Polish cites also uses diacritical letters (ą, ć, ę, ł, ń, ó, ś, ź, ż). And when I want to use my workflow with city that contain one or more of mentioned letters – say <code>Gdańsk</code> the workflow itself won't work – just shows the result prepared for situation when no results find. However, when I debug the script from Terminal: python script.py "Gdańsk" I got all of the XML code for results: <?xml version="1.0"?><items> <item> <arg>http://m.meteo.pl/warszawa/weather;Warszawa</arg> <title>Ostatni → Warszawa</title> <subtitle>Prognoza 60h. Wciśnij Cmd dla prognozy 84h.</subtitle> <subtitle mod="cmd">Prognoza 84h.</subtitle> </item> <item autocomplete="Gdańsk"> <arg>http://m.meteo.pl/gdansk/weather;Gdańsk</arg> <title>Gdańsk</title> <subtitle>Prognoza 60h. Wciśnij Cmd dla prognozy 84h.</subtitle> <subtitle mod="cmd">Prognoza 84h.</subtitle> </item> <item autocomplete="Nowy Dwór Gdański"> <arg>http://m.meteo.pl/nowy-dwor-gdanski/weather;Nowy Dwór Gdański</arg> <title>Nowy Dwór Gdański</title> <subtitle>Prognoza 60h. Wciśnij Cmd dla prognozy 84h.</subtitle> <subtitle mod="cmd">Prognoza 84h.</subtitle> </item> <item autocomplete="Pruszcz Gdański"> <arg>http://m.meteo.pl/pruszcz-gdanski/weather;Pruszcz Gdański</arg> <title>Pruszcz Gdański</title> <subtitle>Prognoza 60h. Wciśnij Cmd dla prognozy 84h.</subtitle> <subtitle mod="cmd">Prognoza 84h.</subtitle> </item> <item autocomplete="Starogard Gdański"> <arg>http://m.meteo.pl/starogard-gdanski/weather;Starogard Gdański</arg> <title>Starogard Gdański</title> <subtitle>Prognoza 60h. Wciśnij Cmd dla prognozy 84h.</subtitle> <subtitle mod="cmd">Prognoza 84h.</subtitle> </item> </items> Notice that first item group is previously used city. But all the other show results with name "Gdańsk". And that is behavior, when the option in Script Filter – Alfred filters results is unchecked. When I check that, all seems to work fine. So why am I bothering you at all? Because I rather want to uncheck that option – it affects situations when I want to not display any results (in some cases). So I want to ask you for help with that problem. Maybe there is some encoding problem in Alfred 3 itself? The workflow can be downloaded here. Just copy and paste "Gdańsk" to debug it.

I hit backspace after I wrote this post the last time and I lost all i wrote... Test #1 (From Term​inal) osascript -l JavaScript -e "console.log(escape('ä'))" Notice that the ä is encoded as %E4. Test #2 Create a keyword trigger with a parameter. Let's call this atest. Create an action with osascript (JS) with the following code console.log(escape("{query}")); Connect the trigger and action. Watch the debug console for output. Notice that the ä is encoded as a%u0308. Problem scenario I'm using this NodeJS workflow as a base https://github.com/giangvo/alfred-workflow-nodejs/ I've created an issue about this over there too https://github.com/giangvo/alfred-workflow-nodejs/issues/6 The workflow supports autocomplete with a menusystem. I'm getting external menu entries which contains the letter ä I'm autocompleting a menu entry which places the (%E4 based ä in the search thingy) I'm sending this to an action which contains the code below function getItemData(itemTitle) { var wfData = Storage.get("wfData"); return wfData ? wfData[itemTitle] : undefined; } This tries to access data where the menu entry title is the key. Originally the key is ä / %E4 which it is in wfData but the autocompleted title is ä / a%u0308 which makes the key not match although they at first sight look the same. Any tip on how to go about this? Latest stable update OSX El Captain Latest Alfred v2.8.2 (432)

Hi, guys! I try to write my workflow for working with Lingualeo.com (it's Russian service for learning English ). Translating works well, but when I try to add a word and its translation to Lingualeo the letter "й" replace to the letter "и". I'm sure this problem in one of my python scripts because when I tried to hardcode translation with this "й" letter - it works fine. So it's not Lingualeo's API problem... The weird thing that in notification it works fine. I guess it's sort of automatic normalization or some problem with encoding but I'm just a beginner. I would be very grateful if you can help me solve this problem. Workflow files: https://github.com/PazzaVlad/alfred-lingualeo/tree/master/LinguaLeo%20Translate When I write instead of "words[1]" (this is translation) just string "йога" here https://github.com/PazzaVlad/alfred-lingualeo/blob/master/LinguaLeo%20Translate/addtodictionary.py#L24 - it works fine. Letter "Й" doesn't replace by letter "и".

I'm trying to make my workflow robust against special characters, and I'm having a bit of trouble. When I run my python script from the terminal with an argument containing special characters it works fine. Eg: python alfredwl.py show "a´´´´ÅÅÅ´´ÅÎÎÎÏÍÒˆ„ÏıÔÍÓÔÍÏıÅͯÅÍåå∂ß˚˜≤√åß" However, when I run it through Alfred as "wlshow a´´´´ÅÅÅ´´ÅÎÎÎÏÍÒˆ„ÏıÔÍÓÔÍÏıÅͯÅÍåå∂ß˚˜≤√åß" in a script filter my workflow seems to stumble on the character encoding. In my python script I convert arguments from UTF-8 into Unicode strings--I figured that would've worked for Alfred. What type of encoded string does Alfred's script filter pass onto the Bash script running? Thanks, Nick

Currently, in some circumstances, it's impossible to stop Alfred processing URLs in some fashion in its Open URL Action. This can lead to Alfred "breaking" correct URLs. It's straightforward enough to work around using a Run Script Action instead (open "{query}"), but this is non-obvious. In some cases, like the one linked above, it's essentially impossible for Alfred to know whether it should or shouldn't percent-encode certain characters. As a result, it'd be preferable, in my opinion, if the Open URL Action also had a "Use URL as-is" option for situations where Alfred doesn't (and realistically can't) do the right thing.

Hi Alfred users. I'm not completely sure this is a bug so I'm posting it here first. I have written a script that outputs xml which some times contains special characters. It seems that the xml interpreter in Alfred does not know what to do with those and aborts the whole script filter without any error in the debug log. A simple example would be: <?xml version="1.0" encoding="UTF-8"?><items><item arg="http://www.glossed.it/highlights" valid="YES" type="file"><title>title Ð</title><subtitle>test</subtitle><icon type="fileicon"></icon></item></items> I've coloured the offending character red. Without it the script filter works fine. Am I correct in thinking this is a bug in Alfred? Best regards, Teo

It seems I originally posted this in the Workflow Help forum by mistake. I'd appreciate it if a mod could delete the corresponding thread in there. Alfred build: 227 OS X version: 10.9.1 When using the Open URL action with the URL set only to {query}, Alfred fails silently if the passed arg contains non-ASCII characters. The following XML, which Alfred accepts and correctly displays in its results list, does nothing when the arg is sent to the Open URL action. The first item is as returned by Python's xml.etree.ElementTree library, the second I edited back to pure text form to see if that worked (it didn't). In both cases, Open URL performs perfectly provided {query} is only part of the URL, but fails if {query} is the entire URL. <?xml version="1.0" encoding="utf-8"?> <items> <item valid="yes"> <title>Göbekli Tepe - Wikipedia, the free encyclopedia</title> <subtitle>http://en.wikipedia.org/wiki/Göbekli_Tepe</subtitle> <arg>http://en.wikipedia.org/wiki/Göbekli_Tepe</arg> <icon>/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/BookmarkIcon.icns</icon> </item> <item valid="yes"> <title>Göbekli Tepe - Wikipedia, the free encyclopedia</title> <subtitle>http://en.wikipedia.org/wiki/Göbekli_Tepe</subtitle> <arg>http://en.wikipedia.org/wiki/Göbekli_Tepe</arg> <icon>/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/BookmarkIcon.icns</icon> </item> </items>

Hi, I have problems to get a phrase like "Müller" correctly transfered into a script. The "ü" (LATIN SMALL LETTER U WITH DIAERESIS - utf-8 = c3+bc) does not reach my python-script via the imput placeholder "{query}". For testing I tried a mini Script-Action (Bash) with "Müller" as the search word: echo "{query}" | xxd > somefile.txt The "ü" seems to represented as 75+cc+88 (in context: 0000000: 4d75 cc88 6c6c 6572 0a ) echo "Müller" | xxd in the OSX terminal displays: 0000000: 4dc3 bc6c 6c65 720a Any ideas? Thanks Thomas