Are you developing software that’s going to be used in multiple languages? If so, it’s time to think about localization. Localizing your software properly is crucial if you have global success in your sights.
I do find, though, that localization – or l10n – gets something of a bad press. It’s often perceived to be more complex than it actually is. That’s why I wanted to take the time to run through some of the basics of software localization with you.
Let’s start with a quick software localization definition. What is software localization? Software localization is the process of adapting the language, look and feel of software to meet the needs of a specific audience.
The software localization process involves making changes to everything from your user interface to your documentation. Images, formatting and more is put under the microscope and adapted to meet the needs of the new audience.
I find the software localization process fascinating. When done well, it adapts the software in linguistic, cultural and practical terms to the point that the new audience feels as though the software was created for them initially.
From a business perspective, software localization means you can plan to engage with global audiences in order to increase your customer base. You can capitalise on this to grow your brand and increase your profits.
Software localization also means that you can get better value for money from your applications. Building it into the development stage of your work means that it takes relatively only a little additional expenditure in order to convert your software from being suitable for one language or country to being suited to multiple audiences.
I think one of the reasons that developers tend to sigh when they think about tackling a localization project is that the process used to be pretty unwieldy. Do you remember those days of having to extract strings and source content and paste them into spreadsheets, then having to put the localized strings back into the software? Thankfully, the process is much more efficient these days. It’s all about having the right resources.
If you need localization tools, I recommend you map out which ones you’re going to use and why. These days, there are some superb localization platforms on the market. These help to automate the software localization process while still retaining the human element of translation.
Look for a platform with an integrated translation provider if you want to take the most efficient approach. This will provide you with the skills you need to judge the number of people needed relative to the volume of the project, as well as access to translators who are experts in the l10n process.
In terms of your resource files, these will contain resources for a particular language. They will define how you handle user-visible strings in your software. You can use properties files to do this, with files for each language. Or for Android you can use the strings.xml file in the relevant directory. Meanwhile, for iOS, you can use Localizable.strings files for each language. You should end up with a resource bundle for each language.
Your strings are the things you’ll mainly localize when it comes to adapting your software to foreign audiences. The localization string process is best undertaken during the design and build phase of your software, rather than once it’s complete.
If you’re focusing on localization strings, there are a few best practices that I believe will make your life easier. Firstly, avoid hard-coded strings. Secondly, don’t concatenate your strings. I know that it can save space, but it won’t help you when it comes to differing word orders in different languages.
Finally, explain your strings wherever possible. Providing context will pave the way for faster, more accurate translations.
Complexity of Your Source Language (Main Software Language) H3
The complexity of your main software language can impact the localization language process. It’s better if English is your base/main language, though of course application localization is still possible if it isn’t.
I didn’t include a mention of internationalization (i18n) in the software localization definition above, but it’s an essential part of the process that warrants discussion here. Before you localize, you must first internationalize.
What does internationalization involve? It’s essentially the stripping away of as many elements as possible that tie the software to one language or location. The outline process flows like this:
• Application framework review
• Dynamic UI expansion
• Coding for string localization
• String extraction
• Resource file preparation
Let’s look at each of these in turn as part of your localization software process.
As I mentioned, software localization is the process of adapting your software to suit new audiences. To do that, you need to make sure internationalization has been taken into account into the code (i18n). However, the way that you do so may be restricted by your application framework.
That means that the first thing you need to do is review your application framework to see if your localization software will support the internationalization process. Once you’ve done this, you should have a clear picture of any constraints that the framework imposes.
While English reads from top left to bottom right, not all languages are the same. Some read from right to left, others horizontally. Then there’s the fact that different languages use different numbers of words to say the same thing. Average word length varies between languages too.
All of this means that you need to factor a dynamic approach to language as part of your internationalization process. Thankfully, dynamic UI expansion is there to help. Opt for Fragments in Android and Auto Layout in iOS to ensure that your text fits perfectly, no matter which language it’s in.
Coding for string localization means extracting your strings, localizing them and then reinserting them back into the code. This is where Unicode really comes into its own. Unicode encodes scripts for languages, covering a huge range: Latin, Greek, Cyrillic, Armenian, Hebrew, Arabic, Syriac, Thaana, Devanagari, Bengali, Gurmukhi, Oriya, Tamil, Telugu, Kannada, Malayalam, Sinhala, Thai, Lao, Tibetan, Myanmar, Georgian, Hangul, Ethiopic, Cherokee, Canadian Aboriginal Syllabics, Khmer, Mongolian, Han (Japanese, Chinese, Korean ideographs), Hiragana, Katakana and Yi.
UTF-8 and UTF-16 (for Asian languages) will likely prove the most useful to you during the internationalization process.
Once you’ve prepared your strings for localization, it’s time to extract them. You’ll need them in a format that your translation team can work with quickly and easily.
These files contain resources for each particular language that you need. They will allow you to deliver appropriate string values for each language/location when someone uses your software.
There are several important steps in the localization process. These include:
• Platform selection
• Resource file extraction
• Translation
• Quality review
• Insertion into code
• Localization testing
Again, I just want to share a little more detail on each of these in turn.
I recommend putting plenty of time into choosing the right localization platform to meet your needs. The right platform can help the software localization process to run smoothly and painlessly.
Using a localization platform with integrated translation providers is always a good approach, as you’ll have linguists on hand who are experienced at using the platform. This can save you time and help to assure the overall quality of your translation.
It’s worth finding a platform that supports multiple source formats, as this can provide you with some much-needed flexibility. Look for platforms designed specifically for developers, as they should offer additional features. A decent editor is also useful.
I suspect this is the point at which you’ll feel like your software localization is really getting underway. You’ll need to extract your resource files in one of the formats supported by the localization platform and then upload them to it.
Using a localization platform with one or more translation agencies integrated into it means you can have instant access to the languages that you need. Translators should be native speakers of the target language with significant technical experience, as well as superb linguistic skills.
If you prefer not to use an integrated agency, most platforms make it easy for you to bring in your preferred translation team. In either case, your translators will translate the source strings within the localization platform’s editor. You should be able to take a top-level view of progress throughout the translation process.
I advise you not to insert anything back into your code until it has been through a quality review. This will assess the accuracy of the translations and provide the opportunity to make any required corrections.
A translation project manager can come in very handy here. Again, you can either use one available through the localization platform’s integrated resources or else build your own into the process.
Once you’re happy with the quality and accuracy of your translations, it’s timed to insert your localized strings back into your code. You should just be able to pull them from the localization platform, then import and deploy.
As with any software changes/updates, you’ll need to test, test and test again to make sure everything is working as it should be. Be sure to test every localized version to try and catch any bugs or errors, whether in language, layout or any other element of the user experience.
As a general guide, your localization testing should incorporate the following stages:
• Build verification testing. This tests the basics of your software to ensure it’s ready for more intensive testing.
• Analysis and test planning. This is where you map out your testing plan and process.
• Initial testing phase. This step examines your content and UI in detail, with any errors logged.
• Using test cases. This is where you look at specific use cases for your software. The more closely they can mirror real interactions, the better.
• Regression testing. If the functional testing discovers a bug or defect, fix it and then regression test it to check that the bug has been fixed and nothing else has broken in the process.
• Report. Document your findings for future reference.
You can click the link below for further details about localization testing.
Read more: What Is Localization Testing?
Naturally, you’ll want your software to be the best that it can be, no matter which language it’s used in. As such, I thought it worthwhile to include a couple of advanced software localization tips that you can implement as well.
Local user testing involves taking a significant sample size of the specific locale to test your software. It’s a process that can be immensely helpful, with users providing feedback on the UI and UX in particular.
This is a really fast way to pinpoint any particular regional issues. You can also use local user testing to home in on specific demographics and user behaviours, which can provide some valuable insights.
There are various localization tools and other relevant tools on the market that can help you to scale up your operation faster and more efficiently. Some of the best localization tools are the platforms themselves, but there are also computer assisted translation (CAT) tools, file management and sharing tools, glossaries for specific industries, localization testing and quality assurance testing tools, translation management systems, screenshot tools and more.
The particular combination of tools that you need will depend on your approach to the software localization process.
There are various ways that you can tackle the software localization process. Incidentally, the same is true of website localization – you can read more about that by clicking the link below.
Read more: Website Localization – The Complete Guide
By far the easiest way to handle your software localization is to hire an experienced professional to manage the process for you. Such individuals combine both technical and project management knowledge in order to deliver software localization services that take the pain out of the process. They come armed with all the tools and resources you need, from localization platforms to translation teams.
If you prefer to take a more hands-on approach to your software localization, then the wealth of tools available means that you should be able to do so without any undue difficulties. I just recommend making sure you’re researched each part of the localization process in plenty of detail, so that you can be confident you’re not wasting time/energy/budget as your localization work proceeds.
I hope this guide has been of use to you. You can always check back against it when you need to brush up on any of the key points:
• Software localization definition
• Why you need software localization
• Key factors to keep in mind
• The software localization process, including both internationalization and localization
• Localization testing
• Different software localization approaches
Post your Comment