We were recently contacted by a client who asked the following:
“We are reviewing our GUI localization plan for next release. We are thinking of creating an internal tool to provide us with a list and location of changed GUI strings in more frequent shorter intervals. We then could provide the changed string file to you and once it’s translated, get the translation back and include in the next build for reviewers. This process allows us multiple build and review cycles and earlier availability of final localized version for our users.
Do you think providing you with smaller amount of string changes in approximately two-weeks intervals would be easier to get the translation done? How about the cost, is more frequent smaller work translates to less cost or more?”
We’ve dealt before with the requirements that our client here presents with software publishers that apply the Agile process in software development. Here are the answers to his questions:
The file prep process is easier to handle when the client provides the GUI strings externalized as this will not require the localization team to parse files to identify where the strings to translate are. However, performing the translation is harder when the strings to translate lack sufficient context, and the tools that are used to externalize the strings have to be very accurate so that not to leave any strings unintentionally embedded in the code.
When strings are externalized, it will be more difficult for the translators to properly understand the context that surrounds them to be able to apply the correct translation. For instance, the string “Save” can refer to registering a file, economizing or rescuing. With insufficient background information, the translator is forced to send queries to the client’s resident expert to get the intended meaning. This will lead to uncertainty and delays in the translation.
Also, strings not externalized correctly, will result in mixed language strings, source and target, showing up in the localized version. See Do’s and don’ts in software development before product localization. Tools to be used have to be properly implemented and tested before they can be fully used or trusted.
Furthermore, additional quality assurance will be needed by capable native users to ensure that the translation is correctly applied within the circumstance of the application at run-time.
As far as total localization costs are concerned, it is a wash. As long as the client keeps the increments at or higher than 300 words per language (please note that most localization companies apply a min fee per language on small jobs), the translation costs will be lower for the following reasons:
1. No file prep is involved,
2. No leveraging of previously translated strings will be required.
By minding the min fees, translation costs can be significantly reduced. However do expect higher costs for localization QA to allow for necessary fixes in the translations and the higher number of QA iteration cycles.
Overall, GUI elements of a product do not often constitute the dominant localization effort. Significant costs amass typically with the translation of the help and manuals. We tell software publishers to pursue the GUI localization process that best meets their end needs from a schedule and quality perspectives!
4 Comments
One of the issues I encounter when localizing or QA testing is the use of the same string for different contexts. It’s the lazy developer’s way of cutting down on strings, but it shows a lack of preparation (ie, internationalization) of the software prior to its localization into one or more foreign languages. How is this best handled?
Hi Mario, translators can be creative in addressing some of the problems, but often the only clean solution is to fix the source code. This is why the software developer should not be entirely removed from the process, and a mechanism should be in place to permit re-leveraging translations into fixed or updated GUI source files.
Some of the topics you mentioned in your post are not related to agile development but to software localization in general.
When reading this article several questions came into my mind: Why does your client is thinking of creating an internal tool to provide you with a list and location of changed GUI strings? Specialized visual software localization are meeting all these requirements: Automatically detecting changed and new text strings between two software versions and pushing these text strings to the translation vendor, of course including the GUI context. These processes can be integrated into automatic built server environments. So no need to think about a file prep process, missing context, or identifying translatable strings.
The externalization of software strings as part of the internationalization of a software is not related to agile development processes. It must be done anyway to ensure a proper and successful localization. Software manufacturers are usually testing the localization readiness before sending a package to a translation vendor. When implementing agile development processes these basic internationalization tests should be part of each sprint. This objection is also true for quality assurance. A (translated) software that is released to the client should be tested regardless which development method you are using.
The interesting questions are related to the costs, but it’s not only about min fees of translation vendors. First of all software manufacturers must evaluate if the implementation of agile localization processes are economically worthwhile. Some useful answers were presented at the Localization World 2010 in Seattle in the session “How Do We Create an Agile Localization Process That Can Keep Up with an Agile Development Process?”.
Regarding the localization costs the software manufacturer will decide if it makes sense to localize a small drop. In long running agile developments I assume that preferred translation vendors will be used that already localized the last drop. It’s up to the software manufacturer to negotiate whether a min fee applies or not. Maybe there are also good reasons to rethink the business model between software manufacturer and translation vendor. The session “Continuous Workflow” held at the Localization World 2008 in Berlin has presented a new approach and its results.
I’m personally interested to get in touch with software manufacturers to discuss their experience with agile development and software localization.
Hello Achim, thank you for your thorough comment.
GUI Localization tools have been around for years and they can be helpful when they correctly handle the file formats in question. We used them and know their strengths and limitations. At times, they don’t handle all the file formats that clients require. Many also rely only on the top-down localization process requiring leveraging old translations into new files each time they are used.
With Agile programming, development groups are building code at times as often as once a week. Leveraging translations on a weekly basis using these tools can be time consuming, or error prone if done hastily.
Furthermore, quality assurance time is usually not proportional to the change in the code. There are mandatory steps that need to take place with each build regardless of the number of translated strings. Agile development teams should weigh-in QA time needed not only for the source language, but for all target languages if they seek simultaneous releases.
GlobalVision has many processes in place to help our clients address the localization of GUI files produced by Agile development. Each client however has their own needs and requirements. Although the high level issues presented in this blog may be the same, one process or tool, will not fit all.