In Part 1 of this two part post, we looked at the basics of international software, and how to plan your project to best support the demands of international applications. In this second post, we look at using local market knowledge to speed up localisation efforts, the pros and cons of a translation management system, and some ways to avoid mobile app “sprawl”.

Use Local Market Knowledge

Introducing locale-specific requirements early in the product development process will benefits your application in other ways too. Local markets will have valuable knowledge of local events, terminology or idioms which can make the application especially engaging for users in their market.

Regulatory compliance requirements also differ from market to market; again, local markets are best-placed to know these requirements in detail, and therefore by giving them the opportunity to influence the direction of the application early on, you reduce the likelihood of having to re-work the application to support specific regulatory requirements later on.

Local markets are often well-placed to manage the translation activity for their market, using local translation agencies. However, this needs to be integrated into a coordinated translation process.

Manage Translations Effectively

A major headache for many organisations with international web or mobile products is the management of translations across markets. This is typically due to a combination of factors:

1. Ineffective or non-existent ownership of the translation process, from liaising with local markets to collating and tracking translated copy. Without someone responsible for ensuring that translations happen at the right time in the process and with sufficient context, early localisation is impossible, leading to substandard UX for many users.
2. Lack of appreciation of the content and functionality needs of local markets (see The Effect of Grammar on Localisation in Part 1), leading to extra rounds of translation and approval.
3. The high capital and operational cost of a typical Translation Management System (TMS), although these systems can represent value for money in many cases.
4. If a TMS is used, there is an overhead in managing access rights for translators; the nature of the translation industry is that much of the work is farmed out to individual contractors, often working remotely, so keeping a TMS secure is a challenge.
5. In the absence of a TMS, the industry standard for disseminating content for translation is the humble spreadsheet. However, it can be difficult to capture accurately all the source and localised text, particularly when line breaks and other formatting are required, because spreadsheets are designed only to deal with single blocks of unformatted text.

The relative merits of spreadsheets and a TMS for managing translations are summarised in Figure 3:

Spreadsheets have a low upfront cost, and are familiar to translators; and there is no need (or way) to manage security access rights. However, workflow and activity tracking are manual steps, as is the import and publishing of translated content.

A TMS allows for rich text formatting (paragraphs, bold, bulleted lists, etc.) to be retained across localisations, and a TMS can be integrated with a Web Content Management (WCM) system to automate the publishing of translated content directly to web sites. However, access rights management can be complex, and few of the TMS vendors currently have a solution which integrates well with mobile app development; mobile app developers must rely on third-party “app preview” services in order to see how their translated content will appear in the app.

Prevent Mobile App Sprawl

Since the launch of Apple’s App Store for iPhone in 2008, the market for mobile “apps” (software applications downloaded to the phone) has grown hugely. Competitors such as Google (with Android), RIM (with Blackberry) and Microsoft (with Windows Phone 7) have adopted the app and app store strategy, and users seem to love the range of apps and their features.

When creating a mobile app for international markets, you should consider carefully how you will manage the number of distinct versions of mobile apps, with a view to avoiding “app sprawl”. App sprawl is the proliferation of many different versions of the same app, across different mobile devices (unavoidable), versions (also largely unavoidable), languages/locales (usually avoidable) and markets. This matrix of factors is depicted in the following figure:

A simple formula quickly illustrates how the number of apps “in the wild” (released and active on handsets) can get out of control:

Number of apps = platforms × app versions × languages × markets

By eliminating one or more of these variables, app sprawl can be contained.

Currently, each mobile device “platform” requires a separate app (although RIM has recently declared that Blackberry will support Android apps [see note below]). Different versions of the app will need to exist as new features are added; users can be enticed into upgrading to a newer version, but you can expect to have to support at least the latest and the previous versions of the app.

Furthermore, each market may require a customised version of the app, so the simplest way to reduce app sprawl is to support all languages/locales in a single version of the app.

Supporting all languages/locales in a single app version requires you to localise early in the app development process (see Localise Early in Part 1), understanding how different locale needs impact the design and features of the app.

Operational Impact of International Web Applications

Before the i18n and L10n of your web applications are complete, you should consider how the production (live) system will be affected by the new languages, locales and markets to be supported. Languages and locales in themselves do not add significant challenges for the operations team, but new markets – if these are dispersed geographically, and cross several time zones – can require a radical re-think of hardware, procedures and personnel.

Consider a B2B web application which supports English, French and German locales for UK, Eire, France, Switzerland, Germany and Austria markets, and users in all those countries; such an application could reasonably be considered international. Users would be active over perhaps 10 hours a day (covering the time zone differences across these countries).

However, if support for Australian and Hong Kong markets were added, then although no new language is needed (let’s say that English will suffice for both regions), the time zone difference means that the application will now have active users for perhaps 22 out of 24 hours (spanning the business day for all the regions).

The system maintenance window has now been reduced from 14 hours per day to 2 hours per day, simply by adding two new markets. If a new US market were also required, then the system would effectively need to operate on a continuous 24-hour basis.

From an operations perspective, there is large difference between a 14-hour maintenance window and a 2-hour window, and a further leap in complexity from a 2-hour window to 24-hour operation. Anything approaching 24-hour operation requires additional hardware, monitoring, support staff and support procedures to cover both planned and unplanned downtime. For example, deploying a new version of the web application – while keeping the existing application running – would likely require additional servers and would increase the complexity of system testing.

The addition of support for new markets from different time zones to an international web application thus requires careful identification of the impact on operations.

Conclusion

The concept of “internationalisation” as an activity which takes place at the end of the application development process is misguided. Support for international features should be introduced early in the process, and features required by languages/locales and local markets should drive the design and functionality of the application throughout.

Ensure your process and tools for managing translations minimize errors and re-work, and involve local markets early in the product lifecycle.

Understand the impact of segmenting your mobile app versions, and plan for production system changes to support users across multiple time zones.

Android apps on Blackberrys: