i18n for XSLT in 4Suite

Prodded by discussion on the CherryPy list I have implemented and checked in a 4Suite XSLT extension for internationalization using Python's gettext facilities for the underlying support. Here is how it works. Sample XML:


Sample XSLT:

<xsl:stylesheet version="1.0"
  <f:setup-translations domain="test"/>
  <xsl:template match="msg">

The f:setup-translations and f:gettext extension elements are the key. The former looks up and installs the domain "test" for use in your XSLT. Replace it with the domain used by your application. The latter extension evaluates its body to get a string value, and then looks up this string in the installed translation.

Assuming you have a test.mo installed in the right place, say that translates "hello" to "howdy" and "goodbye" to "so long".

$ 4xslt test.xml test.xsl
<?xml version="1.0" encoding="UTF-8"?>
  so long

I trimmed some white space for formatting, but you get the idea. The translations are applied automatically according to your locale.

This operates via Python's gettext facilities which means that it's much more efficient than, say, the docbook XSLT approach to i18n.

For those who want to give it a whirl, here's a quick step-by-step. All the needed files are available here on copia.

Create a sandbox locale directory:

mkdir -p /tmp/locale/en_US/LC_MESSAGES/

Copy in the catalog. You may need to create a different catalog for your own language if your system will not be selecting en_US as locale (remember that you can hack the locale via the environment)

cp en_US.mo /tmp/locale/en_US/LC_MESSAGES/test.mo

Your locale is probably not en_US. If not, you can:

  • temporarily override your locale to en_us using export LANG=en_US, or the equivalent command for your shell
  • create translations for your locale (just two strings to translate). I use poedit, which is makes dealing with .pos simple enough. Then replace en_US in all the above instructions with your own locale and the .mo file you created.

Anyway, the f:setup-translations and f:gettext extensions are now checked into 4Suite. You can either update to current 4Suite CVS, or just download the one changed file, Ft/Xml/Xslt/BuiltInExtElements.py and copy it into your 4Suite codebase. It works fine as a drop-in to 4Suite 1.0b1.

[Uche Ogbuji]

via Copia

A couple of Amara/CherryPy Demos

As I've mentioned, I've been playing with Amara/4Suite and CherryPy. Luis Miguel Morillas has been as well. We're both taking things slowly, pursuing it from different angles.

Luis has a "Web-based docbook browser and processor using CherryPy and Amara.". It's a very simple script for rendering as Web content an index and chapters of Mark Pilgrim's Dive into Python book as XML and XML+CSS (which seems to be creeping into the mainstream?).

I also have a demo as part of Amara, cherrypy-xml- inspector.py, which allows you to "inspect" an XML document, through a Web form using CherryPy and Amara. You can load any document off the Web and then enter in an amara expression, such as "doc.html.head.title" and get the result.

[Uche Ogbuji]

via Copia

CherryPy 2.0


After several months of hard work the first stable release of CherryPy2 is finally available. Downloads are available here and the ChangeLog can be viewed here.

Remi Delon announced the 2.0 release of CherryPy. It's my favorite entry in the the Python Web frameworks sweepstakes. It's very simple to learn and use, and it just makes sense. Very few surprising conventions. My own endorsement is among the many testimonials CherryPy has picked up

I'm also pulling for CherryPy to form the heart of the protocol server for the next generation of 4Suite. As I said on the CherryPy discussion board:

I have a nefarious agenda: I regret our having reinvented some wheels in 4Suite, and most especially the Web framework wheel. To be fair to us, the likes of CherryPy were not available at the time and it was pretty much Zope, Webware, mod_python or bust, and we didn't like any of those options. But now we're saddled with really not-that-great re-implementations of HTTP [server] framework, session management, etc, all too tightly coupled into the XML database for my liking. I'd like to move to a more open architecture that decouples core XML libraries from XML DBMS from protocol framework (with CherryPy ideally as the latter). That way, [someone] could get CherryPy, and if they liked, a simple XML processing plug in, and if they liked, an XML DB plug in, and so on. If I can get [something] working sweet as sugar with CherryPy, I bet I could convice my fellow 4Suite developers to leave the Web frameworks to the dedicated Web frameworks projects.

I've been plugging slowly away with these ideas, but it's been hard to get to it with all the other items in the work queue. Perhaps this announcement will spur me to get something into shape.

[Uche Ogbuji]

via Copia