|Fight Club Rules||Internationalization Club Rules|
|1||You do not talk about Fight Club||You MUST evangelize internationalization|
|2||You do not talk about Fight Club||You MUST evangelize internationalization|
|3||Someone 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.
|4||Only two guys to a fight||For coding purposes, all markets and languages are equal.|
|5||One fight at a time||Unicode is a must-have.|
|6||No shirts, no shoes||Unicode is not internationalization. There is more to it.|
|7||Fights will go on as long as they have to||Test I18n functionality.|
|8||If 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.