Steps

1. Install growlnotify, which comes bundled with Growl. You can find an easily installable package under the Extras folder, after downloading and mounting Growl’s *.dmg file.
2. Get IP Growl, an Automator service. Download, extract and put it under ~/Library/Services (open your Home folder and navigate through Library, into Services). For the curious, this service contains nothing more than a shell script:

   /sbin/ifconfig \
   | /usr/bin/grep 'inet ' \
   | /usr/bin/grep -v '127.0.0.1' \
   | /usr/bin/grep -v '169.254' \
   | /usr/bin/awk '{ print $2 }' \
   | /usr/local/bin/growlnotify -t IP Addresses

3. Open the Keyboard System Preferences, navigate to Keyboard Shortcuts, Services and scroll down until you find IP Growl. Setup a keyboard shortcut for the IP Growl service, by clicking on the right side of the table row. Check this out, for guidelines:

   

Note: I chose something simple like Control-Command-I. You can choose your own shortcut. Note that the shortcut will not always work, because the foreground application might catch it first. For example, my shortcut will not work under Finder.

Actually, the old version of Reverb will break the latest Skype version, preventing it from opening. To fix this, just install Skype again and download the new Reverb version, included in this post.

It certainly does not favor those who use Skype every day. In this new version, desktop real estate space seems to considered free. Every table cell item is exaggerated in height and the chat dialog can’t even fit more than 10 messages at a time, for a decently sized window. Example:

As a developer, I understand the usefulness of short feedback cycles between developers and users; and trying out Beta versions while expressing concerns, frustrations and enhancement ideas is an excellent way to apply that. What I mean by this is that I like to use Beta versions to provide feedback to developers; unless the application itself becomes impractical. As an extensive Skype user, I just couldn’t bare with so little information of my screen at the same time.

While there are interface features that one can hardly mess with, this is no longer true for the chat messages view. Skype implements this using HTML, CSS and Javascript, and even offers the option to change the Messaging style, in the application’s preferences.

I took a look at the Beta’s application package and found that, along with the default one, two styles are bundled inside, although disabled. I fiddled with both and eventually picked up on the one, the lowest hanging fruit, that allowed me to come up with a more usable interface. I call it Reverb:

There’s just a tiny thing: I’m not maintaining this theme for purposes other than personal motivation. I’m sure the guys at Skype will hear all sorts of hell concerning their new messaging styles, which will result in an overall improvement, in the long run. Constantly updating this package will then make little or no sense. Besides, I don’t even own any piece of code on this. My intent in creating it was to make the Beta experience more enjoyable – and share it, in the process.

Let’s cut the crap. Here’s an installer package and a zip file (for those who have Skype installed outside /Applications, or just want to take a peek at the thing). If you don’t know which to choose, just go for the package. I hope you enjoy it:

Again, none of this code is actually mine. I provide this package in hope that it will allow more users to stick to the Beta and provide useful feedback to Skype’s developers. Don’t set your mighty lawyers after me. You know I can’t run as fast as they can.

Dubrovnik.

Standard: 2048×1536 – 1280×960 – 1024×768
Wide: 1920×1200 – 1440×900 – 1280×800

It’s a pretty simple project and I did it to fulfill the need I had for such an application. I hope more people find it as useful as I do.

It’s released under the GPLv3 and you can access its source code at its github project page.

Half of us was in New York City, and it wasn’t me!

Standard: 2048×1536 – 1280×960 – 1024×768
Wide: 1920×1200 – 1440×900 – 1280×800

Wow. It’s been a long time. Sorry!

Duarte visited me in Zürich last week and it was awesome. Needless to say, we’re packed full of new photos for more wallpaper deliciousness. Hope you like it.

Standard: 2048×1536 – 1280×960 – 1024×768
Wide: 1920×1200 – 1440×900 – 1280×800

Merry Christmas and a Happy New Year everyone!

Standard: 2048×1536 – 1280×960 – 1024×768
Wide: 1920×1200 – 1440×900 – 1280×800

When I first started out localizing my first iPhone application, I went bananas. Unlike most of the developer resources available for programming on an Apple infrastructure, this feature seemed so confused in documentation and poorly understood by the community. All I wanted was to have multiple languages on my application, relative to the user’s preferences, just by using NSLocalizedString, and editing the translation files.

Please note that there is a whole lot more to localization beyond having different languages on your application. I’m not going to cover that on this post. I’m also not going to talk about localizing XIB files.

Goal

This guide will help you localize strings included in your code (using NSLocalizedString) as well as making the translation process incremental (without ever losing the previous translations made).

Problem

I’m going to talk about the surprise I had when I started localizing my application: the Localizable.strings files that gets generated using Apple’s tool – genstrings – overwrites the previous translations, instead of properly merging them with the new changes. Since I needed to translate as I was developing the application, this meant that I had to merge the files by hand at every step of the translation process (always being careful not to lose the previous translations). This just wouldn’t work.

Solution

And so, I’ve made a Python script that does just what we need: it generates new translation files, merges them with the previous translations and keeps copies of all those steps, just in case anything goes wrong.

Step by Step

Here’s how it works:

1. go into your XCode project folder and create xx.lproj folders inside, one for each language you would like (using ISO 639-1 and ISO 639-2 codes). For example, to have your application in English, French and German, you would create three folders: en.lproj, fr.lproj and de.lproj;
2. put my script localize.py inside the XCode project folder (it is being hosted on my github repository);
3. simply run ./localize.py on the Terminal, from the XCode project folder and your files will be created on the first run, and merged on subsequent runs.
4. after running the script for the first time you should have your Localizable.strings files inside each language folder. To make them work with your application, just add them to your XCode project.

Notes

The script always leaves two files behind, per language: Localizable.strings.old and Localizable.strings.new. These are the two files that got merged to create the brand new Localizable.strings file. They might come in handy for some troubleshooting. By not adding them into the XCode project and (if applicable) by adding them onto your favourite revision control program’s ignore list, they cause no trouble at all.

I hope this helps someone, just like it has been helping me ever since I created it.

If you have any comments, questions, bug reports, please let me know in the comments section.