This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: ExtraCatalogs
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
The MessageCatalog "framework" is begging to be "extended." We've never been fond of the "weightiness" of the VisualWorks localizable text resource files, so we set out to do something a little different. ExtraCatalogs has just been replicated up to the Open Repository.
A while back Georg Heeg had made public some efforts to build VisualWorks translation tools (called L10N I think). ExtraCatalogs effort is complementary to that effort. ExtraCatalogs is simply an alternative way of maintaining message catalogs and resolving user messages to them. The tool(s) Georg posted concentrate on how to actually do translations.
ExtraCatalogs has the following features:
Translations are stored in memory -- this means no thrashing between files. Just one initial load and everything runs along quite nice.
Works with Existing User Messages -- These bolt right into MessageCatalog framework which searches all subclasses for matches. So nothing changes there.
XLIFF export/import option -- This is an open standard, and it uses XML to keep buzzword bunnies happy. Which means that it also has standards for character coding issues. And is one file (as opposed to having to "compile" an idx file from a lbl file).
Support for thread specific locales -- Some had indicated a desire to do something for server style applications, where the system may actually need to render mutiple concurrent localizations of a given user message. To facilitate this, catalogs can be "registred" under a specific locale (if none specified, they go to the current one). As well, a locale can be attached to a given process via Process>>useLocale:. The resolution engine will use this locale when specified, or the current when none is specified (no, this package does not add an instance variable to Process, it uses the process's 'environment' dictionary to store it--I wish PDP did this too).
Unit Tests are included.
The code is free to use by anyone. It has some rough spots in the design still. Hopefully some time and usage will ferret these issues out, so any feedback/contributions is most welcome.
We played long and hard with the TMX file format (this had been mentioned by a couple different people). But TMX is a tool for translators to use, to move translation data between different translation programs. We attempted to use the TMX file to "short circuit" much of what is the normal process a translator goes through to translate a resource. While this would have been really snazzy, none of the translation tools are geared to deal with this kind of scenario. They use TMX files to translate your resources. After working with translators from a company or two, some vendors, and a mailing list or two, we deduced that the XLIFF file format was a better "open and standard" fit for what we were trying to do.
Previous Topic
