Simple But Yet So Difficult To Translate: Placeholders In Software

I do some translating myself too. Already quite a long while ago I translated texts for a web application running on a small company’s website and came across a placeholder that didn’t have much information attached to it. I could see the placeholder’s name and the sentence it was embedded in. For that particular application, the placeholder name usually revealed what it was about. What I assumed it to be was the name of the user’s company/product. That made the sentence a bit difficult to translate due to Finnish grammatics, but I managed to build a somewhat natural sentence out of it anyway.

A while after that I browsed to the web site and saw what my translations looked like. Awful. The sentence structure was in some cases clumsy, in some cases the meaning was simply wrong. The placeholder didn’t stand for the user’s company/product, but for the website/service where it was used. And based on earlier translations in the translation memory I wasn’t the only translator who had been mistaken.

After that I sent an email to my contact person at one of the many agencies between me and the end client, and pointed this out. What happened? Nothing. The translations are still there. (But you shouldn’t really blame the project manager, as he was probably constantly swamped with email. Localization project managers usually are.)

What did I learn from this? Well, first of all it is critical to include enough information about placeholders for the translators. Even if they would be experienced users of the application, it might not become clear to them what different placeholders mean. Secondly, it’s important to have a translation process that supports communication and updates even after the initial translation has been finished. Communication has to be so easy that important issues aren’t left lying around even by mistake.

Microsoft Word DOCX Support Available

I’m happy to announce that we’ve added DOCX support to all projects starting from today. DOCX files can be imported under ‘Files’ -tab like any other file. Projects can hold multiple DOCX files and translation sync works between them and other files like before. It’s also possible to upload resource files and e.g. user manual to same project so everything will get translated at once.

Now additionally to websites and applications, we manage documents too. Yay!

Workspace Got Refreshed

We rolled out small but easily noticeable changes to our project workspaces today. Re-designed header, as you can see on the left is not green anymore and it’s smaller. It takes less space from valuable information making the workspaces more user friendly. The icon is a bit smaller but it pops out more clearly against the dark background.

This is a part of our project to create more clearer design to whole service. We’re doing these improvements incrementally in simple batches so your team’s productivity doesn’t suffer due to major updates. Don’t forget to let us know how you feel about this change, we truly love feedback!

Kickstart to Localization – What Developers Need to Know

Why Localize?

No, I’m not going to start by selling the concept of localization to you. I know you’re a smart developer so it’s no news to you that localization benefits your revenue stream. But nevertheless I’ve added a couple of links at the end of this post, there you can find some insightful blog posts about this topic.

Getting Started

First of all, think about which markets you want to target and where you already have some users. Google Analytics or other analytics software can give you a good indication on where your users are coming from. Another option is to run a crowdsourced translation project to get some understanding on how active your users are in specific language areas (but we will discuss that in separate post).

As a developer you need to make sure your app is internationalized. That’s the process of separating your content to resource files so they can be translated more easily. You can learn more from our earlier blog post Software Internationalization for Dummies.

Additionally, internationalization is about making sure that the app can be easily translated. Here are a few hands-on tips:

1. Don’t split sentences into several strings. This makes it really difficult to translate and the quality will be bad. If you have to split texts, make sure you give proper context information.
2. Feel free to use tags e.g. %s, it’s much better than splitting the sentences. A proper translation tool will make sure that translators won’t mess them up.
3. Keep in mind that expressing the same thing in other languages can take up to 30% more space in the user interface compared to English (e.g. German). On the other hand, some languages might be “short”, but demand more height for the characters to look good and be readable (e.g. Chinese).

Get Everybody Together

So how should you actually implement the localization process for your product? It is very important that the translators are a part of your development team. Strings can be translated in many different ways and the translators need context information to produce good and correct translations. Context is almost as important information as the text itself. That’s why the translators need to know your product, inside out like every other team member. Typically you can differentiate good translators from bad ones by the questions they’re asking, the good ones ask questions about the context and the product.

The key question of the localization process: Will you update this app, website, user manual and/or other related documents after the first version? 

If the answer is yes, you need a localization platform where you can work with your translators. A localization platform is like a version control for your localization files. It knows which parts of the app are translated and can give you the exact status of the translation. A good platform also enables just-in-time (JIT) translations, so your app or document can be instantly translated after modification. The localization platform also helps you to communicate with the translator, you can be sure that same translator is always translating the updates and is a part of your development team. Key considerations when planning the long-term localization approach for your app, document or website:

1. You want to avoid feeling the localization pain when you have to make the change, right? Make it easy to do changes from the start.
2. Get to know your translators so that you can trust them. It’s the only way to be sure that you’re getting the right stuff.
3. Enable communication between translators and rest of the team. Kill the silos!
4. Make sure that translators are using your app!  They need to be a part of your team.

Translation – It’s Actually Really Affordable

Thanks to an industry that has been pushing prices down in fierce competition, you can get quality translations for really reasonable prices. You can find several translation sites and companies that offer translation in bulk. However, spend some time to find your own translators. They’re as important as your other team members. There are several sites, where you can find freelancers, for example Freelancer.com and Elance. There’s also ProZ.com that is targeted specifically at translators. We’re also working on our own marketplace that will allow you to find and hire professional translators directly to your Get Localization project.

Remember, localization is not just about translation. Your translators can give valuable feedback on how your app works in their local market. So make sure to collaborate with them!

You can learn more about our localization platform Get Localization at http://www.getlocalization.com.

Get Localization is a social platform for creating apps that really feel local for every user.

And here, those promised links:

The Importance of Localization in App Stores

Localization is the Key to Be Part of China’s 5.5 Billion App Downloads in 2012, Says ABI Research

Localization: the next big to-do for mobile app developers?

How To Automatically Sync Master Files From GitHub

Some people have asked us how to setup an automatic master file sync from GitHub to Get Localization when commit is done. We’ve done a short video previously that explains it but here’s step-by-step instructions as well:

1. First import the file from GitHub to Get Localization. You can done this from Files → Import from SCM → GitHub

2. Select the file you would like to import to master files, typically it’s the English resource file.

3. Now as soon as file is imported successfully, go to your GitHub project and open ‘Admin’-page.

4. Click ‘Service Hooks’

5. Select ‘GetLocalization’ from the list of service hooks.

6. Enter your project name, it’s the same as in your Get Localization address e.g. http://www.getlocalization.com/<project-name>. Also copy your project token from your Get Localization project settings page and paste it to corresponding project token field in GitHub.

66. 

7. Set project ‘Active’ and then click ‘Update Settings’

And that’s it. Now when you do the commit, all the files you’ve imported to master files will be automatically updated from GitHub.

Keeping Your Translations After A Small Change

You often think it’s a simple thing if you have to fix a small typo from original string or add a missing article, dot or comma… At least until you have to deal with the consequences. With most file formats, you will lose all the translations and you will have to fix them manually to every file. Some people write scripts for this, most people hail the new Get Localization feature that makes this problem a distant past.

We’ve heard your feedback and the feature is called “Import notifications”. You will get an instant and simple notification when you’ve changed a master string a bit (in other words, not much) when comparing to previous revision. We let you decide whether you want to keep all the translations for this string or not. In most cases, small change doesn’t necessarily mean that the meaning is changed. Even if there’s a small typo, translation is not typically affected by it so you can safely let system to keep translation.

Here’s also video that demonstrates the feature in more detail.

Get Localization talks with GitHub

Now you can import your master files from GitHub as well. It’s easy, watch the following video to learn how.

Introducing Get Localization SmartFront

I would like to briefly introduce you to our new product that is currently not yet released in Get Localization but will be available for public later this year. You’ve seen our In-Page Editor, right? Well the tech savvy user instantly asks a question “How do I get those translations to our site?”. There’s multiple solutions for that:

1. You can use traditional localization/internationalization file approach the most application frameworks offer. In-page Editor automatically detects even complex strings from websites and can populate them automatically. Let’s say if you’ve string “Hello Mike” in your website and translator translates it to “Hola Mike”, we automatically populate the translation to interpolated string “Hello %s”. These strings are of course also available for edit in our traditional editor as well.

2. You can use our API’s to fetch translations. Get Localization REST API allows you to do the translation work in your back-end and Get Localization Translate API makes it possible to translate in front-end/client-side with JavaScript. This API again works with interpolated strings as well, so if there’s translation for “Hello %s”, it’s able to translate “Hello Mike” correctly.

Or then, you can use Get Localization SmartFront. It’s a clever new way to translate websites without using any localization files or any modifications to code itself. You can take any HTML content, translate it with Get Localization and it’s available via SmartFront in your preferred domain name. Let’s say your company website is in address www.mycompany.com and you’d like to get that translated to Spanish. To get started you create a domain or sub-domain for this language, let’s say es.mycompany.com and point it to  SmartFront content delivery network (CDN). From our CDN, we provide the translated version of your site dynamically and instantly to the user.

So in short, Get Localization SmartFront offers a really effortless way to translate websites without touching the actual code.  We’re looking to get this out as a part of the Get Localization self-service offering as well, so it would be easy to even small developers to try it out and start using it. But currently if you’re interested of trial or how to work with us, please contact directly our sales at sales@getlocalization.com.

Ovi Store and Application Languages

Earlier today Nokia’s Developer organization (aptly named Nokia Developer) released a set of really interesting numbers.

See the article here: http://www.developer.nokia.com/Distribute/Ovi_Store_statistics.xhtml#article0

Let’s drill down behind the numbers and reflect for a second what they mean for selling and marketing your app. From astounding fact that Ovi Store is available in 190 markets to interesting tidbit that Turkey sees 1.6 downloads a week this article is a must read for anyone doing software localization.

90% of Ovi Store users have Ovi Store in their local languages (Ovi Store supports 32 languages)
So 9 out of 10 Ovi users see the store in their own language. What does that mean? First of all: your app needs to speak local language. We knew that already didn’t we? But secondly and even more importantly: your support and marketing material (like webpages) needs to speak user’s language. Localized apps and support material stand out in the crowd of English only apps and it makes it more likely that your app is promoted in country specific recommended lists (it also helps if you have a strong local brand).

The 10 most active markets are (in alphabetical order): China, Germany, India, Indonesia, Italy, Russia, Saudi Arabia, Turkey, the U.K. and Vietnam

To fully reach all top 10 most active markets your application needs to speak:

  • Chinese (Simplified)
  • German
  • At least English, Hindi
  • Indonesian
  • Italian
  • Russian
  • Arabic
  • Turkish
  • Vietnamese

Only top 10 countries you can cover with English are India and UK. And Latin character set gets us only half-way through this list. We have Right-to-Left language Arabic and we have Top to Bottom languages like Chinese. And we have cyrillic alphabet in Russian. Surprisingly no Spanish speaking markets are in top 10 of Ovi Store, but Spain is mentioned as one of the top 15 countries along with France. For app developer this list is a good check list for answering following questions:

  • What languages I should support with my app?
  • Is my web page and marketing material available in all relevant languages?
  • Am I addressing the right markets with my app?
  • What does it mean for my application to support Right-to-Left/non-Latin character set languages?
  • Is my beta test audience right?
  • Is “Lucy in the Sky with Diamonds” sung by William Shatner the greatest song ever? (yes it is)

It would interesting to drill down even further to these numbers. What is the actual order of these countries? What are the top grossing countries? Hopefully we will get to see these numbers next time.

Other Ovi Store Facts

Series 40 accounts for 25% of the Ovi Store downloads. And number of Series 40 devices out there is mind-boggling: 650 million. Series 40 users would form the third biggest country by population in the world!

In China Ovi Store is 7 times bigger than Apple App Store.

Active users download something 8.5 times a month.

Interesting numbers, aren’t they? What is the most important or interesting of all the numbers? And what number you would like to see to support your app business?

Video: Get Localization In-page Editor v2.0 (FIXED)

Follow

Get every new post delivered to your Inbox.