Internationalization Interview Questions in Java

We have compiled most frequently asked Java J2EE Interview Questions which will help you with different expertise levels.

Java J2EE Interview Questions on Internationalization

Question 1.
Elucidate UDDI.
Answer:
The Universal Description, Discovery, and Integration is a database of web services providers that is accessible from within a program and supplies information about the web services available from the provider including information about interfaces to web services. The web services community centers around a group of web-based registries that contain information about each member, their web services, and the application programming interfaces used to access those services. This group of registries is referred to as the Universal Description, Discovery, and Integration (UDDI). A UDDI entry is called a tModel and contains:-

Question 2.
What do you mean by internationalization?
Answer:
Internationalization, also known as I18N, encompasses tailoring content specific to locales based on their different languages, currencies, and formatting conventions. Due to international globalization has arisen the need for software that can adapt to the conventions and languages used by customers in different countries.

The acronym I18N is sometimes used in place of the word internationalization since it is such a long word to type. I18N represents the first letter i, followed by 18 characters, and then the final letter n.

Question 3.
What is Java’s built-in internationalization support?
Answer:
Java’s built-in internationalization support is centered on three main classes. The following table (Table 1) lists each class and its description:-

Class Description
Java.util.Locale Encapsulates the language, country, and variant for a specific locale
Java.util.ResourceBundle Encapsulates locale-specific resources
Java.text.MessageFormat Provides methods for creating locale-specific formatted messages.

Question 4.
How do you internationalize applications using Struts?
Answer:
With Struts, creating an I18N application is easy. If you are willing to pull all the titles, labels, and text messages from a properties file, then you can easily I18N your application. Just create a properties file for each language (locale) you would like to support.

1. Struts attempts to use a properties file that corresponds to the browser language setting. When requesting a page, the browser sends an Accept-Language request header, listing the language preferences. If no corresponding language (locale) is found, then Struts uses the default properties file.

2. Default properties file: To establish a default properties file, use the message-resource element in struts-config.xml. Thus, when you say:
<message-resources parameter “someName” …>

3. The file, WEB-INF/classes/someName.properties, is loaded and treated as the default language file.

4. Locale-specific properties file: Based on the languages accepted by the browser, Struts automatically looks for specialized files corresponding to the locale. A locale-specific file has the same name as the default properties file but is augmented with local information, e.g. someName_es.properties (Spanish locale) or sometime fr. properties (French locale). Entries from a more specific file override entries from the default file. The locale can also be set explicitly (e.g., based on the incoming checkbox value) in an Action with setLocale.

Once you have created a locale-specific properties file, you will want to test it in your Web application. To test the new properties file, change the language settings in the browser. For Internet Explorer, for instance, select Tools from the menu, then Internet Options, then Languages. Click the Add button to select other languages for the browser. To change the language preference order, use the Move Up button.

Now, we present an example where we internationalize for English, Spanish and French. All we need to do is to create two new properties files (refer to chapter 8 on Struts for more on properties files), MessageResources_es.properties for the Spanish locale and MessageResources_fr.properties for the French locale, The assumption is that the original file, MessageResources.properties, supports the English locale. The two new locale files need to contain all the same messages as MessageResources.properties but are translated to the appropriate language. The keys remain the same. This change is all that is required to internationalize the application for Spanish and French – there are no changes to any configuration files or code!