"Claus Reinke" <[EMAIL PROTECTED]> writes: > Haskell definitely supports abstraction and composition, so we can > factor out application aspects (not just text) that need localisation, > and link them (dynamically?) with the main parts of our applications. > Some systematic approach would be useful, but apart from keeping > track of the issues raised in the standards committees, I don't see > why Haskellers should limit themselves to "the" standard way of > patching C#/Java apps with translated text fragments.
I think there is a good reason to use standard localisation methods; it makes it cheaper/more likely to happen. It sounds like you're advocating localisation methods which would require the translators to know Haskell; this would make hiring translators more expensive (for a commercial proposition) or significantly reduce your pool of volunteers (if you rely on volunteer translators). Carl Witty _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
