January 4, 2008

cl-i18n

cl-i18n is a gettext-style internationalization framework for Common Lisp.

Features:

  • dead simple
  • ASDF package
  • #! string read macro
  • warns and acts gracefully when an untranslated string is encountered
  • very clean translation resource format that can be edited by non-programmers

Deficiencies:

  • dead simple
  • no pluralisation support (will be the next thing, though)
  • only tested with SBCL
  • no unit tests yet
  • not ASDF-installable yet
  • read macro not optional
  • needs cl-ppcre to create translation resources automatically (should probably be done by the lisp reader)
  • read macro doesn’t handle forms yet

Usage:

See http://paste.lisp.org/display/53575.
Extract translatable strings with

(cl-i18n:generate-i18n-file "gowron-monologue.lisp" "klingon.lisp")

To make it work with cl-who, use the str directive, as in

(with-html-output *out*
  (:p (str #!"For Qo’noS!")))

Download:

cl-i18n 0.4
cl-i18n 0.3
cl-i18n 0.2

Darcs repository: http://viridian-project.de/~sky/cl-i18n/

January 04th 2008 Posted to Uncategorized

* Comments(8)

Comments

  1. Vilson Vieira
    January 7th, 2008 | 3:42 am

    Hi, congratulations about cl-i18n, I loved your dead simple solution :-)

    I’ve made a quick-and-dirty hack to read a CL source file searching for #!”strings” and generate the i18n file. It’s here:

    http://vilson.void.cc/files/i18n-util.lisp

    Cheers.

  2. admin
    January 7th, 2008 | 11:14 am

    I’m glad you like it, mov! :)

    I intended to use the Lisp reader for extracting translatable strings, but your cl-ppcre solution is fine with me, too. I’m going to release 0.3 today with your addition, thank you very much!

    The next step would be merging new strings into an already existing translation resource (the job of gettext’s msgmerge tool). This should be a trivial matter by reading what’s already there and finding the set-difference.

    Leslie

  3. Vilson Vieira
    January 8th, 2008 | 2:45 am

    Leslie, thanks for the acceptance of the contribution :-)

    Yes, a Lisp reader would be the right solution. BTW, I followed your suggestion and made the merging possible. I don’t know if it’s the right solution, but it’s working for now.

    I refactored the code, renamed some files, used a unique package to base and util functions, included a CHANGELOG (sorry, I don’t have information about 0.2 release, please, can you fix it?). A possible 0.4 release is here:

    http://vilson.void.cc/files/cl-i18n-0.4.tar.gz

    Be free to modify everything! :-)

    Cheers.

  4. Leslie
    January 8th, 2008 | 3:22 pm

    0.2 actually was the first public release. I’ll put up 0.4 in a moment with a few minor non-code modifications. Thanks again! :)

  5. Robin Powell
    June 18th, 2008 | 9:35 pm

    The problem is, simple i18n solutions are guaranteed to not work; see http://perldoc.perl.org/Locale/Maketext/TPJ13.html for why. Per-language functions, and a clean way of embedding them, are really a requirement. I hope you’ll include MakeText-like things like this so I don’t have to write my own. :)

    -Robin

  6. Leslie
    June 19th, 2008 | 9:31 am

    Yeah, I know this document.

    I don’t have time to work on a comprehensive framework like this, but maybe Slava from Weblocks will do so.

    In the meantime, try cl-i18n; with format strings it’s more powerful than you might think.

  7. Michel
    July 9th, 2008 | 10:40 pm

    Did you look at CL-L10N ?

    Can someone tell us the main advantages/disadvantages of the new CL-i18n comparing to CL-L10N ?

  8. Peter
    August 14th, 2009 | 8:59 am

    FWIW, there’s a Lisp implementation of gettext (that uses gettext .mo files; you use the normal gettext tools for everything) in Maxima: http://maxima.cvs.sourceforge.net/viewvc/*checkout*/maxima/maxima/src/intl.lisp

Leave a reply