10 Practical Tips For Social Media Engagement

Crowdsourcing is a community effort. It should be a win-win process that leaves everybody satisfied: you with the results and the other participants with the experience they’ve had. Here are a few tips on what you can do to make your crowdsourced project a success with the help of social media.

1. Define your crowd, know who and what you are looking for. If you are looking for people in some specific geographic or language area, or demographic, make sure those people notice you.
2. Get publicity! Share information about the project on your Facebook page, in your user forum and tweet about it. Tell about it to your friends and colleagues, anybody who is affiliated with you or your software. And also do encourage your users and translators to do the same. Have them share their translation progress and invite their friends to work with them.
3. But: don’t push too much promotion into the same channels. If you flood everybody’s Twitter timeline by looking for translators 40 times a day, you’ll probably just end up unfollowed or blocked – or both. Do remember common social media courtesy!
4. Give your project an appealing flair in the working environment of the contributors. Make sure it has nice descriptions and graphics. That will make it even nicer to start working on it, and will be an advertisement for your project.
5. Could you reward your translators in some way? That is not something you must do, but will be a nice bonus for the people. (And you have to motivate them somehow.) It can be a free license, maybe a giveaway of some sort or a mention in the credits or promotion in your community. Only your imagination is the limit. Think about what you would think as rewarding for participation, and you have a good indicator of what might do the trick for others too. Of course, already sheer participation might be rewarding.
6. Check-up on your project regularly so that you can reply to any questions from the crowd. Don’t let the work of your community be stuck anywhere.
7. Respond to feedback. Remember not only to be there when someone loves your project, but also when someone is critical. If you handle the situation well, you might even turn critics into promoters.
8. Remember communication at all times! Tell the community how the work is progressing, thank them for their efforts, do pep talks, whatever feels natural for you. Through your own engagement you show that your project is important!
9. Allow enough time when working with a bit more unusual languages or other groups.  For example, it might not be a wise bet to expect that you gather a crowd for Hausa translations over night and have your task ready instantly, unless you know your crowd very well and have engaged them already before the start of project.
10. Add descriptions to your translatable texts, or at least to the difficult ones. Some texts are self-evident, for example ‘Save’ mostly doesn’t need much explanation to it. But then again there are a lot of strings that might not open up to translators that easily, even if it’s the clearest thing in the world to yourself. (Ok, the last tip doesn’t have anything to do with social media, but it’s a useful point to remember when crowdsourcing localization.)

What We Can Learn from Cloudpocalypse?

As most of you already know, Amazon EC2 had some serious issues last and this week that took down several big web 2.0 services. Unfortunately Get Localization was also affected. Problems started on Thursday afternoon (UTC) when AWS was just about recovering from the first outage. We had survived from the first wave of crashes but the second one took us down.

This was unfortunate incident and the easiest solution would be to blame Amazon for this. However it would be wrong. And here’s why:

Our company has been using AWS now almost three years and this was the first time something like this happened to us. It must have been a really stressful and difficult situation to all AWS engineers and despite that, they were able to recover their systems for most of the customers relatively quickly when considering the complexity and how many were affected (the whole data center).

But the main thing here is that we could have done things better. The point is that we can’t blame others when something like this happens, especially when we are in cloud.

There’s no server or infrastructure that never crashes. Cloud is not different in that sense. But what cloud can offer is an easier and better infrastructure to manage these issues — only when used correctly. The biggest problem for us was that our volumes were lost, the data was not lost but the connection between our server and volumes was not working. We could’ve restored the servers and launched new volumes to non-affected zone but our database servers were down so we were not able to mirror the most current data to new volumes.

We have secondary backups as well but they are not real-time. We could’ve gone back and lost couple of hours of work but instead we decided to wait until AWS fixes this problem. That unfortunately took 20 long hours.

Happily we didn’t lose any data and systems have been up and running since last Friday but this is not something we take lightly.

So what we learned from this?

– Elastic Block Storage (EBS) is clearly a weak point. It’s a persistent storage but the connection between instance and volume is not reliable. It can disconnect and bring the whole database server down. We are figuring a way to replace EBS with some more reliable solution so this cannot happen anymore.

– We cannot trust that availability zones within one region are safe from each other. The problem was occurring now in all availability zones in N. Virginia data center. This was not expected to happen.

– The most critical is the API that should not go down. It’s something that can be seen by our customers customers and we cannot accept that. Getting rid of EBS and locating to different regions should bring the stability and reliability we need.

In retrospect, we could’ve done better but on the bright side we learned a lot how to make our service more reliable. Amazon EC2 is a remarkable platform that gives you the power to distribute your applications to all over the world but we just need to keep in mind what Stan Lee once said:  “With great power there must also come great responsibility”. It’s our responsibility to make the system reliable.

See also: Amazon explains what went wrong

MIX 2011: My thoughts on Windows Phone 7.5

Greetings from Las Vegas! Microsoft’s annual developer conference MIX 2011 is currently on-going. We’ve also attended to this event to gather some information about recent developments on the planet Microsoft.

One of the hottest topic here is clearly Windows Phone. There’s new version coming up, code name “Mango” a.k.a Windows Phone 7.5. They claim it will introduce around 1500 new API’s, 16 languages and the marketplace will be available to 35 countries. We can confirm these when SDK will be available next month.

What this means for developers? Microsoft is hugely investing in creating the best possible development platform and from our point of view, it really looks like they’re in the right path with it. Developer tools that are now provided for free corporate features that were previously only available in the most expensive tools. I’ve personally worked with quite many development environments from different manufacturers so I’m not easily impressed but what I’ve seen here really look cool. Of course, we have to see how they work in practice.

New API’s bring WP up to the level where it can really compete with others as well. I wasn’t impressed by the first version as it was lacking a lot of important API’s but as they are now introduced in 7.5, I’m actually looking forward to developing for it. On the negative side, lack of native SDK is a disappointment. I’ve discussed with Microsoft guys, and signals I got was that we should not even expect to see it.  This means that bigger open source projects like Firefox can’t really make appear on Windows Phone.

However, in the end I can see rise of Windows Phone good thing for developers. It will take some time to get up to the level of Symbian or Android in terms of features or API’s but eventually I can see this platform as a winner.

Software Internationalization for Dummies

I had discussion today in Twitter regarding software i18n (i18n is a short for internationalization, and it means there’s 18 characters between letter ‘i’ and letter ‘n’). I was trying to find some simple, straightforward link that explains what this word monster actually means but I wasn’t able to find it. So here it goes:

Software Internationalization is a process to separate content from code so that it can be localized. Almost all programming languages and environments provide some kind of framework to do this. There is some popular examples like JavaScript that doesn’t provide i18n support out of the box. However, most well known JavaScript libraries such as jQuery do have plugins that provide the support.

As an example, the iPhone i18n framework provide a way to use following “strings” files that are then accessed from the code:

"Hello World" = "Hello World";


When this is translated, file is copied and typically saved under the corresponding language folder, in this example it would be Finnish strings file:

"Hello World" = "Heippa maailma";

Here we can see that “Hello World” is now translated to Finnish. Based on the language you’re using in your iPhone, the correct file is automatically loaded. It means that when in actual application code we use string “Hello World”, it will get automatically replaced with Finnish translation from the Finnish strings file (if your iPhone is in Finnish, of course).

The benefit of this whole process is that we don’t have to change the code when application goes to localization phase. Also in some cases, e.g. in HTML or other declarative languages we don’t have to duplicate the design or behavior to each localization variant as the languages reside in different files.

However, managing these i18n files will get tricky as soon as you have to deal with multiple languages, hundreds of strings and different character sets, file formats and versions. That’s why there’s new breed of software localization platforms that provide version management, editor, collaborative tools and API’s to manage these files more easily. You can learn more from Get Localization and this blog how to simplify the localization process as well.

If you wan’t to learn more? Please read the following blog post, it will give you more insights about the topic: 10 Internationalization tips for developers – I18N checklist

Agile/Lean Localization: Tell us what it means?

We are defining what Agile/Lean Localization actually means to digital product companies, please let us know what it means to you? Do you think it works or maybe that it really cannot work at all? Do you even understand what it means? Please share your experiences, feelings and ideas. Challenge or praise it. Especially if you are seeing red and your head bursts, share your feelings with us. It doesn’t matter who you are, e-mail them to petteri@synble.com or just drop a comment here. We will discuss about these topics and publish best of them here and in our upcoming e-book about Lean Localization!

Thanks in advance!

(What is Lean? See here: http://en.wikipedia.org/wiki/Lean_manufacturing)