I18N

From APIDesign

Has internationalization any relation to API design? That is a question a curious reader of TheAPIBook asked recently. Here is my take on that.

Localization Team

The team developing NetBeans realized that while I18N is responsibility of developers, the actual L10N (e.g. localization) is a task for completely different group. The localizators. The communication between these two groups fulfills all aspects of an API: most of the I18N work in Java is done through PropertyFiles and we already know that such files are example of an API type. Moreover the L10N is done on a different schedule. Developers first prepare the code for I18N and only later the localizers jump on to it to do the L10N - e.g. a sign of distributed development - which is one of the major reasons why people invest in an API. Of course the fault tolerance is usually higher in case of PropertyFiles - if translated property is missing, one falls back to default (English in case of NetBeans) version - the outcome is ugly, but nothing gets broken or corrupted.

Still it is clear that I18N is a kind of API.

Localizing Output

On the other hand, localizing an API is probably not good idea. Classical example is output of various Unix commands like ls, find (yes, format of textual output is also an API). It is often used in bash scripts in a classical pipe/grep chaining style.

You wouldn't believe how many bash scripts get broken when running in non-English locale! Because if the grep invocation seeks for particular format of date, it is going to be different in different locale and then everything gets broken. Of course, the fix is simple:

LANG=en_US

at the beginning of your script, but people often forget. Until one runs in a different locale (and many programmers do not), one does not notice the problem.

This is what one gets when mixing user interface for humans (e.g. the output of ls in its localized form) with application programming interface which needs to be as stable as possible! Localizing API is general bad idea!