We were recently contacted by a client who asked a question that hits at the hear of agile software localization. He asked the following.
“We are reviewing our GUI localization plan for next release. We’re 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 these types of questions.
Agile Software Localization File Prep Process
The file prep process is easier to handle when the client provides the GUI strings externalized. Usually because it 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. Additionally, the tools that are used to externalize the strings have to be very accurate. Otherwise, they may unintentionally miss strings embedded in the code.
Translating Strings Out of Context
When strings are externalized, it will be more difficult for the translators to properly understand the context that surrounds them. This makes accurate translation more difficult to achieve. For instance, the string “Save” can refer to registering a file, economizing or rescuing. With insufficient background information, the translator is forced to query the client’s resident expert to get the intended meaning. This will lead to uncertainty and delays in the translation, leading to an incoherent agile software localization process.
Missed Strings for 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.
If you are to externalize strings, externalize all the strings and highlight the ones that have changed or need translation. This may give sufficient context to the translators to perform the translation work accurately.
The translator can also check to make sure that all the non-highlighted strings are already translated and stored in the translation database.
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.
Impact on Localization Costs
As far as the impact of agile software localization on the 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 (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 is required.
By minding the minimum 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 both schedule and quality perspectives. For more info, refer to the agile localization process details on our website or contact us for a free consultation.
Whitepaper: Does Your Product Speak Your Client’s Language?
To succeed in today’s economy a company needs to broaden its horizons and think globally. This is exactly why a product localization strategy has to be as tactically and strategically important to the company as its global vision. Based on a real life case study, this whitepaper discusses how localization can be an awesome opportunity, and why we believe that “The language of business is not English, but the language of the customer.” Request this whitepaper now!