Localisation and Localisation Register

Introduction

There’s nothing worse (we think) for a user of your App, to open it up only to find it isn’t using your native language. We get a little twitchy if we see “color” instead of “colour”, as an example. What’s more, localising your App into various languages will no doubt help push sales. People love that you cater for them and we believe it shows respect.

The game industry “standard” for minimal localisation are the following languages:

• uk: UK English
• en: US English
• fr: French
• it: Italian
• de: German
• es: Spanish

You should most definitely also consider localising into Chinese (Simple), Japanese, and other languages that are becoming more popular to include, such as Dutch and Portugese. We also include au: Australian English into ours, however, we’ve yet been able to set this up on our devices, which is odd. The reason we may want this is that some words we use to describe items, are different to what’s used in the UK or US.  Overall, when it comes to localisation and who to cater for, you’re only limited by your localisation budget.

Budget? Yes, please PAY someone to localise your text for you. Don’t rely on Google Translate – it doesn’t always get it right, particularly when it doesn’t understand the context of the words or sentences that you are plugging into it. Context can dramatically change translation. There are loads of Freelance Translators online these days who charge very reasonable prices for localisation, based on the number of words you require translations for. And the majority of these people’s language that you require are natives to that language, so the translations should be far more reliable. It’s always a good idea to submit text with context/descriptions next to those whose context might be difficult to interpret on paper alone.  For example, “Close”. Is it “close that book”, or “I’m close to the target”?

Don’t under-estimate professional translation services… Bad translation = “We don’t respect your language” in our eyes.

The Localisation Register

Before doing any work in X-Code, you should always have a Localisation Register. This is a spreadsheet (we use Excel) of all text that requires localisation. From front end, to native pop-ups, to your App’s name and every where that text is used.

Don’t just write it straight up into the Loclization.strings file in X-code, for these reasons:

1. You might accidently build over the X-code project, thereby losing all of your Localisation strings.
2. It’s a terrible way to track localised strings – what is localised and what’s not – thereby opening up room for ghastly errors
3. It forms a part of ‘best practice’ in professional game/app development. The Localisation Register should be an Appendix to your App’s “Design Document” or as we call it, “App Blueprint”. Planning properly from the beginning will save you so much time in the future.

What is the Register?

The Localisation Register is a spreadsheet that contains the following headers:

• Class (where we stipulate whether this particular row is a Comment or Variable)
• Key (the String type key/legend for each line that is referenced in our code in Unity)
• Column for each language (contains the text to display for that Key or String e.g. each column is named US, UK, AU, FR, DE, IT, ES)

 

Our Register also has TWO (2) Tabs, named:

• Data Entry
• Export for .strings

Data Entry Tab

The Data Entry tab is where we enter in all of our text. Where we don’t have translations yet, we put “TODO”. That way, in-game during testing on other languages, if we see “TODO” we know that there is a translation missing for that line of text.

Here’s a snapshot of our spreadsheet:

The data entry tab in our Localisation Register

As you can see, for the class we use either “Comment” or “Variable” to describe what each row is. A “Comment” row is just that – a comment you want to be inserted into your final Srings file in X-code. A Variable row is the actual string reference you want in your Strings file.  When we enter either “Comment” or “Variable”, our spreadsheet automatically detects it and colours the row to make things easy to read. This is an Excel function, and we won’t be going into that here (Google for Excel tutorials on this).

For the Key in column B, use only one word (no spaces). We use underscores, as well, to help make things easy to reference. e.g. Loading_ for loading screens, Menu_ for menu items, and so on.

Disclaimer: For the sake of this How-To we DID use Google Translate for the above translations 😛 Don’t do this for your final App!!! (We’re not sure if they’re right or wrong lol)

Export for .Strings Tab

The Second tab, called Export for .strings is a direct copy of the above tab, except it contains a formula that reads each row Class type, and formats / spits out the correct variable for each string as it needs to be written in the .strings file.

A string in the .strings file must use the following format:

“myStringID”=”This is the text for my string.”

Obviously, having to put your strings into the format above by hand is a pain in the posterior. Hence, why we created the following formula to do it for us. This then frees us up to change text willy-nilly without having to worry about the format output.

This is a snapshot of our Export tab:

Where the magic happens
These columns are copied and pasted into each Localizable.strings file for each language

Note that each time you insert or delete rows, or change the order of rows in the Data Entry tab, you will need to Refresh or recopy and paste the formula down the columns in the Export tab in order for it to update correctly.

The Formulas

In row ONE (1) ONLY, from Column C ONWARDS we have the following formula in all cells from C1:F1 (note that B is just empty for us – you don’t need it. And there is no formula in cell A1)

<br />="/*"&'Data Entry'!D1&"   Localisation Copyright YOURNAMEHERE 2013"&"*/"<br />

Of course, replace “YOURNAMEHERE” with your Copyright name if you wish. You can remove “Copyright” as well, and insert with any text you want at the top of your .strings file.

Note that in the above formula, and those below, ‘Data Entry’ is the name of the TAB. If you don’t call your first tab “Data Entry”, then you will have to change all formulas we give on this page to use the name you use for your data entry tab.

In Column A (all rows) we simply have the basic formula as follows, just to copy the Class name:

<br /><br />=+'Data Entry'!A2<br /><br />

Finally, the most important, formula we use is the one that creates the final OUTPUT text for the .strings. Be sure that you have the same number of columns in your EXPORT tab as appears on your DATA entry tab. From cells C2:I5 (or how ever many languages and rows you have – essentially all rows and columns that are left over), copy the following formula:

<br /><br />=IF($A2="Variable", (""""&'Data Entry'!$B2&""""&" = "&""""&'Data Entry'!C2&""""&";"), "/*"&'Data Entry'!$B2&"*/")<br /><br />

This formula will automatically format your data from the DATA tab into the correct format, ready for you to copy over to your .strings files. (It’s quite a long function, so make sure you copy it all from above.)

Your Export tab should look like the one above. If you notice any errors, it’s likely you have incorrectly copied a formula or put a wrong entry into the Data tab. Note that in the above example, we’d be deleting row 6 – it’s showing that there is no data and the row above it is the final data entry, so there’s no need to have row 6.

Next, we’ll move to Setting Up Xcode for Localisation.