Localizing strings into different target languages is one thing, but what about localizing software? How do strings from different software codes get translated into a specific language and how is it different from localizing a document?
Imagine this scenario: you are a developer who has to send their code to be localized. But that code is your baby – your own flesh and blood – and you don’t want to send it to be localized because chances are, it’s functionality would get messed up along the way.
Well, we only have one word for you: I18N. Trust us, it’s not just a bunch of letters and numbers thrown together, that means Internationalization.
How does internationalization work?
Internationalization is the process by which all the strings that have to be localized will be moved into a file, separate from the code, called the resource file. This way they can be easily localized without affecting the code.
If you’re a newbie about these terms, think of it this way: software is written as a code where developers can put strings (read: words), and these strings will appear on the UI (read: your screen). Now, let’s say you want the word ‘Cancel’ to be localized. But since it’s in the code, it will be hard to localize since the people in localization hardly understand the code. So what you will do is put the word ‘Cancel’ in a separate file to send to the localization team.
Why should you do this?
The benefit of internationalization is that it makes localization possible in the first place. If internationalization happens, it shortens the amount of time needed to localize since everything is on one file, and consequently engineers don’t have to come up with crazy workarounds!
Think of the process as the investment itself; the effort on localizing software after internationalization is done would be considerably lower, faster, and cheaper since you can localize up to how many languages you can and already have one resource file.
Have you found this blog helpful?
