Method 2: Locale-Dependent Source


In this case, the product is broken into separate sources for each locale (such as French Canadian versus French) or major sets of locales (such as Euro languages versus Far East). At some point, a code fork is made, whereby a separate team owns the source dedicated to a locale or a set of locales, with different deadlines and requirements.

Advantages of locale-dependent source are these:

  • End users get the full benefit of correct locale handling for their geographic location or region, including language-content enabling, sorting, and numeric formatting.

  • A locale or set of locales might request special or additional functionality, which separate code can accomplish. (OLE can also do this.)

  • The core product can ship slightly earlier by offloading locale-dependent deadlines to a separate team and code base.

The numerous disadvantages include the following:

  • Users are limited to one locale or language series, which you can't change without restarting or reinstalling the product.

  • Separate source is owned by a different internal team down the hall or across the world, and the result is propagation of source and headcount. Or an external localizer or partner is given responsibility for engineering, which is expensive and a potential security risk.

  • Locale-dependent source defeats the purpose of no-compile localization tools.

  • An increase in ship deltas/delays for other locales from a code fork greatly exceeds the gain in ship date for the "core" release. This has been proven through many past product releases.

  • Bugs reported against one set of sources misses the other, or testing has to be completely duplicated. Ship delta differences might mean that bugs found in one code base are too late to fix in the other. Synergy is lost between code bases. They might as well be different companies.

  • Data interoperability among languages probably has not been thought through. File format interchange is probably not considered between major language differences (Japanese, Greek) or maybe not even among mathematically similar languages (French, English).

This method is not really considered viable because it results in a source tree management nightmare.



The Build Master(c) Microsoft's Software Configuration Management Best Practices
The Build Master: Microsofts Software Configuration Management Best Practices
ISBN: 0321332059
EAN: 2147483647
Year: 2006
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net