I18N

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Localization Team)
Line 7: Line 7:
Still it is clear that [[I18N]] is a [[APITypes|kind of API]].
Still it is clear that [[I18N]] is a [[APITypes|kind of API]].
 +
== Localizing Output ==
 +
On the other hand, [[L10N|localizing]] an [[API]] is probably not [[good]] idea. [[TBD]].
[[Category:APITypes]]
[[Category:APITypes]]

Revision as of 06:31, 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. TBD.

Personal tools
buy