Customized Internationalization (i18n) in Java - Step by Step

Internationalization (i18n) is very important in our software projects. It brings mainly these benefits:

• Externalizing UI strings into external files other than code files and so easy-to-manage UI content.
• Supporting multiple languages.

In this post, a brief practical example of i18n will be given for Eclipse and Java projects, including customizing i18n mechanism to have more maintainable and encapsulated approach.

• First, we must have some classes which includes string values shown on user interface:

An example UI class

• Then we must have an instance of an i18n utility class. This is generally one of the two in Java:

• java.util.ResourceBundle (doesn't need spring dependency)

ResourceBundle initialization

• org.springframework.context.support.ResourceBundleMessageSource (has multiple word externalization capability (which will be told later)).

ResourceBundleMessageSource initialization

We'll use ResourceBundleMessageSource instance in this tutorial because of its extended capabilities.

• Then right click on the class and choose Source --> Externalize Strings. A window as below will be shown. Enter keys for strings into the right column. Keys will be started with class name as default. Keys must be unique on the system, so a predefined pattern should be applied (e.g. <class_name>.<type_id>.<description>)

Eclipse string externalization window

• Click Next--> Finish and your strings will be changed as follows. And also Messages class and externalizer properties file will be created automatically (auto-comments on the right are markers for eclipse which means  "externalized"):

Class with externalized strings

Auto-created i18n utility and property classes

• Now externalization is complete. But we want i18n, and we must support multiple languages. For this, define another properties file with location post-tag (e.g. "EN", "FR", "TR", ...), copy keys and fill values with new language and set locale of resource bundle in a proper place/action of your application (e.g. on settings window or login page):

Multiple property files for each language

Messages_tr_TR.properties file content

Setting new locale to the resource bundle

• As the last step, we want to encapsulate i18n utility class and also want to use a more  capable i18n utility (e.g.  ResourceBundleMessageSource). For this, define a class as below:

Customized and encapsulated message source (i18n utility) class

• Finally, change "Messages.getString" statements into your new instance:

Class with externalized strings (with customized i18n utility class)

• You can also externalize parameterized strings using your class. Its usage will be as follows:

Getting a parameterized string from i18n utility

Defining a parameterized string in property file

15 Best Practices of Variable & Method Naming

1. Use short enough and long enough variable names in each scope of code. Generally length may be 1 char for loop counters, 1 word for condition/loop variables, 1-2 words for methods, 2-3 words for classes, 3-4 words for globals.
2. Use specific names for variables, for example "value", "equals", "data", ... are not valid names for any case.
3. Use meaningful names for variables. Variable name must define the exact explanation of its content.
4. Don't start variables with o_, obj_, m_ etc. A variable does not need tags stating that it is a variable.
5. Obey company naming standards and write variable names consistently in application: e.g. txtUserName, lblUserName, cmbSchoolType, ... Otherwise readability will reduce and find/replace tools will be unusable.
6. Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. userName, UserName, USER_NAME, m_userName, username, ...
• For example for Java, 
• use Camel Case (aka Upper Camel Case) for classes: VelocityResponseWriter
• use Lower Case for packages: com.company.project.ui
• use Mixed Case (aka Lower Camel Case) for variables: studentName
• use Upper Case for constants : MAX_PARAMETER_COUNT = 100
• use Camel Case for enum class names and Upper Case for enum values.
• don't use '_' anywhere except constants and enum values (which are constants).
7. Don't reuse same variable name in the same class in different contexts: e.g. in method, constructor, class. So you can provide more simplicity for understandability and maintainability.
8. Don't use same variable for different purposes in a method, conditional etc. Create a new and different named variable instead. This is also important for maintainability and readability.
9. Don't use non-ASCII chars in variable names. Those may run on your platform but may not on others.
10. Don't use too long variable names (e.g. 50 chars). Long names will bring ugly and hard-to-read code, also may not run on some compilers because of character limit.
11. Decide and use one natural language for naming, e.g. using mixed English and German names will be inconsistent and unreadable.
12. Use meaningful names for methods. The name must specify the exact action of the method and for most cases must start with a verb. (e.g. createPasswordHash)
13. Obey company naming standards and write method names consistently in application: e.g. getTxtUserName(), getLblUserName(), isStudentApproved(), ... Otherwise readability will reduce and find/replace tools will be unusable.
14. Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. getUserName, GetUserName, getusername, ...
• For example for Java, 
• use  Mixed Case  for method names: getStudentSchoolType 
• use  Mixed Case  for method parameters: setSchoolName(String schoolName)
15. Use meaningful names for method parameters, so it can documentate itself in case of no documentation.