Agile programming impact on software localization

Localization with AgileWe 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 (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 both schedule and quality perspectives! For more info, refer to Software Localization details on our website.