On Thu, Sep 29, 2011 at 7:54 PM, Paulo Pocinho wrote:

Still uncomfortable with i18n, I learned about the article "I18N in Haskell" in yesod blog [4]. I'd like to hear more about it.

Yesod's approach is pretty nice [1]. The idea is to have a data type with all your messages, like data Message = Hello | WhatsYourName | MyNameIs String | Ihave_apples Int GoodBye For each of your supported languages, you provide a rendering function (they may be in separate source files) render_en_US :: Message -> String render_en_US Hello = "Hello!" render_en_US WhatsYourName = "What's your name?" render_en_US (MyNameIs name) = "My name is " ++ name ++ "." render_en_US (Ihave_apples 0) = "I don't have any apples." render_en_US (Ihave_apples 1) = "I have one apple." render_en_US (Ihave_apples n) = "I have " ++ n ++ " apples." render_en_US GoodBye = "Good bye!" render_pt_BR :: Message -> String render_pt_BR Hello = "Olá!" render_pt_BR WhatsYourName = "Como você se chama?" render_pt_BR (MyNameIs name) = "Eu me chamo " ++ name ++ "." render_pt_BR (Ihave_apples 0) = "Não tenho nenhuma maçã." render_pt_BR (Ihave_apples 1) = "Tenho uma maçã." render_pt_BR (Ihave_apples 2) = "Tenho uma maçã." render_pt_BR (Ihave_apples n) = "Tenho " ++ show n ++ " maçãs." render_pt_BR GoodBye = "Tchau!" Given those functions, you can construct something like type Lang = String render :: [Lang] -> Message -> String render ("pt" :_) = render_pt_BR render ("pt_BR":_) = render_pt_BR render ("en" :_) = render_en_US render ("en_US":_) = render_en_US render (_:xs) = render xs render _ = render_en_US So 'r = render ["fr", "pt"]' will do the right thing. You just need to pass this 'r' around in your code. Using is easy and clear: putStrLn $ r Hello putStrLn $ r WhatsYourName name <- getLine putStrLn $ r MyNameIs "Alice" putStrLn $ r (Ihave_apples $ length name `mod` 4) putStrLn $ r GoodBye This approach is nice for several reasons: - Builtin support for complicated messages. Making something like Ihave_apples in gettext would be hard. Each language has its own rules, and you need to encode all of them in your code. On this example, my render_pt_BR recognizes and treats differently the 2 apples case. If you didn't think about it when you wrote your code (using gettext), you'd need to change your code for pt_BR. - Fast processing. "render" as I've coded above looks at the language list just once. After that, it's just GHC's pattern matching. - Fast startup. No need to look for strings on the hard drive. - Flexible. You may try several extensions, depending on your needs (a) Using a type class (like Yesod) if you don't want one big data type. (b) Using Text instead of String. Or even Builder. The biggest drawback is lack of tool support and lack of "translators' expertise". gettext has a lot of inertia and is used everywhere on a FLOSS system. But as Ertugrul Soeylemez said, if you're targeting Windows, _not_ using gettext should be an advantage (less pain while create installers). HTH, [1] http://hackage.haskell.org/packages/archive/yesod-core/0.9.2/doc/html/Yesod-... -- Felipe.

On Thu, Sep 29, 2011 at 6:54 PM, Paulo Pocinho 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@lolcattranslation, which I auto-translate with perl, though I admit if I could find a nice perl module for generating zalgo-style text, en@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe