Unity makes things easier by streamlining the development process.
This includes localization, too, so you can open up your game to the global masses. However, you need to be careful because game localization is a tricky process.
This blog was originally posted on Level Up Translation's blog on October 23rd 2016.
Unity is one of the most popular game engines for independent developers. It’s a cracking tool that opens up the gaming industry to even the smallest of publishers and one-man bands.
The problem with taking the independent route is you’re always fighting to match the standards and workload of bigger teams. Unity makes this easier by streamlining the development process so you can get more done with one pair of hands.
This includes localization, too, so you can open up your game to the global masses. However, you need to be careful because game localization is a tricky process – so let’s look at the best way to go about this in Unity.
Smart Localization (free and paid versions)
We’re off to a good start with localizing in Unity because it comes with an extension designed to make this easier for you right out of the box. The extension is called https://www.assetstore.unity3d.com/en/#!/content/7543">Smart Localization, which was developed by janeTech, and there are two versions: a free option and a paid Pro version.
Here’s what you can trust Smart Localization to do:
- Create your folder structure for different languages
- Import and export files
That’s pretty much it. Don’t even waste your time using the translation feature which is powered by Microsoft Translator. The author says this is only intended to create temporary translations for the development process, not for final translations. But even using it for this can cause problems with the length of text and size of your game elements.
I2 Localization ($45)
Among paying assets, https://www.assetstore.unity3d.com/en/#!/content/14884">I2 Localization, developed by the game studio http://www.inter-illusion.com/tools/i2-localization">Inter Illusion certainly represents a valuable option.
Google Spreadsheet live synchronisation and Automatic Right to Left display for Arabic are some of the handy features offered by this asset.
"I2 Localization in general is an amazing tool for localization. [...] First and foremost is their ability to import data directly from a Google Sheet, even after a game is released. This is extremely helpful, as most localization companies give you the results in an Excel file, making it simple to just swap it over to a Google Sheet and import all of the data.
The other feature I love deals with hardcoded text in code, as mentioned above. Now instead of having to deal with a loop or switch statement or whatever your preferred method is, you can just use a single line to translate that text: I2.Loc.ScriptLocalization.Get("");."
Daniel Batoff from MegaDwarf
Source: http://www.gamasutra.com/blogs/DanielBatoff/20161007/282861/Localizing_a_Unity_Indie_Game_The_Hidden_Costs.php
Both extensions are popular choices with Unity developers (particularly the free version of Smart Localization, for obvious reasons). They certainly make useful tools, but use them with care. No extension can take care of your whole localization needs and certainly not the translation process.
So….
There’s no way around this one, if you’re serious about releasing your game in overseas markets. You need to get professional video game translators on board and the sooner you start working with them, the better.
Get your first draft of translations in before you start developing.
You’ll save a whole bunch of time by coding your game after the translation process is all taken care of. Pay special attention to the length of words and sentences in each translation, compared to the English version (or whatever your base language is). This way you can make any design tweaks that are necessary or go back to your translator and work on alternatives.
Doing this after development has already finished is a nightmare.
Once development begins, the first thing you need to do from a localization perspective is choose how to format your text strings. This isn’t just a development choice you’re making here; this will decide how easy/difficult it is to add new languages to your game in the future or edit your existing translations.
Unity supports a number of formats, but the most popular seem to be:
- JSON
- XML
- YAML
- CSV
You can also create your own customized format, if you prefer. However, this always leaves more room for errors and is certainly the most complex option for localization. So it’s not something we’ll be looking at for the purposes of this article.
If you’re developing your game in JavaScript then it makes absolute sense to go with JSON. It’s a simple, light format that tons of developers have adopted over the years and it’s a fast performer. Aside from the development perks it’s also easy to read, even for non-developers – which is a major plus for future translations and edits.
Many developers still go with XML and it’s a good choice if you prefer to work in this particular markup language. It’s not the most efficient language and it’s harder to read so consider these issues as you code your game.
As for the other options, they’re definitely more problematic from a translation perspective but you have to go with what you’re most comfortable working with. Just make sure you work with your translator to make their job as easy as possible – because it’ll mean less mistakes.
Structuring your strings in the most efficient way can be a real challenge. There are no set guidelines for this and Unity gives you a lot of freedom to structure how you please. Freedom is always good, of course, but it also allows more room for mistakes.
There are three main factors at play in string structures:
1. Language
2. String IDs
3. Text
Language
For most games (where language choice is saved at the start) you can store your strings in separate files for each language – eg: en.json, es.json, fr.json, etc. This is the most resourceful way to separate your strings by language so your game doesn’t have to process additional files unnecessarily.
String IDs
Next up, you have to think about your string IDs. The size of this task largely depends on the quantity of text strings your game includes. You need to anticipate problems when you create string IDs, giving each of them a unique and descriptive ID that makes individual string easy to pinpoint at a later date.
A lot of this comes down to personal preference, but always remember other developers could be working with your code in the future.
Text
As for the text itself, always create strings with localisation in mind. The most common problems you’ll run into are varying lengths between different languages and occasions where there is no real translation for certain springs. Don’t let this compromise the quality of your script but shortening the odd string or writing in simpler languages might help later on.
By following this approach, the process of storing and retrieving your localized strings will be much simpler. You’ll not only reduce your workload this way but also reduce the risk of errors.
Unity allows you to create components, which cuts out a good chunk of the manual coding process. Once again, this is as much about reducing the risk of errors as it is about saving time.
You can find more information on components from the Unity resource page. For our purposes here, though, we’re going to focus on a select few tasks:
- Allowing users to change language
- Save the new language choice
- Automatically set this language upon game restart
- Load the correct string for each value
With Unity components we can take care of all four tasks in one simple action!
Most gamers will only need to set their language once and be done with with it. One option you have it to detect the user’s location and set the local language as default – although you may want to include a prompt screen asking users to confirm their language when they boot up for the first time.
Not all American’s speak English as their first language, for example.
How you choose to design and implement this functionality is as much about user experience as it is localization. The important thing here is to save the value they set (if any) and store this as the new default. This way you don’t have to ask them the same question every time they start your game.
To do this in Unity, you’ll want to create a Master component to assign the default language. If the user decides to change their language preference, this will be assigned to the component and act as the default language.
There’s no way around it; localizing visual elements in your game can be a pain. The first thing you need to think about is fonts – not only in terms of how they look in but also which languages they support. Here are some things to consider:
- Style
- Language support
- Font sizes
- File sizes
Style is important for the branding of your game, of course. You may find a font that looks great in English but find it doesn’t support the languages you need. Which leaves you with a decision: do you look for one font that supports every language or combine different fonts to cover everything you need?
This depends on how many languages you need to cater for. Finding fonts with accented characters (for Spanish, French, Italian, etc.) isn’t too difficult. But you’ll struggle to find one font that supports multiple European languages and Asian writing systems, for example. And, even if you do, that’ll be one huge file size – so don’t be afraid to find separate fonts for different languages, as long as you’re happy with their styles.
Not all of your text will necessarily be hard-coded, either. Certain text elements will be graphics and there are various other visual elements you need to think about, too.
Text graphics
The majority of your text graphics won’t need to be localized at all. For example, unless you decided to localize them, your character names will stay the same for each language, so any graphics with their names (eg: badges, player icons, etc.) can be left alone.
However, names that have a rich meaning – like metaphors or a play on words – might need to be localized or some players will miss out on the joke. It’s not only character names you need to think about either, but level names, weapons and other in-game items.
Above all, make sure you don’t overlook any text graphics that have an impact on gameplay. It could be something simple like a UI element inside a mini-game but you’ll kick yourself for missing small details like this.
How to localize your text graphics in Unity
Once you know which text graphics you need to localize (and which ones to leave alone), Unity makes it easy to switch your graphics based on user language choice. There are three methods you can choose, each with their own pros and cons:
- Create atlases in the Unity Sprite Packer
- Create individual graphics and call them in as needed
- Replace graphics with text and UI elements
If you can manage the workload, we recommend creating atlases in the Unity Sprite Packer. This way you get to keep the polished look of using graphics but maintain performance. The downside is it takes more work to create these atlases, but the sprite packer tool speeds this process up for you.
You can get the same visual look by creating separate localized graphics and calling them in as needed, but this is by far the least resourceful approach. If you’re not careful, your game could run slow.
Another option is to replace graphics altogether with text strings and UI elements. This may not look as great as the graphics option but it’s by far the most lightweight approach, which will help you maximise performance. You can also fit this in with your standard localization workflow by passing this text on to your translators along with your other strings.
Unity AssetBundles allow you to create file packages that users download only when they need them. This means you can drastically reduce the overall size of your game while providing full assets for every audience you need to localize for.
For example, users will only download your French text files if they choose that as their language. Otherwise, they don’t need those files and they stay safely on your servers waiting for anyone who needs them.
This not only drastically improves performance by reducing the number of download resources, it also makes you games smaller/faster to download in the first place. Best of all, you don’t have to make compromises on the files and assets you create for localization. You can cater for every audience you need to, knowing they won’t be held back by any resources they don’t need.
So there you have our starter guide for localizing games in Unity. The bad news is you can’t do this alone – if you're serious about the quality of your game's localization, you have to work with game localization specialists. However, the good news is Unity makes much of your other localization tasks easier to manage.
What it can’t do is teach you how to do localization properly, so be sure to get in touch with us if you need help with localizing your indie game for international audiences.
If you like what you just read, we've got more for you!
Just follow us for more game localization tips and insights:
Facebook
Twitter
LinkedIn
YouTube
Read more about:
BlogsYou May Also Like
