Multilingual Issues

Most developers targeting their products for markets other than just the English-speaking world (or the German-speaking world, if you prefer) are well aware of the several issues surrounding multilingual support. We need to address two of these in relation to the utilities we're developing.

The first issue is the ability of the utilities to manipulate documents in several different character sets. XML (through its support for Unicode), Java, and Win32 all support several different character sets including multibyte sets. I have chosen Unicode's UTF-8 as the character encoding specified in the XML prolog of the instance documents these utilities create. Due to the design of UTF-8 most requirements should be accommodated. However, if you need a different encoding, I will assume you are aware of the issues involved. Here is some relevant information about the utilities as currently implemented.

• All record lengths, field lengths, and offsets are specified in terms of bytes, not characters .

• Delimiters such as line feed record terminators, CSV column separators, quotation marks, and EDI segment terminators are handled as single-byte characters.

• Conversions that involve examining and manipulating data treat the data as single-byte characters. Examples include converting dates to and from ISO 8601 formats and numeric conversions.

• String fields are considered strictly as a series of bytes with no attention paid to character encoding.

The second issue is in the area of text messages displayed by the utilities. The text messages created within the utilities are all in English. However, they are mostly coded as string constants in a common class or header file. This should make it fairly easy to create versions that display messages in other languages. A more ambitious enhancement would be to build tables with the messages in the appropriate languages and let the end user configure the desired language. For this version I'm not that ambitious.

I have not extensively researched whether or not JAXP with Xerces or MSXML have the ability to generate error message text in the computer's local language. There is no mention of multilingual messages in the documentation for either API, so I'm going to assume it isn't there. If you need such functionality, you should probably research whether or not the API you selected does, whether it supports your specific language requirements, and the specific mechanisms you need to employ to take advantage of the functionality.