Translation of software (or software localization) has a few quirks that you need to take into account in order to achieve a software project that’s top quality in every language. This is vital to ensure that all users have the same experience, wherever they live and whatever language they speak.
1- Format of the files:
The first thing we need to do is convert the files that contain code and strings of text. You should use a format that can be processed with CAT (Computer Assisted Translation) tools. These tools protect the code, so that the translator can solely concentrate on the translation of the strings.
One of the formats that’s often used and works really well is xliff (XML Localization Interchange File Format). This a format based on XML and created to standardise localization. It contains a lot of the information necessary for the correct translation of the strings, which are normally translated out of context.
2- Information that developers have to add:
Xliff files have to include a series of tags with information that’s important for the correct translation of the strings. This information would have to include the following, as a minimum:
- Maximum length of the string. This will avoid clipping once it’s translated. If the source language is English, translations normally take up about 30% more space, depending on the language.
- Status of the string. The translator should know if it needs translating, revising, or modifying.
- An explanatory note. Information about the string and where it will appear (whether it’s a button, a menu title…)
3- Screenshots of the original:
Strings are normally sent out for translation out of context. Although developers add information in labels, it’s important for the translator to have access to a screenshot in the source language. That avoids lots of mistakes further down the line and helps to improve the quality of the translation.
4- Validation of the final translated software:
Once you have the files translated and converted back into the original files, there’s one last step: the validation of the translated software. You can do that by using screenshots or the software itself and sending it to a professional translator. You will then avoid errors in length (strings that are clipped), errors in context (strings used in more than one place that should have been translated differently in each case), and errors in genre (when, for example, variables are used).
5- Documentation that accompanies the software:
If there’s any documentation that goes along with the software (help files, user manuals…), it’s important that you translate strings first. You should then create a translation memory (TM) or terminology database, and afterwards translate the documentation using this TM. You will then have all references to the software itself translated correctly in the documentation.
Translating software isn’t an easy task, but if you take these points into account then the end result will be far better, and customers all over the world will have a better user experience.
Written by LocalizationLab