Identifying Localization Requirements in Specs

The user interface design and the feature set for each language edition of a product might not be exactly the same. Plan for this in advance by identifying required differences in your spec. For example, European editions of Windows 95 do not upport some API calls that Far East editions use to handle the input of ideographic characters. European editions of Windows 95 don’t simply omit these API functions; the spec calls for their entry points to be stubbed so that programs that call them will still run on all language editions of Windows 95.

In addition to describing product features in detail, your spec might also address other factors that will affect your ship dates, such as staffing requirements and the scheduling of milestones for coding, translation, and testing. The members of your team who are writing the program specification, for example, need to know in advance which languages and locales the final product is targeting and to what extent each language edition will actually be translated. When describing what new features will look like and how they will behave, the team should address internationalization issues, such as whether certain features will be removed or customized for different editions and whether a feature’s behavior must be locale-sensitive. What happens if a user enters Cyrillic (Russian) characters? Is it necessary to adjust certain dialog boxes for the Japanese edition? Program designers need to consider such details. If they are not familiar with foreign languages or with the needs of international users, they need to talk to people who are.

If you work for a large company, send copies of your draft specification to marketing representatives and language specialists at international subsidiaries. If you work for a small company, share the spec with overseas partners or consultants. Your partners should be able to point out any glaring errors or oversights and give you feedback on the relevance of proposed new features and designs to their markets. They might forward customer reports, market-research results, and reviews of competitive products from the local press. They should also provide you with locale-specific information your product might need, such as typical postal codes, business letter formats, punctuation rules, and so on. Familiarity with the specification will in turn help your international partners make plans for marketing the product once it is released.

Good planning will help you ship your product quickly. Early feedback on the specification from your team, key customers, usability tests, and market experts will help you determine the best way to implement your features at a much lower cost than the cost of making changes at the last minute. Large-scale last-minute changes in your product design will cause a chain-reaction delay in the ship date of your executable, help files, tutorials, documentation, and marketing collateral—all of which might then need to be retranslated and retested. You never want to ship an inadequate product, but major last-minute changes are expensive, and you can avoid them by working from a solid, globalized spec.