Localising iOS App Modules
Introduction
Localising your app can be challenging. Not only that you have to check the UI to make sure the strings are constrained appropriately. But there is also the challenge of dealing with the strings themselves. This article will show you a nice and simple way of localising your iOS/macOS app. :)
Preparation
First of all, we have to add another language to the app. This is done through the Localisation section in the Project Info Tab. A file called Localization.strings should be automatically created by Xcode. Apple calls this file a localisation table.
Localising modules
I wrote two articles about modular architecture on iOS while there module is a framework in this article module is a logically separated part of the app in a folder. But don’t worry the process is the same. :) I will demonstrate the localisation on my latest project called AchieveMe. So let’s say that AchieveMe has those modules — Dashboard, Friends, Goals, Login etc… Each module is a logical part of the app and has its own enum of localised strings. With that being said, you can imagine that by dividing localisation to modules will let you find strings in enum quite easily.
Localised enum
Since we have many modules with even more enums a protocol would be nice to define the enum interface. Let’s create a LocalizedStringRepresentable protocol that has a get accessor for a variable called text. The text variable will be the one we will use in the code to get our localised string.
Name-spacing
When it comes to localisation, namespace is your best friend. Therefore, we will namespace each enum with a unique path. Why does this matter? It might not be necessary in the beginning but when your app grows bigger and bigger you would have a hard time to think of a proper name for the localised string that has not been used in the localised table yet.
In our case namespace is going to be a module path separated by dots. For instance, module login will have a prefix module.login. as a namespace.
I would not advice on using localised strings from other modules. When it comes to a localisation it always worked for me much better to have it all strictly separated even though some strings were duplicated across modules.
Now, let’s look at the LoginLocalization enum.
Usage in the code
To have a localised string in the app simply select a proper key from the enum and call the text variable. The part I really like about it is that we are not using any raw untranslated strings in the code which makes the code much more clearer.
Localised table
The Localization.strings file for module login would then looked like this:
…as you can see each word has it’s module prefix.
Localised table lookup method
Finally, we need to create a String extension that will contain the localized method we are going to use for translating our name-spaced keys from the Localized.strings table.
Localising XIBs/Storyboards
Ever since I have discovered SnapKit(3 years ago) I tried to avoid using Interface Builder. However, you can simply drag the IBOutlet to the swift file and then use the enum to localised the strings in a proper way. :)
Testing your localisation
Once everything is set it is time to try the app in other languages. Luckily, Apple made that easy for us. You can specify the application language under Edit Scheme → Options. The app will then launch with the specified language.
Conclusion
In this article I described a nice way of localising modules of an app with enums. If you are interested in modular architecture on iOS you can read about it here or here. :)
If you find these articles useful please comment or give me a clap (…or 50) :)
Thank you very much for reading.
