While working on a software localization project recently, I couldn’t help thinking about the same—and sadly, unnecessary—challenges that keep reoccurring in this type of projects. That also got me thinking about ways to eliminate them. And here is what I came up with.
The Main Problem with English to Russian Software Localization
Typically, the main challenge is working on a list of the GUI (Graphical User Interface) items extracted into a standalone document, fully detached from the actual software. As a result, you only see the name of a GUI item, but can’t see its actual location in the software, which is critical since Russian translation of a GUI item often depends on its location.
Example of Different Translations Depending on Location
I’m using an example based on English to Russian translation:
View – Показать (context menu command)
View – Просмотр (user’s read-only right to open files)
View – Вид (menu name)
I’d love to have user manuals or help files for reference every time I work on a software project. But although they are extremely important for understanding what the software is all about, such reference materials are usually hard to come by. If you’re lucky, you can find some of these on the Internet, provided that this software is generally available, i.e. not custom-made.
I’d also love to get my hands on the final localized software for testing purposes each time I’m involved in a localization project. But there is actually just a handful of programs that I can remember receiving for testing.
Ideal Localization Process
Since we are at the bottom of the translation supply chain and aren’t involved in any decision making, these challenges are something we need to accept and adjust to. So the process below is my dream process and not how we actually do it:
- Preparing content for translation: We can prepare content at our end or let our client do it. The main idea is to provide the GUI in a way that makes it a possible for a translator to see the context. An example is providing each GUI item with a comment that explains what this item is and does.
- Localization: Our client provides either the software or screenshots together with a user manual and/or help files for reference. We have enough time to review them and achieve good understanding of the software. This will help eliminate mistranslations and literal translations.
- Software testing: Ideally, we test the localized software before everyone else does. Next, a subject matter expert at the client’s end also tests the software. Our task is to check whether each translation fits the context while the customer’s expert is responsible for reviewing our work to make sure we didn’t misunderstand something.
- User manual and help file translation: It’s best to translate these two together since user manuals and help files are often similar. It’s also important for us to be able to change any GUI items at this step if we find this necessary because translators often find errors in the previously localized GUI items when they work on the manuals. That’s because the new context helps look at a GUI item at a different angle.
- Before translation starts, your translation services company should have all important reference materials related to your software since this has a direct impact on quality.
- We strongly recommend to avoid completing the above steps in parallel since quality and price might take a hit.
- Avoid finalizing anything while localization is still in progress. Even at the very last steps, you may find errors overlooked at an earlier step.