The design process will generally begin with your specification, in which you identify all criteria that will help bring about world-readiness. The general categories to consider when writing your specification include globalization, customizing features, designing a user interface (UI) that's localizable, legal issues, and accessibility of features. Each of these areas is discussed in more detail throughout the remaining sections of this chapter.
More specifically, your team's specification should address factors affecting your ship dates, such as staffing requirements and the scheduling of milestones for coding, translation, and testing. In addition, the members of your team who are writing the program specification need to know and specify in advance which languages and locales the final product is targeting and to what extent each language edition will actually be translated.
Also, when describing the appearance and functionality of new features, the team should be sure to address internationalization issues in the specification. Some examples include whether certain features will be removed or customized for different editions, and whether a feature's behavior must be locale-aware. For instance, 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 specification 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. (Country-specific formats for addresses, currency, date, time, and other information can be found in the appendixes of this book and on the accompanying CD.) 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; you can avoid them by working from a solid, world-ready specification.
Some of the areas just mentioned that you'll need to consider when developing a world-ready specification-for instance, specifying which languages and locales the final product is targeting-overlap with tasks associated with globalization. This makes sense since focusing on globalization issues, once again, is an integral part of writing any specification that's world-ready, as discussed in the next section.