Working as a Consultant

Wearing many hats at work is what interest interest me with my job. Being a Consultant definitely provides that. Meeting clients, talking about their needs, identifying technology platform, designing the system and managing a development team are just about the things I've enjoyed doing.


Developing a system in-house for a client makes the development and management effort very interesting but I find there are two most critical things that needs to happen before a single code is written as shown below.

• Validating verbal and written client's development platform
• Knowing how your client's think, how your client's work, and what makes them happy.

Asking a client's system environment  is not enough to produce a product's platform development. One should consider validating the client's environment by developing a dummy framework built according the to their system specification. Try dropping that framework onto their server and start running some dummy test cases. This will validate the version of the programming language being used, modules installed, security restrictions and some unknown and known incompatibilities. Some client's environment are tightly secured even down to the smallest feature of an application and sometimes this is what makes developing/deploying an application difficult. Validating an environment by writing a sample framework is the surest way to know exactly the platform one should be developing on.

Now, another interesting thing to note is that when you understand who your clients are and how they think, it makes it a lot easier to work with them and  one can pretty much predict how the application should be designed and created. Carefully listen to what they need and how it should be incorporated to the application. The culture of the company reflects on their personality and this is what drives what they produce and use. A consultant should be able to identify and classify business functions that are most critical, important and least important. 

Internationalizing Java Web Applications Part I

Internationalizing an application can become a daunting task. Specially if the application already existed for quite some time. What more if the business decides to support a huge number of languages? There are several things to consider to ensure that the application displays the correct translation according to its locale. This is just the minimum list but there might be some other stuff to consider. Let's start with the list below.

The Setup:

1. Windows Server

2. Windows XP Client Machine

3. Java Web Application

4. SQL Server 2005

5. Firefox/IE

1. Browser Support

2. OS and Microsoft Office Language Settings
4. Database Internationalization Support
6. i18n Bundle - Property Files and Data

7. Font Support (Highlight If Text is embedded in an image)

8. UTF-8 Encoding

9. JSON element/data Encoding/Decoding
10. The Locale class

Browser Support

This is the easiest to figure out. Lots of browsers out there supports tons of languages. It's just a matter of choice.


OS and MS Office Language Settings
1. OS Server
The operating system should have been installed with the languages the users are interested in. At least the english (en_US) language and make it the default language. You can check what the OS supports by checking the Regional and Language Options if your server is Windows based. There you can see Standards and Formats of the currency, number and time from the Regional Options tab. While the Languages tab shows the option to choose what Text Services and Input Languages to use and allows one to install East Asian Language Support and this is really important specially if we are working with Chinese, Japanese or Korean language. 


Now for an Application Testing Environment that supports many different languages, the server can have the English [United States] setting from Regional Options and leave the other properties unchanged. If Japanese, Chinese or Korean or any East Asian Language is needed for the application, then the East Asian Language Support must be installed.


To test if the language settings are correct, drop a text file that contains data with the language of interest to the server. Open the file. If the data is in Chinese, then the text characters should show up as Chinese characters. Otherwise, the language settings aren't right.


2. OS Client
On the client side, there must also be Language settings that needs to be done. The OS should also have come installed with other languages. But the East Asian Language is by default not installed. This must be installed if Japanese, Chinese or Korean needs to be supported.


3. Microsoft Office
Apparently, Microsoft Office needs to be tweaked to properly display East Asian characters. No tweaking is necessary for other languages. Just go to Microsoft Office Tools and click on Microsoft Office Language Settings. There you can enable other languages for proper viewing of data.


Database Internationalization Support
All major database products supports internationalization. It should be able to support Unicode characters or the literal character of that language (by using the prefix 'N' when inserting data into the database).


I18N Bundle
All internationalized app have i18n bundle which is used for displaying the appropriate label, description or error message to the application. This bundle is basically a jar file containing all the supported languages or locales. The files in that jar are properties file of the form I18N_locale.properties (i.e. I18N_en_US.properties for English US). So each properties file is composed of a key/value pair. If this is done right, then you avoid a lot of translation issues. The number of keys from the default locale, say en_US should match the number of keys in the other locales. The value for each key must be translated for its target locale.