[Haskell-cafe] haskell i18n best practices

Rogan Creswick creswick at gmail.com
Fri Sep 30 22:44:16 CEST 2011

On Thu, Sep 29, 2011 at 3:54 PM, Paulo Pocinho <pocinho at gmail.com> wrote:
> Hello list.
> I've been trying to figure a nice method to provide localisation. An

The grammatical framework excels at translation and localization -- it
probably has the highest learning curve of the options; but it will
generate the best / most accurate text depending on the target

 * http://www.grammaticalframework.org

At first brush, it may seem like extreme overkill; but it is able to
handle many, many infuriating corner cases (eg: properly forming
discontinuous constituents, updating case / tense and number to agree
with potentially variable quantities and genders, addressing the
absence of "yes" and "no" in some languages, etc...)

The language processing bits are expressed in a PMCFG grammar, which
uses a syntax similar to haskell.  The PMCFG compiles to a PGF file
that can be loaded and used by a haskell module that implements the
runtime, so it doesn't change your run-time requirements (if you
already rely on haskell, there are also runtime implementations in
javascript, java, c and python).


> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list