Method 1: Internationally Ignorant Code


Internationally ignorant code is not really an intentional method, but it seems to happen a lot, so it is worth mentioning. I usually see this with small companies or groups. It happens for the following reasons:

  • The product is experimental. You can minimize risk and exposure by targeting just one locale. If the product succeeds, you'll need to completely rewrite it anyway. This reason is rare.

  • There's a lack of planning, or taking a focus on goals too literally at the expense of the product's international usability. This is often caused by fear of the unknown, assuming international engineering is so complicated that it must be offloaded as someone else's problem, or confusing international enabling with UI translation.

Advantages of internationally ignorant code include the following:

  • Release to the initial market is faster.

  • Binaries are smaller and tighter (although no smaller than through #ifdef).

  • Text entry/display is possible with other languages that happen to have the same code page.

The disadvantages of internationally ignorant code are as follows:

  • A fundamental rewrite of source is required to take product to other locales.

  • Release in the initial market serves notice to competitors about what to target elsewhere.

  • Text sorting and numeric formatting are broken for other locales.

  • Users do buy products through mail order or while traveling. Users might be sold on the product concept and look for competing products that correctly handle their language. Or users might get frustrated, give up, and be disinterested in the next version.

This is probably the worst type of "internationalizing." Avoid it.



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