NBI Internationalization and Localization Support
NetBeans Installer's support for i18n and l10n relies heavily on the java capabilities in this area. However, the support is implemented in several layers:
- Engine. Since the engine is an almost pure java application, its i18n support is implemented in a standard way. The engine classes reference strings in the resource bundles, which, in turn, are normal java-style .properties files. The build script supports fetching the localized files from the translatedfiles module.
- An exception to the i18n compatibility are the error messages originating from those rare pieces of native code, that are sometimes used by the engine and/or components' configuration logic (accessing the windows registry for windows, checking for free disk space on all platforms). These error messages are not localized, which should not be a big issue given that they are always wrapped into a more user-friendly exception (which has a localized message) before becoming user-visible.
- Another sub-layer in the engine is the i18n support in the native launchers.
- Windows native launcher is now available as GUI application and have standard localization support. All important messages are stored in normal .properties files. Windows messages that occurs are shown using system locale. Debug messages are not localized.
- Unix native launcher (one for for all supported platforms : linux/solaris/macosx) now goes as the .sh file. That is why the i18n features are not fully supported. We have an ability to use LANG environment variable and show messages from the desired language, but we have no ability to either get the console`s font. Most probably the unix native launcher would allow to show messages in UTF8 or in default codepage but there is no yet final desicion on it.
- As an additional feature, the ResourceUtils class in the engine supports localization of arbitrary files. I.e. if a user requests a resource via ResourceUtils, the facility will first check whether a localized version exists (by attaching locale data to the resource's file name) and if it is available will return a localized veriant, falling back to the default one, if a localized one is not available.
- Installable Components. Just like the engine, installable components are 100% pure java, and their support is no different from the engine's, except for the part about exceptions to i18n support. Generally components are 100% i18n compatible, but the details depend on the component's author. As of 2007/02/09 there no exceptions in i18n support.
- Registry. The entity which needs to be i18n ready in the registry is the XML file which actually lists the available components. The localizable parts there are the various display names and descriptions. The entries themselves also come from the properties files, which are localed at the predefined positions in the components' sources (./data/Bundle.properties for both product, group and feature (as of 2007/02/09 the same location is planned for update)).