A key prerequisite to creating an internationalized core code base for your program is that all language editions share the same core source files. Maintaining separate source files for different language editions of the same product is error-prone, a waste of time and disk space, and unnecessary for code that is properly internationalized. Your code will be slightly different for some language editions, because some languages, like those used in the Far East or the Middle East, require extra processing. If you are using the C programming language, you can manage these differences by using #ifdefs carefully and sparingly.
When you have shipped or are close to shipping your domestic product, you might decide to make a copy of your current source files and set up a separate development project for the next product revision. In such a case, you will need to pass bug fixes to the new project and incorporate updated code or features into the old project for international editions that have not yet shipped. When the schedules for your international releases overlap with the schedule for the next product revision, you might be torn between your desire to take advantage of improvements and your desire to ship to international markets on schedule. Obviously, you have to use your best judgment in these situations.
Just as all language editions should share a single set of source files, all language editions should share a single bug database or bug-tracking system. Many bugs will be common to all language editions, but bugs that appear only in non-native editions can reveal internationalization design flaws. Those responsible for testing certain features in native editions should also be responsible for testing the same features in the international editions. It's a good idea to have dedicated test scripts for localized products and help from native speakers to test certain features, but the most successful philosophy is that of one product, one team.
As you start a new project, be sure to select tools, such as editors and compilers, that will help rather than hinder internationalization. If you plan to write customized build tools or design your own resource-handling mechanisms (instead of using Win32 resource files), first consider what effect they will have on your international editions. If you must write your own build tools, internationalize them the way you would your main executable. The mechanics of selecting a directory structure for your files to handle those parts of the code that will change from language edition to language edition is discussed in the next section, "Isolating Localizable Resources."