Software translation is no easy task. It involves more than language skills. While it’s not easy translating words precisely by looking at the context, it’s more difficult to translate ideas and instructions if you lack technical understanding. So how do software translations work?
Presented below are the basics of how software translation works. To clarify, this article is not about translating software from one programming language to another, like converting an Android app into one that works for iOS devices. The focus here is on making a software understandable to users who use different languages.
This is part of our localization series. For a more comprehensive look into localization, please go to our Ultimate Guide to Localization.
Forming the Translation Team
Depending on the size of the project, one software translator may be enough (for small apps) or a team composed of several members may be required. The translators should have two major qualifications:
- Expertise in the source and target languages
- Knowledge in the programming language used in the software to be translated
It’s not essential for the translators to be an expert in the programming language used. What’s important is that they know the fundamentals. For example, they should be aware of changes that can affect the software code. There could be strings they unwittingly insert that would cause parts of or the entire software to malfunction. The translations or the use of certain characters in some of the code strings may change the way the software works. They need to be knowledgeable in these things so they don’t translate what shouldn’t be translated and easily track their work to correct errors arising from the changes they implemented in the code.
How do Software Translations Work?
Software translation does not work with the client simply submitting to the translator the different texts they want translated. Well, in some cases it may work that way. Some clients may just ask for translations for specific texts and integrate the translations to the software code on their own. In general, though, companies that offer software localization solutions should be technically adept that they can integrate the needed translations in the code itself.
Many translation teams involve translators who work remotely instead of hiring in-house translators on a permanent basis. This is the most cost-efficient way of doing things as having permanent translator employees to become experts in different languages (for both communication and programming) is going to be very costly. It also does not make sense having in-house polyglots with programming knowhow when the software localization projects involving different languages tend to come at the same time. You cannot assign them to work on different projects at the same time. Hence, it’s better to outsource the translation tasks to programming-savvy translators in different parts of the world whenever the need arises.
Several translators for different language specializations may be hired. Software developers or publishers may target different regions so they need localization for more than one language.
Evaluating the Software
The first step in doing software translation is the examination of the software to determine the parts that must be translated. A client may specify which parts to translate, but an experienced translation company should be able to help the client in pointing out everything needed to achieve optimum localization.
Some clients may be satisfied with the translation of major texts such as the end user license agreement (EULA), the Help file, and the texts on the user interface, missing the need to translate other important details.
Here’s a list of the parts that need to be proficiently translated for the best localization results.
Window Titles
These are the texts that appear on the topmost part of a software window. They need to be translated unless they are proper nouns or they indicate a unique name for a window or interface in the software.
These are the main navigation buttons of a software. In Microsoft Word, for example, these are the File, Save, Save As, Open and other options on the top part of the main software window.
Dialog Boxes
As the name infers, these are small boxes that appear on screen whenever the software needs inputs from the user. It is usually provides two options (Yes/OK or No/Cancel/), but also presents other options depending on the action the software is about to undertake.
End User License Agreement (EULA)
It is like the terms and conditions of a software but presented in a form of a contract. As such, it binds users to the limitations and uncertainties of the software. It’s only logical that this should be accurately translated.
Help File
Also known as the software documentation, this is a file that serves as the software manual or reference. It presents the different functions and features of the software. In Windows, it is the file that appears when pressing the F1 key.
Status Messages
These are similar to dialog boxes but don’t require interaction. They simply present a status such as the percentage of download completion.
Error Messages
Just like status messages, error messages present information on something that went wrong, usually an error code plus a brief description. These are messages that appear when the cursor or mouse pointer is made to hover on an icon, button, image, hyperlink, or other element in a GUI.
Readme Files
Many Readme files (especially in small games) only present messages or instructions from the software developer, but they are generally intended to serve as a supplemental documentation. The provide details about other files in a directory or archive.
Texts in Images
Some software include images that contain the texts, and are vital in understanding commands or the messages in dialog boxes. As such, they should be translated. They are not contained in resource files but saved as .jpg, .png, or .gif files, so an image editing software is needed to modify them.
Most of the texts software users see in the user interface (menus, texts in dialog boxes, status messages, etc.) are stored in a collection of files referred to as resource files. Only translators who have some programming knowledge should be allowed to make changes in these files. Otherwise, words that appear translatable such as font names may get translated, causing changes in the way the software looks or works.
Establishing References
To ensure consistent translation, it may be necessary to come up with a list of references or dictionaries to be used by the translators. The client may provide a style guide as well as a list of terms that should no longer be translated as they are already understood by users in specific target languages. The translations should be comparable to how the software is presented in other literature or media. For example, the term driver (software that allows operating systems and other programs to access hardware functions) in French is usually written as “le driver,” but it can also be translated as “le pilote.” To avoid confusion, there should be consistency – only one term should be used across all translations.
The Actual Translation Process
Once the goals and parameters of the translation project are set, it’s time to start the actual translation phase. The entire process is comparable to how video game translation works. Everything passes through a meticulous process. The localization service provider should employ a multi-step translation process that involves initial translation, editing, and proofreading stages. The translators may be working with resource or binary files here. In some cases, they have to work with graphics, audios, and videos.
After the translation-editing-proofreading stages, the output is sent for quality analysis. If there are issues found, corrections are made and another round of quality analysis is undertaken.
Once everything is ready, where applicable, the back conversion stage follows. This is when files are converted to their original or intended format. For example, if the software audio or image elements also had to be translated, they are converted to the format the client needs. Everything is then finalized and sent to the client.
Resource File vs Binary File Translation
Translators may work with resource files or binary files. Resource files, as mentioned earlier, refer to the individual, non-compiled files that contain software code strings that can be edited by the translators using a text editor, resource editor, or computer-assisted translation (CAT) tool. Binary files, on the other hand, are compiled program files that can be edited using special tools like Binary Editor.
Working with resource files can be quite challenging as it is difficult to keep track of all the translations made. The translators can’t see the results of their translations on the user interface. Also, there’s the possibility that translators make unwitting alterations on the software code. Nevertheless, there are translation companies that prefer working with resource files since they don’t need to use special editors and costly software localization tools for it. There are also those that do it because simply because they competently can, as their translators have the skills in working with software codes.
Translating with binary files is the easier method albeit requiring special editors or tools. WYSIWYG localization tools may be employed to do the translations. With these tools, unwanted modifications in the software code are avoided. Additionally, context information can be viewed in the binary files.
The Final Output
The final output that will be sent to the client depends on what the client wants. A new language version of the software or the edited resource files complement the translations. More capable language service providers that have programming-savvy translators go above and beyond translation. They also implement changes or additions in the software code, integrating a language selector in the software’s graphical user interface. This ensures users can select different languages when they use the software.
Need software translation? Allow us to simplify the software translation process for you.
Wrapping Up
A combination of technical expertise and experience makes Day Translations Inc. the best choice for software localization. We have network of translators around the world who are also knowledgeable in various programming languages. These include Java, JavaScript, Python, C, C++, Ruby, PHP, SQL, and Perl. We can competently make your app or software more usable in different countries worldwide. Send us an email at Contact us or call uss at 1-800-969-6853 to arrange the translation services you need. Our lines are open 24/7.
Image Copyright: scyther5< / 123RF Stock Photo