[Haskell-cafe] haskell i18n best practices

Edward Kmett ekmett at gmail.com
Tue Oct 11 22:03:34 CEST 2011

On Thu, Sep 29, 2011 at 6:54 PM, Paulo Pocinho <pocinho at gmail.com> wrote:

> Hello list.
> I've been trying to figure a nice method to provide localisation. An
> application is deployed using a conventional installer. The end-user
> is not required to have the Haskell runtimes, compiler or platform.
> The application should bundle ready to use translation data. What I am
> after is simple; an intuitive way that an interested translator, with
> little knowledge of Haskell, can look at and create valid translation
> data.

I've been meaning to bundle up some i18n/l10n code that I have lying around
from previous compiler projects.

What I was using was a gettext/printf template haskell function that can be
hunted for with xgettext, which expands to code that reads translated .po
files for the current module at two different times. Once at compile time to
check that any printf-style format strings are compatible across each
translation, and again later at runtime to allow for additional translations
to be added.

The biggest headache I have is that doing all this requires a pretty hairy
.cabal file, and I haven't yet figured out how to package that up nicely for
use in libraries.

I'll admit I have only ever really tested this with a joke
en at lolcattranslation, which I auto-translate with perl, though I admit
if I could
find a nice perl module for generating zalgo-style text, en at zalgo would be
pretty neat to auto-generate as well.

I'm not sure its considered "best practice", since I haven't bundled it up
for third party use yet, but its *my* practice. ;)

-Edward Kmett

> This is what I've been looking at lately. The first thing I noticed
> was the GNU gettext implementation for Haskell. The wiki page [1] has
> a nice explanation by Aufheben. The hgettext package is found here
> [2].
> I don't know if this is a bad habit, but I had already separated the
> dialogue text in the code with variables holding the respective
> strings. At this time, I thought there could be some other way than
> gettext. Then I figured how to import localisation data, that the
> program loads, from external files. The data type is basically a tuple
> with variable-names associated with strings. This is bit like the
> file-embed package [3].
> Still uncomfortable with i18n, I learned about the article "I18N in
> Haskell" in yesod blog [4]. I'd like to hear more about it.
> What is considered the best practice for localisation?
> --
> [1]
> http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs
> [2] http://hackage.haskell.org/packages/archive/hgettext/
> [3] http://hackage.haskell.org/package/file-embed
> [4] http://www.yesodweb.com/blog/2011/01/i18n-in-haskell
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111011/d73c180e/attachment.htm>

More information about the Haskell-Cafe mailing list