[Haskell-cafe] haskell i18n best practices

Paulo Pocinho pocinho at gmail.com
Fri Sep 30 00:54:35 CEST 2011


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.

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



More information about the Haskell-Cafe mailing list