Internationalizing Java applications includes highly
repetitive tasks. The standard method is
to use a property file per supported language, which effectively contains a
look-up table of content that is presented in the user interface. Hard-coded content displayed in the user
interface is moved into properties files, and is replaced with unique
keys. Initially, the following syntax
was used for naming keys:
- <source file name>.<description>
The format allowed developers to quickly determine where
the key is used in the source code. It
also helped provide translators the general area of the user interface the content
is used, thus providing a bit of context.
Later in the project, translators requested further information to
narrow down context even further. The
following format, which includes a look-up value used to indicate descriptor
(button, label, link, title, etc...), was used:
- <source file name>.<descriptor>.<description>
Note that keys are only used once within each application
to maximize translation flexibility. We
wanted to avoid forcing translators to use the same content in multiple places,
which could result in incorrect contexts.
In general, internationalizing applications is not a technically difficult task. However, it is time consuming, repetitive, monotonous work and therefore prone to errors. Anything that can be done to minimize errors due to this is highly recommended.
Syntax highlighting source code editors are hugely advantageous when internationalizing applications. These editors allow developers to efficiently scan source code for literals, which is where content that requires translating resides.
However, these editors can't provide syntax highlighting for languages within languages which is sometimes the case. For example, Java source code literals can contain HTML source, which in turn contains JavaScript. Source inside of source is important because different escape sequences are required.
After changing my development to use AutoHotKey, I found that the number of errors was significantly reduced. Originally, I had a relatively large amount of typos, missing and out of order letters, etc… in the source code and property files. Afterwards, these were almost entirely eliminated. Furthermore, I was internationalizing the source code much faster than before.
In general, internationalizing applications is not a technically difficult task. However, it is time consuming, repetitive, monotonous work and therefore prone to errors. Anything that can be done to minimize errors due to this is highly recommended.
Syntax highlighting source code editors are hugely advantageous when internationalizing applications. These editors allow developers to efficiently scan source code for literals, which is where content that requires translating resides.
However, these editors can't provide syntax highlighting for languages within languages which is sometimes the case. For example, Java source code literals can contain HTML source, which in turn contains JavaScript. Source inside of source is important because different escape sequences are required.
To simplify the effort, a class should be used to maximize
code reuse in the application. Create
methods in the class that perform common tasks such as returning text based on
a properties file key, adding escape sequences to content based on the target
language (HTML, JavaScript, JavaScript within HTML) and formatting numbers.
I found that using tools like AutoHotKey to automate common
tasks was extremely beneficial. I
created a shortcut that copied the currently selected text to the clipboard and
replaced the text with a method call to the internationalization object,
including the source file name as the argument.
The appropriate quotes and concatenation operators were also
included. Then I only had to type in a
description for the text, and put the corresponding entry in the appropriate
property files. With minimal ingenuity,
AutoHotKey can automate most of the task of inserting the entry in the property
files as well. Basically any task/key
sequence you are doing repeatedly can be added to AutoHotKey. After changing my development to use AutoHotKey, I found that the number of errors was significantly reduced. Originally, I had a relatively large amount of typos, missing and out of order letters, etc… in the source code and property files. Afterwards, these were almost entirely eliminated. Furthermore, I was internationalizing the source code much faster than before.
No comments:
Post a Comment