Perl Internationalization and Haskell: An Interview with Autrijus Tang

by Edd Dumbill
September 08, 2005

Author's note: Autrijus Tang is a speaker at this October's European Open Source Convention. In the fine tradition of the OSCON, he is a Perl hacker, entrepreneur, internationalization geek, and self-proclaimed "Net activist, artist, and anarchist."

AT EuroOSCON, Tang will speak about Pugs, a Perl 6 implementation written in Haskell, and he will teach a session on learning Haskell. O'Reilly Network caught up with him to ask about one of his major endeavors, Perl internationalization and Haskell.

On Perl and Internationalization

Edd Dumbill: Let's talk about Perl and localization. I will admit that when thinking about localized applications, Perl really isn't the first language that comes to mind. How long has Perl had localization capabilities?

Autrijus Tang: Gettext bindings date back to 1996. In 2002, an I18N/L10N (internationalization/localization) framework was built into the core distribution as part of Perl's 5.8 release.

ED: How easy is it to introduce I18N to an existing Perl application? Or is it best to start localized from the beginning?

AT: The conversion is straightforward, so I usually recommend starting L10N only after a first working version is ready. However, if the program depends on a specific encoding (say ISO-8859-1) for data storage, then it may take some effort to convert it to use Unicode.

ED: What kind of tools exist to support Perl internationalization?

AT: Lots of tools. The Locale::Maketext family of modules contains various utilities. The application framework may also have built-in support using those modules; for example, the Catalyst::Plugin::I18N component uses my Locale::Maketext::Simple module to work with PO files, as well as lexicons implemented as Perl modules.

ED: Many hackers will be familiar with using GNU Gettext. Is it possible to use that with Perl? Is it preferable?

AT: There are six Gettext bindings on CPAN; some use the C API, some use XML, and some parse the .mo files in pure perl. Moreover, Locale::Maketext users can use PO files via the ::Lexicon and ::Simple helper modules.

I think [Gettext] PO files are preferable for the great toolchain and cross-language appeal, although sometimes it's better to manage lexicons in other databases. This is like a common DBI interface with database-dependent DBD drivers; Locale::Maketext::Lexicon is written specifically to address that need.

ED: CPAN is one of Perl's major advantages, but how accessible is it to non-English speakers?

AT: There are projects like PerlChina and perldoc.jp to translate articles and documentation, and many Perl Monger groups that hold local meetings. While most mailing lists are in English, non-English speaking people can usually find IRC channels and USENET groups for support.

ED: What percentage of popular modules would you say are localized to a usable degree?

AT: Most modules on CPAN are "plumbings"; they are not exposed to the user, so there is little need to localize them. If the user might see errors or messages from those modules, it's easy enough to localize those in an ad-hoc fashion with tools such as Locale::Maketext::Fuzzy.

The important place for I18N is in the templating and application engines; I'd say most of them already have suitable plugins for I18N now.

ED: How do you encourage people to write I18N-ized applications? In the GNOME project, for instance, it's thought of pretty much as something to do by default, and there's a keen translation team. Is there a team somewhere localising Perl modules?

AT: Open source is great for I18N: the original author does not need to know anything about it, and people who need I18N capabilities can easily hack them in. Because of this, I18N and L10N tend to happen when there is demand. It's our job to constantly improve the tools, to make the entry barrier to localize somebody else's code as low as possible.

Pages: 1, 2

Next Page