I18nGuy Home Page

Internationalization Club Rules

 Fight Club RulesInternationalization Club Rules
1You do not talk about Fight Club You MUST evangelize internationalization
2You do not talk about Fight Club You MUST evangelize internationalization
3Someone yells stop, goes limp, or taps out, the fight is over Internationalization is architecture. Accept it wholly.
Localization on the other hand, is a business decision.
4Only two guys to a fight For coding purposes, all markets and languages are equal.
5One fight at a time Unicode is a must-have.
6No shirts, no shoes Unicode is not internationalization. There is more to it.
7Fights will go on as long as they have to Test I18n functionality.
8If this is your first night at Fight Club, you have to fight Everyone participates, no exceptions.
You do not need to speak, read or write other languages to exercise, code or test i18n.


#3: Ignore debates about which languages will ship with a release. Internationalization is designing for all markets. The decision about which languages to localize for or which markets will be shipped to, is a business decision that is independent of internationalization, and can come later in the development schedule.

#4: Don't treat your native language as special. Treat it as just another locale.

#5: Unicode can be either UTF-8, UTF-16, or UTF-32.

#6: In addition to supporting the Unicode Character Standard, internationalization requires support for native data formats (date, time, number, currency, etc.), time zones, measurement systems (page size, inches vs. centimeters, etc.), legal requirements (export restrictions, age limits, content restrictions, etc.). For more information, see I18n Checklists.

#7: I18n testing includes exercising international functions and configuration settings and using international data. Pseudo-localization is a good technique for testing that the user interface is localizable.

#8: All developers should be responsible for writing international code and unit testing. Having a special team retrofit code to internationalize it, is costly and error-prone and not sustainable over the long haul.
All testers should write tests that use international data. It wastes development and execution time to create duplicate tests with international data.