| In this situation, one binary or set of binaries meets the requirements of all users, regardless of language or geographic location. One team develops, compiles, and tests a single source, with no conditional compiles. The text language either is bound into the one executable or is user-callable from separate language DLLs at runtime using LoadLibraryEx( ). Code that is required by all users in some regions is either built into the main EXE or is installable from DLLs at user options to conserve use of memory or diskspace. Single worldwide binary offers the following advantages: The single-binary model works great with most localization tools. Although the tool was designed initially for no-compile localization, resulting in separate EXEs, you can also use it to edit language resource DLLs, which can be called from a common worldwide EXE. Testing is easier to unify into one team. Bugs are tracked and fixed once, including those resulting from UI language changes. Data interoperability between languages becomes obvious to the development and test team, as it already is to many users. Single-tree source maintenance is easier. Also, there are no conditional compiles for international and no code propagation. A single worldwide binary fits well with the movement to electronic product distribution, which moves the world to a geographically independent model. This model offers the best flexibility for users, which is a tangible benefit you can use as a competitive advantage. Consider what this means to multinational corporations and MIS, certifying and installing one product worldwide with a UI language based on a user's install choice or login. Product delivery has the option of managing SKUs separately by locale, or as a single project all the way to shrink-wrap product delivery worldwide. The original development group can easily check consequences of translated strings. The language DLL approach is extensible. (This applies to applications and other high-level products that can rely on GDI.) You can add additional language DLLs later, provided that you develop and test a core set initially to check consistency. This reduces some pressure on ship deltas for second-tier languages.
Disadvantages of single worldwide binary are as follows: The binary size is larger, depending on the method (all languages are stuffed into EXE or callable DLLs) and type of code, such as low-level code with rudimentary messages versus UI-intensive application code. File formats are larger. The perpetual question, "Won't Unicode double everything?" is actually not the case, since even rudimentary compression can pack out the null characters from Unicode data, and raw Unicode data is not much bulkier than raw DBCS data. But there is measurable growth in file format. Advanced planning and careful management are required. There's no room for afterthoughts or special requirements based on locale. Either it all fits the original specs, or you'll have to wait until the next revision.
It's safe to say that method 1 is least efficient, and method 4 is most efficient. Many products outside (and some inside) of Microsoft fall between methods 2 and 3. Method 4 is the preferred method. The more advanced teams, such as Windows and Office, use it. Microsoft Sidenote: Localized Builds for Windows XP Most Microsoft products are a complex mix of new and old code, shared components, and sometimes parts licensed from other companies. Some products might use a combination of all four methods. The Windows team tends to follow the last method throughout its code, and, when integrating new components, requires that the guidelines discussed next are followed. English and localized versions of Windows XP are generated from the same source code, except for a few operating system loader and setup binaries that are running before any globalization features of the operating system have been loaded. The localized versions of the binaries are transformed during a process applied to the release build of the English version. The build lab compiles the source code with the English resources and creates the English Windows Build. After verification, the build is released to manufacturing and to localization teams. The localization teams extract the resource portions from the binaries, translate the tokens, and test them before returning them to the build lab. There they replace the English resource files. The build lab creates localized INF files, which contain install sections and a strings section. Install sections contain the logic for installing software and use strings that are defined in the strings section. The strings section contains localizable strings that can be displayed to the user during setup. With exceptions to a few setup INF files, the build lab just attaches a localized strings section to a template INF file that contains only install sections. After the build lab has these files, it compiles the specific binaries for the localized version, thus producing a localized version. This represents great progress from the early days of Windows, when many core binaries had to be recompiled to generate localized versions. The fact that only resource sections and INF files change now means that the executable portion of Windows XP is world-ready. |
|
