Localizer 0.9.3 released

First, many thanks for the splendid work on Localizer. With Translation Services, it looks likely to transform Web services to students and alumni in the faculty where I work. I couldn't be more grateful.

In adapting these products to our needs, though, I'm ending up hacking in an extension, so I'm sending in this note in case anyone is interested in the code when it's finished -- and in case I'm reinventing the wheel.

In brief, here's the problem. Our site is a filesystem-based thing, with tab-and-breadcrumb navigation. Tab labels, folder descriptions, and item titles and abstracts are drawn from object metadata. To take the site multi-lingual, we want to maintain translations of the metadata. Translation Services does a brilliant job of spinning up message catalog keys from metadata on the fly -- I was really surprised that this worked straight out of the box.

But if we stop there, we will have maintenance problems with the site, because the metadata content changes often, and if key references to Japanese are lost each time the English changes, our translators will complain.

I plan to alter our CMF to generate unique keys for the two metadata fields, and abstract all content into the message catalog. Then I want to maintain these catalogs within Zope, rather that relying on PO-tools. My reason for wanting to do so is that metadata changes too frequently for PO-export/PO-import cycles to keep up with us, and that my colleagues and students, who will be handling the translation task, will not want to take the time to master the desktop tools of a professional translator in order to contribute to the site.

I can draft up a template and associated methods for maintaining translations within the site, but to do so, I need date information on individual entries. Specifically, I need to know the most recent date on which an entry was modified (so that I can track recent changes), and the origin date of a given entry. A change to metadata may be an adjustment to smooth out the language, without affecting content. In this case, other maintainers of other languages need not be alerted. But when an editor changes the content of metadata in a way that affects its meaning, he should be able to touch a toggle that sets the origin date of the message catalog entry for that item to the current DateTime(). Maintainers capable of translating out of that maintainer's native language should then be alterted of the change, and when their adjustments are made, their entries should be set to the origin date of the triggering catalog entry.

This approach requires these two pieces of information in addition to the message catalog entries, so I have doctored Localizer to provide and maintain them, and doctored Translation Services to call on my modified MessageCatalog()s. The rest of the framework will be bespoke local stuff, probably not of interest to others. But date-stamping of message catalog entries in this way should open up interesting possibilities for bazaar-style translation maintenance strategies.

Anyhow, if anyone would like the code, please drop me a note. I would be really happy if this or similar functionality were incorporated into mainstream Localizer.