kopischke

Hello,

 

hm, can´t find it „No translation found!“ it says …

What´s wrong?? Or isn´t it german - english?

 

thx for reply

Nope, Google changed their API, the current workflow will not work anymore. The good news is: I’ve patched my workflow to use the new Google Translate URL syntax; the basic functionality, i.e. single term translations, is thus functional again. Being rather constrained for time, I will leave implementing a multi-sentence patch to the reader (PRs welcome, external interpreters need not apply). Grab the revised workflow at the repo.

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....

Thanks to Shawn Rice for the above link, and to GitHub user @g0to for bringing this to my attention. 

In the future, please follow their example and open an issue on the repo for problems to ensure I can react swiftly – I barely ever visit the Alfred forums, but I keep close tabs on my repositories and their issue trackers.

EDIT: just pushed a quick update that fixes handling of multi-word (not multi-sentence) translation queries, which I broke when refactoring for the new API. Apologies to everybody who suffered from that – please download the updated version.

Would be interested in hearing about this too. I’m using Jens Kutilek’s system font version of Fira Sans as my system font, and Alfred now sticks out like a sore thumb… I understand portability is an issue for arbitrary fonts in themes, but could we get an option to use the system font no matter what, maybe?

It only works with Mavericks, or more precisely Ruby v2 that ships with Mavericks (ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]). This is because it uses the SQLite3 Gem, which has to be built with native extensions, and thus it's build for this precise version. I'm not very keen on Ruby, specially this kind of environment issues, so any help on this limitation is appreciated.

You can safely shorten that to “It only works on Mavericks” and stop worrying about the SQLite3 gem dependency, as Apple is taking care of the issue for you: SQLite3 it’s part of the gems included in Mavericks’ system Ruby install, along CFPropertyList and Nokogiri: do gem list on a pristine Mavericks install, or gem which --all sqlite3 if you already installed gems of your own .

Just for the record, Paul Kim, the developer of Hazel, struggled with the exact same issue when updating Hazel to manage Mavericks tags (I should know – I was the one reporting the issue to him ). AFAIK, he ended implementing the exact same solution…

Sorry for not answering earlier, I haven’t been around the forums for a while… Short answer, I’m afraid, is no, not with this workflow, as the underlying utility does not support per monitor sleep. 

Just a hint: if any of the posters with problems happen to be running OS X in another language than English, the AppleScript will not work, as it searches for the relevant menu item by name, which, of course, is localized.

If that is the case, the fix is easy: check your Finder and see what your window menu is called, and what the menu item to merge windows is called, then replace the second and third argument of the click_menu call on line 2 of the AppleScript action of the workflow by the localized versions.

For instance, for German, replace

click_menu("Finder", "Window", "Merge All Windows")

by 

click_menu("Finder", "Fenster", "Alle Fenster zusammenführen")

Great workflow, thanks!

 

One side note, I think the box for the hotkey should be positioned as in the image below.

The way it is now it still brings up alfred and you have to hit return after pressing the hotkey.

 Absolutely. Brainfart of mine, corrected. Re-download or update via Alleyoop.

Great.. Thx a lot.

But what's the difference to  ./sleepDisplays 

Um, I’m not quite sure where you got the sleepDisplays command from? It’s not part of the default OS X set of CLI commands…

 "keywordz". I like that. It's definitely better than mine.

 

BTW: Should I also file my bug report on openradar, then?

Duplicating a bug report on Open radar is always good.

Sleeping the Mac display is the fastest way to lock a machine if a password is set. Unlike switching to the login window (Alfred’s default strategy when using the lock command), all your apps keep running, enabling continuous operation of tools like Dropbox, Hazel or EventScripts, and even quasi-magical unlocking with Knock (if that’s your thing). On a machine whose keyboard has an Eject key, Ctrl+Shift+Eject will do the trick, but on those without, only hot corners are available.

Sleep Display complements the inbuilt options by adding an Alfred keyword (sleepdisplay by default, though I prefer to disable standard locking and use lock) and an optional keyboard shortcut (unset by default). No more, no less.

Grab it here, or go to the repo here.

Changelog:

• version 1.0.1 – fixed hotkey bringing up Alfred

NB: Mavericks only, as it uses a tool compiled with the 10.9 SDK.

Those are truly insane translations.

 

 

I'm not surprised. "Worte" and "Wörter" have clearly distinct meanings that have nothing to do with tags or keywords.

 

It should confuse the hell out of anyone that understands the difference. "Key words" vs "keywords" doesn't really capture the total dumbness of the mistake. I'm not sure you can in English. Tags are Tags.

 

Why does Apple always have to come up with a different, wrong translation for everything?

Well, actually, “Schlagworte” has a tradition in indexing contexts (albeit not computer based ones), so that wouldn’t have been too bad a a choice for either term, but not for both (and differentiating by subverting German grammar is … umh [to English speakers: it’s a bit as if keywords and tags were called, respectively, “keywords” and “keywordz”]).

I didn't know about bugreport.apple.com. I just filed a bug re Apple Maps and the city where I live, Essen.

Yeah, it’s meant to be a dev tool, but it’s accessible to anybody with a free developer account, not just paid members of the iOS and OS X programs. The openradar mirror exists because the bug reports are only visible to the submitter, which makes it rather difficult to assess if the issue has already been noticed by others, and what patterns they have noticed…

Every single business [in Essen] gets a restaurant icon, even the local prison  

 *mind blown

German translations are almost always dubious if not misleading. I therefore switched my Mac's GUI language to English long time ago.

 Apple's German translations are horrific. Windows in German is just fine (other than being Windows), but OS X in German is demented.

 

Ablage vs Datei or Sichern vs Speichern are kinda okay, but they've done some really insane things. On the iPhone, "Aktualisierungen" spread across, like, three buttons in the App Store app, and the "kostenlos" button in the iTunes app made it impossible to see the title of the podcast/track you were looking at. I'm sure there are much better (worse?) examples.

 

My favourite was Flash's translations of "level" and "layer" (very different things in Flash). Both "Ebene" in German. Bravo!

 

My favourite non-IT translation that I've come across was for the "hydraulic ram" on a large machine tool. Hydraulischer Widder. Epic! (For non German-speakers, "hydraulischer Widder" means "hydraulic male goat".)

Well, I keep hoping … and, in the meantime, filing localization related radars  .

I also use a File Filter to display tagged files instead of the cli utility. I just omitted OpenMeta tags, as they are already very well covered by your workflow. I usually do not like to reinvent the wheel...

Hah, looks like I jumped to conclusions when checking out your workflow, I assumed you were using the cli’s search functionality for the filter. With a file filter, adding application tags would just involve adding kMDItemKeywords to the queried fields, of course. Well done   . Also, only ever so slightly OT: noticed this already?

That solves it: we have run into an internationalization issue  . Your syntax only works on systems configured to use English as their language, and mine is German (the correct version here would be mdfind 'Art:Gesicherte Suchabfrage'). Luckily, there is an easy way to work around this and make the workflow work no matter what the language settings: use mdfind "kMDItemContentType == 'com.apple.finder.smart-folder'".

Gah, no, that was me being stupid – I forgot to cd to the workflow dir before testing in in Terminal *facepalm. That being said, I still do not get any results, and when testing in Terminal (with a prealable cd   ) the output of python smartfolders.py <fragment of existing smart folder name> is </ items>.

Smart Folder search fails for me on Mavericks (using system Python 2.7.5):

This is a nifty workflow – I noticed the utility a few days ago and have wondered if implementing a workflow based on it would make sense. This one is feature complete and well done, kudos: if you want tag management from the Alfred file browser, go for it, by all means.

However, and without wanting to denigrate the workflow, if all you need is a keyboard interface to tag management, I would suggest simply defining a hotkey for the Tags … command in System Preferences (hat tip to Brett Terpstra for the idea). It’s lightweight and integrated, and will offer autocomplete suggestions among other things.

Also, the workflow search is for user tags only – if you want and / or need to also search application specific tags like those set by Delicious Library, Evernote and others (aka Spotlight keywords – when Apple fixes CoreData Spotlight importing on Mavericks, that is), you might want to use a workflow based on an Alfred file filter (like my Tagg’d – sorry for the plug, really). The speed advantage James Berry’s utility claims over mdfind is entirely lost when using a workflow [EDIT: I didn’t pay attention: the workflow already uses a file filter] you will have to add kMDItemKeywords to the scope of its .tagged file filter, optionally also kMDItemOMUserTags for OpenMeta tags (essentially recreating my Tagg’d workflow).

Again, kudos for the workflow. Please consider the above a set of differentiating footnotes, not a fundamental critique. 

Very cool! I don't suppose there's a way to have it auto-suggest tags as I type?

I’d love that, but there is no way to achieve that with OpenMeta tags I am aware of, as there is no central database of the tags [Leap, a tag centric file browser which offers an “all tags” view collects these by actually scanning the whole file system hierarchy, which is far too slow to be useful in a filter, and all tagging apps with autosuggest I am aware of (Tagger and DefaultFolderX) simply cache the tags used in their own apps to suggest new ones]. The same is true of Spotlight keywords, with the added complication that these are set by apps privately and their only interface is … Spotlight. If Mavericks tags end up superseding OM tags and app specific Spotlight keywords, the whole issue will be worth revisiting, but until then, I am afraid the answer is no.

If you need a companion workflow to retrieve these tagged files afterwards, I shamelessly recommend my Tagg’d workflow.

A simple file filter to search all bookmark (keyword web) and web browsing history (keyword hist) files accessible to Spotlight. 

Why use this instead of the default Alfred functionality? Well:

• More targeted search, less clutter in default results.
• Smarter search: History search searches the URL, bookmark search ignores it; JavaScript bookmarklets are excluded from bookmarks searches.
• Searches bookmarks in Pinboard.in / Delicious accounts registered with Delish and Webbla, including tag search (Webbla, needs OpenMeta enabled, Delish works out of the box).

If you’d like the workflow to support more browsers and bookmark / history formats, please attach an example of a pertinent bookmark and / or history file to this issue.

As usual, repo is here, direct download there.

Updates:

• Version 1.0.0 hotfix 2013-10-23 – fixes Alleyoop updating (you need to redownload), workflow file renamed
• Version 1.0.1 2013-10-25 – update for final Mavericks tagging scheme

A simple file filter companion to my tagging workflow. Will search OpenMeta tags, application specific tags (as long as they are stored as Spotlight keywords – kmdItemKeywords to the savvy) and Mavericks native tags.

As usual, repo is here, direct download there.

Updates:

• Version 1.0.1 2013-10-25 – Update for final Mavericks tagging scheme

not sure how to fix this.

 

Maybe you can make a dumb workflow to output the feedback items directly and see how alfred responds. Then you may remove the items to the minimum and check where the problem is. 

I don't really have the time or ruby knowledge to do much testing. I'll just use the old one that was working until you're able to upgrade and take a look.

Hmm, I had a quick look thinking you might have hit a snag with escape characters in XML content, but TextMate parses the XML fine. Considering the issue is then very likely in Alfred’s parsing, just a few thoughts on the posted feedback output: 

1. unless I missed something in the docs, shouldn’t args be an attribute of item, instead of an XML node?
2. by the same token, shouldn’t the XML output also lead in with <?xml version="1.0"?> (@Jb_Bryant: or did you omit that from the copied output)?
3. least likely, but ya’ll never know: the uid item attribute is only optional since Alfred version 2.0.3 – which version of Alfred are you running, @Jb_Bryant?

(just throwing random suggestions at the wall to see if anything sticks – feel free to ignore me  ).

That‘s odd – the very same command runs fine on my system, and I have had no other reports of it being otherwise, Lion or Mountain Lion. As there is no documented incompatibility of contacts with 10.7 (which it predates, BTW) I can only surmise there is an issue specific to your system. Are there any logs in Console.app that say more than “illegal instruction”?

Great, thank you!

I added German and it works.

But every space is replaced by two backslashes:

Screenshot

 

Do you have any idea how to change this?

Make sure Alfred is not set to escape spaces in the script filter settings. The only checked escapes should be backquotes, backslashes and Dollar signs (as these are shell metacharacters that will be interpreted inside double quotes) as well as double quotes (as they end the quoting, obviously).