Are multiple platforms required?

Client/server localization often involves multiple platforms (e.g. servers running on UNIX with clients running under Windows 95/NT, the Web, and/or Macintosh). This creates the need to make the localized terminology as uniform as possible to run cross-platform so that the customer does not have to spend a fortune on documentation. In addition, this also creates the need for numerous QA testing scenarios.

Is all of the code truly internationalized? If not, what does the customer plan to do about it prior to the start of the localization project?

The standard checklist for internationalization compliance should be applied to the client/server arena. The areas to double-check for localization include, but are not limited to, the following:

• Is multi-language support across clients/servers/databases/applications a requirement?
• Are all installers internationalized?
• Are all executables internationalized?
• Are both the server and the client fully multibyte-enabled?
• Are such items as collation/sort, multi-currency support, time/date handling, etc. available for all languages into which the product is to be localized?

Many client/server companies only provide a localized user interface. If this is the case, the product will be hybrid in the sense that languages may be mixed at times on the screen. For example, error messages from the server may appear in English while the user is in the middle of a German client or application. Since this software is not for retail use, this is often acceptable for certain applications in certain markets.

What are the QA requirements?

The QA function for client/server applications is the key to delivering high-quality software on time and within budget. This applies to both the development of the original product, and the localized versions. This area presents the most risks, yet produces the highest payoff if executed successfully, due to the following reasons:

• It is virtually impossible to test every single permutation for all platforms, clients, servers, applications, languages and third-party software.
• It is truly critical to build and run internationalization test suites prior to starting localization. Otherwise, the probability of there being schedule delays increases dramatically. This is due to the interaction between server, client and application code, which often causes a review of several sections of the code before the root cause of a bug is found and fixed.
• As always, local printers and third-party products pose the challenges of (1) procurement, and (2) setup of the proper test environment(s). In-country subsidiaries, distributors and/or Alpha test sites can sometimes come to the rescue in this area.
• Upgrade/compatibility testing is a big challenge for client/server localization. This is mainly due to the large number of possible configurations and to legacy installations.
• Most service providers cannot afford the investment in UNIX machines, so arrangements must be made to share localization testing between the customer and the service provider. However, there is an advantage to this scenario since it provides the opportunity for both parties to quickly resolve issues and more fully test different configurations at a faster rate.

How extensive is the documentation?

The documentation for client/server products is often quite extensive when compared to that of retail software. In addition to user reference manuals for the client, there may be hundreds of thousands of words in the form of programmer’s manual(s), administrator’s manual(s), troubleshooting manual(s), applications manual(s), etc. The format for such documentation may include on-line help, HTML, PDF, hard copy, etc. Most markets do not require localized programmer manuals. Some markets require that administrator information be localized, while some do not. The more text that can be leveraged between the formats, and/or if mini-manuals can be created for certain markets, the less it will cost the customer.

How do applications fit into the equation?

Client/server products almost always include applications that are shipped as an integral part of the package. Depending on how the application is developed, additional internationalization work will probably be needed. Also, the application may require additional work to truly adapt it to a local market. For example, if an application touches on areas such as accounting/finance, legal, or human resources, it will not be enough simply to translate the US version. A strategy for adapting these products for the local legal and financial infrastructure is required. Such a strategy will often involve agreements with a customer’s distribution and/ or development partner(s) to adapt and/or produce these applications in-country.

Summary

The areas which require the most up-front planning and risk management for client/server localization are as follows:

• Multiple platform requirements
• Degree of internationalization required for each section of the shipping code: client/server/database/applications
• International QA requirements
• Amount of documentation required
• Local market requirements for applications

Once there are strategies developed and implemented to deal with these areas, localization can proceed more smoothly.

Rebecca Ray
Remedy Corporation
Senior International Product Manager
1505 Salado Drive
Mountain View, CA 94043 USA
Tel.: +1 (650) 919-5476
Fax: +1 (650) 254-4905
E-mail: rebecca@remedy.com