Writing Content for Localization

Localization in any organization doesn’t limit only to translating and adapting source texts and other materials to a target market. A good and also cost-effective localization process starts earlier than in the moment when the developers send texts to translators. It naturally contains all necessary technical steps, but we’ll skip them this time and focus on the translatable texts themselves and what you can do to make them efficient from a localization point-of-view.

Many of these tips are quite general so they will help you improve your original texts too. They have been written especially with UI, help and support materials in mind – writing for your landing page might be a completely different ballgame but many of the rules apply there too.

Fluent and Correct

Would you trust a linguist to do code for you? I wouldn’t either (and I’m a linguist). Don’t put too much trust in your developer’s linguistic ability either.

Software and other web content are nowadays mostly written in English, which often is a good choice for localization and translation purposes, as the most translators around have English as one of their source languages. But other languages are used too.

Whichever your writing language of choice is, make sure the texts are well written. If your own or your developer’s English is not that good, have the texts edited by someone whose knowledge is more solid. “Engineering English” might create misunderstandings for your users, and those misunderstandings will get multiplied in localization.

Consistent Terminology

Stick to the terminology you choose and make everybody who is writing content also aware of it. This also means not using one term for several concepts. This might in many cases leave the translator wondering which of the concepts you’re referring to – and even get yourself in trouble when you want to mention those two concepts in the same sentence. Put a system in place to manage and spread terminology in your organization.

Reuse

At school, you learn that you shouldn’t be overly repetitive when writing, so you don’t make the reader bored. This is mostly true, I don’t want to argue with your elementary school teacher, but when writing software texts, repetition is your best friend. And this goes for basically any help and support texts too – or anything you write with localization in mind.  Identify parts of text that appear in many places and don’t rewrite them. The commonly used localization tools identify what has been translated earlier and you can usually have those parts translated automatically. The more similarities the new texts have with old ones, the less their translation costs. Repeated terms and structures are easy for the translators.

Using the same terms and structures also makes things easy for your user: they will be more familiar with different parts of the UI and have a more fluent experience.

Be Concise

Don’t write overly long texts unless you have a true motivation for that. English is often shorter than many other languages, e.g. German translations tend to be around 3o% longer than English texts, so don’t aim at filling all available space already in the English version. Other than that, concise texts are mostly user-friendly, too. You don’t want your users to leave your page because of texts that take ages to read and are difficult to understand, right?

Localization cost is almost always directly tied to text length, so this point is also directly linked to your bottom line.

Text in Graphics

If you want to make localization easy, embed as little text as possible into graphics. Each time you localize texts that you have as graphics means manual labor, which means more costs. Each time you add a language you need to update all graphics manually.

Cultural References

Funny slang words can nicely spice up a text, as will idiomatic expressions. And make you sound like someone who really masters the language. But at the same time, they make localization more difficult and might even be nearly impossible to translate. For translators, there are ways to get around that, but you don’t want to make translating more difficult and error-prone. The same goes rid of jargon and metaphors, you need to get rid of them.

A Final Pointer

Being customer centric pays off in localization too: if a text is optimal for a user in your own language area, it probably is easy to localize.

Photo by Thomas Lefevbre.

Improving SEO Rankings through Localization and Correct Use of Hreflang

Google needs a bit of help to detect your website’s localized language versions. To do this correctly, you need to be aware of the hreflang attribute and how to use it.

Let’s now assume that you have ordered professional translations from Get Localization for your site from English to Spanish. You define an alternative version of your site using the link tag and hreflang attribute like this in your English website:

<link rel="alternate" hreflang="es" href="http://es.example.com/" />

This means that your Spanish website will be found at http://es.example.com. But now, hold on! This is not the whole story, and some precautionary measures should be taken to do this correctly.

First and foremost, make sure that Google Search Console is tracking your website property (https://www.google.com/webmasters/). This is important as it lets you see whether your hreflang tags and international targeting are working properly.

Furthermore, you need to use these tags correctly – if you just go and add hreflang tags into your site, I bet your Search Console will show “Hreflang Tags with Errors”.

Most common hreflang error is “No return tags”. This happens because your English page links to Spanish page, but your Spanish page does not link back to your English page. Why must it do that? Well, Google uses this to verify that the content really is an alternative version of your site.

So, you also need to add this tag into your Spanish page:

<link rel="alternate" hreflang="en" href="http://www.example.com/" />

After this you’re good to go. Google will now process your site. However, it will take some time. Google’s indexing is otherwise fast, but not so much for international content.

The wrong language code is also a common error. You can find a list of language codes and region codes on Wikipedia. From us, you will receive the correct language codes along the translations.

Localizing Apps Webinar

We had a webinar about apps localization & translation with Nokia earlier. It’s meant for Nokia Asha developers but provides a lot of general information about app localization as well.

So here it is, finally:

Quick i18n Tip for Sublime Text Users

Do you hate wrapping your content with i18n tags? Yeah me too, however your editor might do this much easier for you. Here’s a quick tip on how you can create a shortcut to add e.g. a Django trans template tag around a string in Sublime Text:

1. Open your keymap preferences: Sublime Text → Preferences → Key Bindings (User)

2. Add the following snippet there:

{ 
 "keys" : ["ctrl+shift+g"], 
 "command" : "insert_snippet",
 "args": {
 "contents": "{% trans \"${0:$SELECTION}\" %}"
 }
}

Now when you select the text and hit ctrl+shift+g, it wraps the text with Django’s i18n template tag like this:

{% trans "Continue" %}

If you have any other  tips how to do i18n easily, let us know in the comments below.

Apps Localization for Nokia Series 40 and Asha

We have recently added support for the Nokia Java SDK, which is an Eclipse based IDE for Java ME development. This post covers basics on how to get started with localizing your Java ME apps for multiple languages by using the Get Localization Sync plug-in and Nokia Java SDK.

Getting Started: Install Everything

If you don’t have the latest Nokia Java SDK, you can download it from http://www.developer.nokia.com/Develop/Series_40/.

Then you need the Get Localization Sync plug-in.

• Open your Nokia Java SDK
• Choose Help -> Install new software…

Installing the plug-in

• Click ‘Add…’
• Enter a name for the repository, e.g. Get Localization
• Enter the repository location, which is http://getlocalization.sync.s3.amazonaws.com
• Click ‘Ok’
• Check ‘Get Localization Sync’ plugin
• Click ‘Next’ and follow instructions

Internationalization

If you are not aware of the concept of internalization or I18n, please refer to our earlier blog post Software Internalization for Dummies. Java ME is one of those frameworks that are shipped without a standard internalization framework. Fortunately Nokia provides internalization support within their SDK and it’s easy to set up.

When you create a new project, you have an option to ‘Enable Localization Support’ (see screenshot below). This feature allows you to localize  your application strings easily.

Screenshot #1

TIP: If you already have a project and/or an existing app, you can enable the localization support by right-clicking your project and selecting ‘Mobile Tools for Java’  ⇒ ‘Enable Localization’.

So now you have everything set up, let’s see what the SDK created for us:

Screenshot #2

As you can see, there’s now two new files inside the package that we defined in the previous step.

L10nConstants.java – This is a generated Java file and will contain all the metadata of your localization data.

L10nResources.java – This is a utility class for loading the strings inside your UI.

Then we got the new editor called Localization Data. This editor is used to manage all your application strings. First you need to add your first ‘locale’ i.e. the language your application will be translated from. We recommend writing the initial version in English, as it’s easier to find translators to translate from English than other languages. Click the ‘Add locale’ button and it will add automatically en-US language for you. Make sure to check ‘Default locale’ on for this language (you can find this option to the right). You can also modify the language and country code here if you want but it’s not necessary if your app is in English.

Next you can add your first entry. Entry is a string you are using in your application, let’s say you have a ListBox element and you are setting a title for it like this:

listBox.setTitle("My Awesome App");

Now, what you want is to add this very same text as an entry to the localization file. Click ‘Add entry’ button in Localization Data editor and define key for this entry e.g. LISTBOX_TITLE and then the value ‘My Awesome App”‘ Hit save and now a few things happened:

1. Inside the res folder you can find a file called messages_en-US.properties. This is a master file which will be translated into another languages.
2. L10nConstants.java was generated and updated.

This means that you can now modify your code to use these new classes.

First of all, you need an instance of L10nResources, for example:

L10nResources res = L10nResources.getL10nResources(null);

Given parameter is null here but you could also define language code here e.g. “en-US” or “fi-FI”. It’s good for testing purposes so you don’t have to change e.g. your emulator language. Giving null means that it will try to use the same language the device is currently using.

Now we can actually load the string from resources instead of hardcoding it:

listBox.setTitle(res.getString(L10nConstants.LISTBOX_TITLE));

That’s it. Now the text is always loaded from resource files based on the phone language.

Localization

That was easy. Now it’s time to start translating your app and for that Get Localization is the perfect companion. It is a browser based service that will help you manage the files, translate them and even let you to manage your own translators if you wish. This part assumes that you are familiar with Get Localization already. If not, then please  visit the frontpage, take a tour or if you have questions, create a support ticket in the ticketing system and someone will get back to you ASAP.

Configuring the Get Localization Sync Plug-In

First you need to configure your Get Localization Sync plugin. I hope you already installed it but if not, please refer to the section ‘Getting started: Install everything’.  Now in Package Explorer, right-click your project name e.g. MyApp in Screenshot #2 and select ‘Properties’. Then find Get Localization Sync leaf in your properties and you should see the below screen:

Screenshot #3

The following fields are used:

Username – Your Get Localization username

Password – Your Get Localization password

Project – Your Get Localization project name (same that appears in project URL e.g. http://www.getlocalization.com/example/, where example is your project). If you don’t have project, please create one first at http://www.getlocalization.com/signup/

Default Platform – Platform you are developing on. IMPORTANT: You should choose “Java Properties (UTF-8)”

Pull file filter allows you to filter which files you wish to pull to your Eclipse project. For example just pull all the .properties files, you can use filter:

.*?properties

Replace rules can be used to alter file names when they’re pulled to project. Typically it’s not necessary but you can e.g. rename language codes in files in case they happen to be wrong.

Replace rules can be imported and exported so if you manage to do proper rules, please do share them with us. We’re happy to add them to our library.

Sending Files to Translation

Simply right-click the file in the res folder called messages_en-US.properties, then select ‘Get Localization Sync’  ⇒ ‘Send to translation’.

Syncing Translations Back to Project

When the files have been translated, you can sync them easily back to your project. Right-click ‘res’ folder and select ‘Get Localization Sync’  ⇒ ‘Sync translations to this folder’ and that is it.

Localizing Your Other Data

Metadata such as Store Description

It’s highly recommended to localize your store description and other meta data. You can add multiple files to Get Localization so it’s easiest to add the store description e.g. as a plain text file. You can do this via browser on Get Localization project (Files tab)  or via the plug-in.

Dates and Times

Java ME does provide some help to localize dates and times. What you want to do is to provide them both in the same format based on user settings. These settings are already configured in the device and accessing them is easy.

Dates

You can get currently used date format using following piece of code:

String format = System.getProperty("com.nokia.mid.dateformat");

This method returns for example these values with following settings:

Gregorian calendar date in little endian format: dd-MM-yyyy

Gregorian calendar date in big endian format: yyyy/MM/dd

Gregorian calendar date in big endian format: yyyy-MM-dd

Note that the date separator can be often changed from the phone settings.

Time

In a similar way you can also get the time format which the Nokia Series 40 or Asha device is configured to use.

String timeFormat = System.getProperty("com.nokia.mid.timeformat");

In this case the return values are a bit simpler:

HH:mm means 24 hours clock

hh:mm a means 12 hours clock