i18n would cover a lot of things like the following: - Using Unicode for UI-visible string functions (to make it possible at all for your app to show non-Latin

i18n would cover a lot of things like the following: - Using Unicode for UI-visible string functions (to make it possible at all for your app to show non-Latin characters). Other some other means of selecting arbitrary charsets but Unicode is hard enough as it is. - On that note, using language-specific instead of byte-specific functions. This itself has its own large pitfalls (e.g. even something as simple as using foo.toUppercase() instead of foo.tr('a-z', 'A-Z') simply doesn't make sense in all languages, but at least it's better than what you had before). - Having hooks for displaying dates in the user's preferred format. - Advanced mode: Having hooks for operating on dates in a non-Gregorian calendar! - Having hooks for proper currency handling and display. - Having hooks for properly translating pluralized words. This is way worse than it sounds. In English you generally have "1 of", "none of", and "2+ of" that you might have to worry about, but other languages may have significantly more options, or entirely different ways of binning which categories an ordinal phrase falls into. - Having hooks to supply "context" to a translator. E.g. talking about an "elevator" in the context of choosing an I/O scheduler may give an entire sentence a far different structure than using the same word "elevator" in the context of vertical transportation. - Speaking of context, there's the problem of properly handling placeholder text in printf-style format strings. The translators may have to re-order the placeholders entirely to get it to translate right. Even this is just kind of scratching the surface, I haven't talked about things like graphics, audio, etc. Now, l10n is the process of actually going through and making the changes needed for a given locale. This doesn't just mean language, it can also include regional aspects. E.g. Brazilian Portuguese (pt_BR) may end up with a different appearance than Portugal's Portuguese (pt_PT) [1]. Even American English (en_US) and British English (en_GB) have famous differences which go into far more than just s/truck/lorry/, but into things such as units (even gallons are not the same). All of which must be handled to have a proper localization. In code terms you might say that i18n is refactoring to have a proper interface for usage by subclasses, while l10n is the art of making a specific subclass for that i18n interface for a given regional locale. [1] http://lists.debian.org/debian-i18n/2005/10/msg00077.html http://lists.debian.org/debian-i18n/2005/10/msg00077.html