PackageDescription: ExtraCatalogs


Extra Catalogs

Last published: January 5, 2010 by 'xp'

Defines 3 Classes
Extends 4 Classes

This package was put together to address (perceived) shortcomings with the original VisualWorks I18N label/index file scheme for storing label translation resources. It does not change or remove the existing system, but sits as a transparent, but alternate method of resolving user messages. It has two basic parts to it:

1) New format for label translation resources - SimpleMessageCatalog is just a simple in memory dictionary. The amount of memory consumed by a normal, or even large, set of translation resources, is usually smaller than the number of bytes used to represent graphical assets such as icons and such. This keeps the system quite fast. SimpleMessageCatalogs are usually created from XLIFF files (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff). The biggest problem with XLIFF files is that when you hand a translation asset to your translators that is a format they use amongst themselves, it confuses them. SimpleMessageCatalogs can be created from XLIFF files, or created programmatically, and then asked to write themselves for initial translation. The class side of SimpleMessageCatalog has services for registring SimpleMessageCatalogs with given Locales. Typically, application code loads these registries on startup, and/or watches Locales for changes to adjust registered catalogs. One of the advantages of the XLIFF format, is that UserMessage keys may actually contain white space if desired.

2) Process specific Locales - Process has been extended with APIs to set a locale for a given process. When the label resolution engine is consulted for a translation, the current process is checked, and if it specifies a locale, that locale is used. If none is specified the existing global default is used. The existing implementation is simplistic and really only applies to label resolution. To make it more complete, two units of work could be done. The first is to make other Locale specific services (Timestamp printing for example) use the activeProcess currentLocale. At this time, only the SimpleMessageCatalog engine uses it. The other is that a process fork would inherit the environment of the process is what forked from. As it stands right now, if you fork a new process, it will have no "current locale" set for the new process. You have to set it yourself for each new unique process.