I18N
From APIDesign
(→Localization Team) |
(→Localization Team) |
||
| Line 3: | Line 3: | ||
== Localization Team == | == 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 [[APITypes|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 ( | + | 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 [[APITypes|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 [[APITypes|kind of API]]. | Still it is clear that [[I18N]] is a [[APITypes|kind of API]]. | ||
Revision as of 06:29, 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.
Follow
