"Claus Reinke" 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