On Thu, Sep 29, 2011 at 3:54 PM, Paulo Pocinho <poci...@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 language: * 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). --Rogan > 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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe