[Haskell-i18n] Some starters for the new list

Sven Moritz Hallberg pesco@gmx.de
15 Aug 2002 20:31:55 +0200


Sorry, I accidently hit CTRL-Return which sent the message prematurely.
Here is the rest again:

On Thu, 2002-08-15 at 20:21, Sven Moritz Hallberg wrote:
> [...]
>
> After some pondering, I think we should base i18n on the first snippet's
> approach:
> 
>   - There will be a data type representing a "message" which will be 
>     displayed to the user. The message is then translated to a string
>     in a given language.
> 
>   - The languages are, this appears natural to me, values of a data type
>     again. We can have ctors for everything there are ISO codes for or
>     so. In order to be extensible, a ctor taking a string argument
>     appears suitable.
> 

I suspect we can build all the convenience we need on top of this easy
and clear to understand basis. For instance, if we want the string
lookup way of things, one can just use String as the message type, like
this:

    type Msg = String

    trans De "There is no space left on the storage device."
         = "Der Datentraeger ist voll."
    trans En = id


The choice is up to the application developer. I'd personally tend to
use a real data type, because that lets me do this:

        data Msg = ... | MessagesWaiting n | ...

        trans En MessagesWaiting n
                 = "You have "++(show n)++m++" waiting."
                 where m 
                       | n==1 = " message"
                       | otherwise = " messages"
        trans De MessagesWaiting n
             | n==1 = "Sie haben eine neue Nachricht."
             | otherwise = "Es warten "++(show n)++" Nachrichten auf Sie."

I can't think of a more contrived example right now, but I'm sure many
exist. Also note that (once there is some sort of locale-aware show) one
will get the benefits of that coherently across all messages.


Reading translation tables from files is of course important. How about

    Read msg => readTransTable :: String -> IO (msg -> String)

which takes a filename and yields a translation function? This would
work for any data type in the Read class, String already is and a custom
type could simply derive Read.


Again, sorry for the accidental double post. :/

Regards,
Sven Moritz