Written by Fred Fisher, Software Internationalization Consultant
With the growing popularity of enterprise software and SaaS, the need to localize applications is also on the rise. If you’ve never localized an app before, the whole process can be challenging.
That’s why in this article, we’ll break down the different stages of the software localization lifecycle, including examples, to help you get started on your software localization journey.
In case you didn’t know, the software localization lifecycle is the process that software developers and teams follow to adapt and translate a software application or product for use in different regions and languages.
We’ll talk about…
Initial Localization
If a software application was originally created to support just one language (e.g. English) we need to do four initial localization steps to enable the software to be translated into multiple languages.
Replace hard-coded text with translatable string keys.
Add translatable string keys to a TMS.
Enable language selection in the application.
Include translated text in the packaged application.
Replace hard-coded text with translatable string keys
Many software applications are originally written with hard-coded text in the source code. This means that all users will always see the same text. For example, if the source code contains hard-coded English text, the software will be in English for all users.
To enable the software to be translated into multiple languages, we need to replace hard-coded text with “translatable string keys” which display text in the user’s language.
The process of replacing hard-coded text with translatable string keys is sometimes called “string extraction” or “key extraction”. Translatable string keys are also known as "string identifiers" or "translation keys".
Here's a simple example in code:
Without Translatable String Keys (Hard-coded Text):
With Translatable String Keys:
In the second example, "welcome_message" is a translatable string key. We use this key to select the right text to display based on the user's language.
Add translatable string keys to a TMS
Once we have replaced hard-coded text with translatable string keys we need to add the translatable string keys to a Translation Management System (or TMS).
A TMS is a tool that translation teams use to translate your source language such as English into other languages. The TMS enables translators to work efficiently and easily review each other’s work.
The most important thing the TMS does is to provide translators with context about how the words they are translating are used in the application. So when developers add translatable string keys to the TMS, they will also add context about how the text is used e.g. screenshots. Keep scrolling to learn how Translation Management Systems Help Translation Teams in detail.
Enable language selection in the application
UX designers and developers must build a way for users to change the language of the application. Typically, users will be able to click a button somewhere to choose their language.
It’s also common to auto-detect the user’s preferred language, and if this works well, users will rarely need to select their language manually. For example, if your application is a website, you can auto-detect the user’s language based on the user’s browser settings.
Include translated text in the packaged application
For the application to display text to users in a variety of languages, the application needs to have access to the translated text somehow. The most common way to do this is:
Download files containing translated text from the TMS.
Make the translated text files available to the application by including the files in the “packaged application”.
The packaged application is a collection of all the files an application needs to run including code files and any other files the application needs e.g. image files, video files, and translated text files.
When the software development team decides to release a new version of an application, they run a process called “application packaging”, which creates the “packaged application”.
Therefore, the application packaging process must be modified to download translated text files from the TMS, and include these files in the packaged application.
How Translation Management Systems Help Translation Teams
The Translation Management System (TMS) is a suite of tools used by localization teams to manage the translation process. It is a key component of the software localization lifecycle, providing context and structure, and simplifying translation management.
Here’s how a TMS can help…
Contextual Guidance: A Translation Management System (TMS) provides translation teams with context about the words to be translated, helping them understand how these words are used. This context greatly enhances the accuracy of initial translations. For example…
It groups strings of the same feature in a single place so that translators can see what they’re working on in context. This speeds up their work and reduces errors. For example, all strings related to “sign up” would be grouped together.
It provides screenshots, showing how features look to end-users, so translators don’t need to ask as many questions about how features work and how the words are being used. This means faster turnaround times for new features and better overall accuracy when translating existing ones.
It can provide links to live websites or online design wireframes, which can also help translators understand how a feature works before translating it into another language, reducing confusion and increasing accuracy.
It includes notes describing how the feature works, describing what each software string is referring to. For example, you might have a string that just says "Let's go" and the note could help with the translation by explaining that "This is a CTA that launches the task creation wizard".
Control over translation quality: A TMS ensures that the same standards are applied to all translations. It also makes them accessible for review by a wider audience across the organization. This ensures consistency in style and terminology, which leads to better-quality output.
Streamlined project management: Managers can easily assign work to specific translators, and translators can work on multiple projects simultaneously while ensuring they always have access to up-to-date files and accurate stats about their progress.
Increased productivity: TMS features like ‘translation memory’ allow translators to reuse translated text in another context where appropriate. The TMS might also suggest AI translations for the translators to review, which can sometimes save time and be a helpful starting point.
Popular Translation Management Systems
Several translation management software companies provide tools and solutions for managing translation projects. Some examples include
These companies offer various features and solutions for businesses and organizations to streamline the translation and localization process. The choice of software often depends on the specific needs and scale of the translation project. Phrase is our preferred TMS but we’ve worked with many others in the past, it depends on your business needs and tech stack.
At Undertow we have experience working with many different TMSs and can help you choose the right one for you. As experts in the language industry, we understand how overwhelming it can be when starting on your localization journey, it’s why we pride ourselves on speaking a language you understand without making things more complicated. We connect with you on a “human” level while creating processes tailored to your specific needs.
Language Quality Assurance
Language Quality Assurance (LQA) reduces the risk of translation-related problems causing unexpected delays and disruption to existing project plans - especially if you need to get developers involved to fix a problem that is impacting end-users.
A common example of a translation-related problem is: when translating from English to German, the layout of the user interface might break because German words are generally longer.
If you detect and fix a translation-related problem during QA, there will be little or no disruption to project plans. But if a problem is not detected and fixed during QA, the problem will get into the live application and start impacting end-users.
When end-users are complaining about a translation-related problem and your brand reputation is under threat, the development team must stop whatever they are doing, and quickly release an emergency application update to fix the problem. This is stressful, disruptive, and expensive.
So it makes everyone’s lives a lot easier if you can make the language QA process as quick, smooth, and thorough as possible.
Here’s how it should work:
The translation teams do their initial work based on the context provided in the TMS. Once that’s done, the translated text will be visible to the translators in a draft version of the application that is not yet available to end-users.
The translation team will check if there are any mistakes, and ensure that all the words make sense in the context of the application. As a result, the translators might need to update some of the translations - and developers might need to make some code changes - before the application is released to end-users.
To ensure that nothing goes wrong during this process, we recommend using a separate team of translators for QA to review the translations with fresh eyes. Then, your translations will have gone through multiple rounds of review by different people so you can launch new features with confidence.
What to watch out for
For language QA to be effective, some key requirements should be met:
Translation teams must be able to QA their work before the application is released to the public. Fixing problems before they impact end-users is critical for maintaining customer trust and protecting your brand reputation. It is also much easier and cheaper to identify and fix problems before an application is released to the public than it is to fix problems later - which can be highly disruptive.
Translation teams must be able to QA their work ASAP after they've done the initial translation. Ideally, this should happen immediately after the initial translation work is complete so that everyone involved has fresh memories of what was done and can more effectively verify whether the translations are accurate. If any code changes are needed, it’s also more efficient for developers to make changes while the code is still fresh in their minds.
Translation teams must be able to update translations on their own. It is often necessary to do multiple iterations of translation QA before the application is ready to be released. If the translators can update the translations and then QA the application again without needing help from anyone else (e.g. the developers) the translators can do multiple iterations of translation QA more quickly, reducing the risk of unexpected delays to the application release.
How To Ensure a Smooth Language QA from a Development Standpoint
Pseudo-localization
Making language QA smooth starts with the developers.
Developers can detect layout issues early on by using a technique called pseudo-localization, where the English text is replaced with something a bit like English text, except longer. This way, you can see that the layout won't break in a language like German, where the text is usually longer than in English. Pseudo-localization also includes Unicode characters, so you can check that Unicode characters will render correctly in the interface.
Developers can detect layout issues early by using pseudo-localization.
Developers can also use Google Translate to generate text in German and other languages to test if the layout will break. Testing the user interface with AI translations is generally more realistic than testing with pseudo-localization.
Providing Translation Teams with Context
One of the best ways to improve the quality of your translations is to give your translation teams good context.
This may seem obvious, but providing good context is not always as easy as it sounds. If you're a developer who's never worked with professional translation teams before, then you may not know how much context they need to translate your app properly.
If you do have experience working with translation teams, it can be hard to remember all the details when you're busy working on other things. The most important things to remember are:
Tagging all strings used by each feature enables translators to translate all the text used by a feature at the same time. This reduces the risk that a feature will be released before all the text used by the feature has been translated. It also makes it easier to ensure the feature will have a consistent and coherent user experience.
Screenshots and design wireframes show the translators how a feature works, and how the text is used in the context of the feature. If possible, a video of someone using the feature, or a link to a live demo application where the translator can try the feature for themselves, is also extremely helpful.
Words describing the feature are useful sometimes if screenshots and design wireframes alone are not enough for the translators to have a clear understanding of how a feature works. It’s always better to show translators how a feature works visually than it is to tell them how it works in words, but sometimes words are helpful for additional clarity.
Continuous Localization
Adapting your product development process to support multiple languages.
After you’ve finished the initial work to enable your application to be translated into multiple languages (Initial Localization), you need to adapt your product development process to support multiple languages on an ongoing basis (Continuous Localization).
In the initial localization phase, the developers replaced hard-coded text in the source code with translatable string keys, and then added the translatable string keys to the TMS, along with context about how the words are used.
In the continuous localization phase, you also need to add translatable string keys and context to the TMS whenever you build a new feature. However, product managers and designers will add translatable string keys and context to the TMS, not developers.
If you rely on developers to add string keys and context to the TMS when you develop a new feature, you won’t be able to release features as quickly, because after the feature has been developed, you’ll need to wait for it to be translated before you can release the feature.
This is why product managers and designers should add translatable string keys and context to the TMS while they are designing the new feature before development work has begun. This means translation can happen in parallel with development, so by the time developers have built the feature, it has already been translated and is ready to release immediately.
Once you get into the continuous localization phase, it’s a good time to make the localization process as smooth as possible.
Be careful of extra friction. If you have extra friction in your workflow, it’s like a hidden tax on productivity every day. Over time this adds up to a big loss for the company, and sometimes it generates a lot of frustration and delays.
So it pays to automate as much as possible and to minimize manual tasks.
For the tasks that you cannot automate, you can write documentation. The best way to use documentation is to find a way of sharing it automatically at the moment people need it. If that’s not possible, you can organize training sessions to ensure everybody knows the standard operating procedures.
Before diving into your project, make sure you're aware of the challenges of continuous localization to avoid any unexpected obstacles.
Why relying on AI translations and hiring freelance translators are not enough to complete the Software Localization Cycle
Software localization is a complex process that requires a team of professionals. There’s a common misconception that you only need to translate your software to localize it - but as we’ve outlined in this article - just translating your app is not enough. Therefore, relying solely on AI translations or individual freelance translators to complete the Software Localization Cycle is just not possible.
Translation is just one component of the Software Localization Lifecycle. While AI and freelancers can help bridge certain gaps, the level of technical expertise required for this task surpasses the typical knowledge of freelance translators.
Relying solely on AI and freelancers can introduce additional challenges for developers in the long run, leading to project delays and increased costs. Multilingual support is cumbersome, and this is where collaborating with a localization partner can make a big difference.
Why solely relying on AI translations is not enough
Firstly, AI struggles with context and nuances, which are critical in translating industry-specific terms and maintaining accuracy. Similarly, AI is often trained on extensive models that lack specialized terminology, resulting in less proficient translations. Secondly, cultural sensitivity and adaptation to user preferences are vital for a seamless user experience, a task best accomplished by human translators.
Finally, software localization entails more than just translating text; it involves adapting layouts with help from developers, ensuring legal compliance, and providing ongoing support to ensure an intuitive UX.
Hiring freelance translators vs a localization partner
Hiring freelance translators alone may prove insufficient for effective software localization. This limitation arises due to the complex technical requirements and many moving parts of the Software Localization Cycle:
In-depth knowledge of the initial localization phase.
Proficient grasp of how TMSs work and experience using them.
The demand for rigorous quality assurance.
The necessity of handling continuous updates.
Providing user support.
Ensuring legal compliance.
Maintaining brand consistency, and more.
In summary, while AI and freelance translators have their roles in the software localization cycle, they are not the final solution. They are just one moving part of the localization cycle.
A successful approach to the software localization cycle combines both AI and freelance translators during the translation phase, leveraging human expertise to navigate the complexities of context, culture, and user experience while using AI as a tool to speed up the translation process.
A localization partner would not only hire and coordinate your translators, but project manage the whole software localization cycle from start to finish. They would take full responsibility for each stage ensuring quality and success.
How Undertow Can Help
Are you ready to take your localization efforts to the next level? We hope that you found this article on software localization useful. And if the whole process sounds baffling, don’t worry! Our expert team is here to provide comprehensive guidance and support, ensuring your software localization is a success. Save time, reduce stress, and maximize efficiency with our tailored solutions. Let us handle the complexities while you focus on scaling your business and captivating international audiences. Ready to unlock the full potential of localization? Get in touch!