A resource bundle typically contains all display strings and messages used by the adapter at runtime and at design time. A resource bundle is also specific to a particular locale. Resource bundles enable you to internationalize an adapter quickly, without having to change any code in the adapter. For more information, see Creating Resource Bundles

Adapters may also make explicit use of a resource bundle to localize other data, such as resource domain values, especially if those values are known at development time (for example, a list of known record status values). (For more information about resource domain values, see Populating Resource Domains with Values.) In those cases, the strategy for key composition is left to your discretion. However, be careful when a value that was localized needs to be understood at other points in the code (for example, if (this.getStatus() != "active")).

For example, suppose an adapter service includes a metadata parameter called status, which can be set to a value of active or inactive, and that these values should be localized so that active and inactive appear in the language of the current user. If the run-time locale might be different from the locale of the design-time client, then the adapter needs to know the language that was used when the value of status was set. So essentially, instead of code that says 'if (this.getStatus() != "active")', the code must say 'if (this.getStatus() != inLanguageOfDesignTimeClient("active"))'. The problem becomes more complicated if the adapter service node is managed (edited) in more than one locale. If a resource domain lookup depends on a value that is localized, and that value was set by a client in a different locale than the current client, then you need to say 'if (this.getStatus() != inLanguageUsedWhenValueWasSet("active"))'.

To support this functionality, the ADK inserts a special metadata property, called designTimeLocale, in each adapter service node and notification node. The value of designTimeLocale is set when the node is created. Adapter users update the value (in the node) when they press the "Reload values from the adapter" button on the Designer toolbar (which appears while users view an adapter service or notification node). An adapter that uses this property can then present resource domain values in the appropriate client locale when the node is created, and understand the value at run time regardless of what locale the server may use. If a Japanese client wants to edit a node that was configured by an English client, the initial presentation in the Adapter Service Editor or Adapter Notification Editor will reflect the English values currently stored in the node. When a user presses the "Reload values from the adapter" button, the server changes the designTimeLocale to Japanese, and performs all resource domain lookups using the new locale. From the adapter user's perspective, all localized values change from English to Japanese. (This example assumes that the adapter includes both an English and a Japanese resource bundle.)

To support localized resource domain values, include the property name ADKGLOBAL.DESIGN_LOCALE_PROPERTY in the resource domain dependency list of any parameter that uses a resource domain with localized resource domain values. Include this property name for any parameters where the lookup depends on a parameter containing localized values, as well. For example:

You must present designTimeLocale as a string (derived from Locale.toString) so the value is made available as a resource domain value. To convert this string to a Locale object, use AdapterUtil.parseLocaleString.

Within the implementation of the statusLookup, the adapter uses the designTimeLocale value provided to access the create a list of localized string values:

At run time, the adapter uses the getDesignTimeLocale method to retrieve the locale, and to interpret the value of localized parameters. For example:

For more information, see the Javadoc for the following: