I18N
From APIDesign
(→Localizing Output) |
|||
| Line 9: | Line 9: | ||
== Localizing Output == | == Localizing Output == | ||
| - | On the other hand, [[L10N|localizing]] an [[API]] is probably not [[good]] idea. [[ | + | On the other hand, [[L10N|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: | ||
| + | |||
| + | <source lang="bash"> | ||
| + | LANG=en_US | ||
| + | </source> | ||
| + | |||
| + | 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 [[L10N|localized]] form) with [[API|application programming interface]] which needs to be as stable as possible! [[L10N|Localizing]] [[API]] is general bad idea! | ||
[[Category:APITypes]] | [[Category:APITypes]] | ||
| + | [[Category:APIDesignPatterns:Anti]] | ||
Revision as of 07:41, 31 May 2015
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 for one API type. Moreover the L10N is done on a different schedule. The code 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_USat 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!
Follow
