Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Some I18N Requirements
At its core, accommodating I18N is mostly a problem of separating code from text resources. This is a bit like the now-routine separation of business logic (increasingly referred to as service logic) from presentation. In I18N, you want to be able to easily change language and data formats—if possible, without having to recompile—for entities such as
- Dialog text blocks
- Help files
- GUI element text tags (for example, button labels)
- Currency symbols
- Delimiters for currency amounts
- Dates
On a more general level, these requirements describe text substitution problems.
In pre-Java days, I18N constituted a rather arduous process of manually extracting I18N elements and placing them in disk files. This extraction process often occurred as the software was used more and more in non-English language locations. The consequence was that some poor soul had to go through the code, pulling out text strings and copying them into files. The files were then sent for translation, after which some cunning scheme had to be devised for locating, loading, and reading the text strings back into the program. At runtime, the I18N elements would be dynamically inserted by the code to produce an internationalized version.
The problem with these schemes was their cumbersome and proprietary nature. Fortunately, I18N began to be considered a language issue, and Java includes standard support features for this task. So you can internationalize Java code from the beginning with little extra cost. I have worked on products that were destined only for the U.S. market and therefore were not internationalized. However, I was always inclined to I18N-enable the code because it's good practice and also because it's pretty easy.
Let's lay some groundwork by examining some I18N examples before looking at the AOP area.