Localization in Unity with No Such Localization
Localization in Unity with No Such Localization is easy and truly convenient. We used that package to localize our game 10th Corpse into several languages, and it was a straightforward process. When the time came to localize our game, we evaluated the localization options available for Unity. The canon choice, so to speak, is Unity’s own Localization package which, however, required us to update our project and also, at that time, did not have an expedited installation (it had to be installed manually.) In the long run, Unity’s Localization package is likely to become the standard and the first choice of Unity developers, but for now it’s still at the preview stage.
For 10th Corpse, however, No Such Localization was a wise choice. In fact, No Such Localization offers much more than what we really needed to localize our game, which only required localization of strings. No images and no audio had to be localized in 10th Corpse, but if your project needs that, No Such Localization easily allows for it.
What is No Such Localization?
It’s a localization package for Unity, and it comes in 2 versions: Lite and Pro. Both versions are available in the Unity Asset Store. The Pro version (paid) offers even more features, such as support for Right-To-Left (RTL) languages (Hebrew, etc.), automatic variable replacement, and translation source classes for JSON and CSV files (more about this in a while.) Even the Lite version is awesome and, as told above, it offers much more than what our game’s localization required. No Such Localization integrates naturally with the Unity editor, and requires no coding unless you want to extend its functionality. And that’s the beauty of the package: its architecture, which makes it a breeze understanding and extending its functionality.
How to work with No Such Localization?
Let’s first understand the architecture of No Such Localization. The official documentantion is here and is very good. You’ll work with 3 classes of components. The most important of these components is the LocalizationService. It’s the core of your localization, and you should have a single instance in your scenes (ideally, use DontDestroyOnLoad to have single, persistent LocalizationService object if your project comprises multiple scenes.) Just create an empty object and append a LocalizationService component. Now, in the Locales list, add the languages you want to support, e.g., English and German. There are a few attributes, but you’ll be mostly changing Current Locale. Once you complete the localization process, modifying this Current Locale will immediately switch your project’s content to the localized strings and assets corresponding to such language.
So, main component: LocalizationService. We have yet to work with other two components: ComponentLocalizer and BaseTranslationSource. LocalizationService is our core, our hub, the ruler of all the localization of your game. However, it needs to know what scene’s objects (strictly speaking, components) it has to localize, and it also needs to know where it’s going to find the content with which it will localize those objects. For instance, let’s suppose you have a Text object (again, strictly speaking, an object with a Text component) displaying a “Welcome” string. The LocalizationService can automatically localize that object, but it needs to know that such object has to be localized (that’s the responsibility of ComponentLocalizer), and it needs to know what content it will use to localize the object (that’s the responsibility of BaseTranslationSource.) You can subclass both ComponentLocalizer and BaseTranslationSource to adapt them to the requirements of your project, but No Such Localization comes with classes that will suffice for basic requirements. For instance, the package includes a TextLocalizer component.
In continuation of our example, let’s add a TextLocalizer to our Text object having the “Welcome” string. You’ll notice that the TextLocalizer component has a Phrase attribute. When localizing, you’ll have to remove string literals (e.g., “Welcome”) from your components and replace them with unique IDs. The localization components will used those unique IDs to identify the content. Place unique IDs in that Phrase attribute, e.g., welcome_text. Now we need a Translation Source with an entry for that unique ID, welcome_text. The package comes with a very basic translation source, StandaloneTranslationSource which we can recur to for a simple use case like this. Create another object, add a StandaloneTranslationSource component, and edit its Translation List attribute to add welcome_text as an entry of such list, with translations for Locale English and Locale German.
That’s all. All the components of No Such Localization will connect among them automatically, and if you go back to your LocalizationService component and change the Current Locale you’ll see your text component modifying its content accordingly. It’s like magic!
Of course, if your project is medium or large sized, working with the StandaloneTranslationSource can be tiresome and error-prone. You might want to read your content from a file (the Pro version of this component comes with translation sources for JSON and CSV files.) The wonderful thing about architecture of No Such Localization is that you can extend it as you wish (we created our own Translation Source class for 10th Corpse.) And you can also create your own ComponentLocalizer for your specialized widgets, for example. You can localize text, images, sound, etc. Further information in the official documentation. An excellent tool for localizing your Unity project!
