Happstack internationalization and localization
Hello, Happstack does not offer anything special for internationalization. And, it probably shouldn't either. I18N is a more general problem, and it seems like a more general solution is what you want. That said, to the best of my knowledge, I18N and L10N are not a very well explored areas of Haskell development. This page suggestions some methods: http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs What template system are you trying to use? Also, if you have suggestions for how Happstack could make I18N easier -- we'd be happy to hear them. But it seems like the problem is largely orthogonal to Happstack itself? One area where Happstack could be involved is if you wished to use text encodings than UTF-8. That is mostly possible with Happstack already. But you would need a pretty compelling reason to not just stick with UTF-8 I think. (For example, interoperating with a legacy system that does not use UTF-8). - jeremy On Fri, Dec 9, 2011 at 6:20 PM, Asafe Ribeiro <asafe.hai.kai@gmail.com> wrote:
Does Happstack offer anything for internationalization ?
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
I updated the wiki page to better point out the Yesod web framework's internationalization. Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack. Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack. On Fri, Dec 9, 2011 at 11:17 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
Hello,
Happstack does not offer anything special for internationalization. And, it probably shouldn't either. I18N is a more general problem, and it seems like a more general solution is what you want.
That said, to the best of my knowledge, I18N and L10N are not a very well explored areas of Haskell development.
This page suggestions some methods:
http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs
What template system are you trying to use?
Also, if you have suggestions for how Happstack could make I18N easier -- we'd be happy to hear them. But it seems like the problem is largely orthogonal to Happstack itself?
One area where Happstack could be involved is if you wished to use text encodings than UTF-8. That is mostly possible with Happstack already. But you would need a pretty compelling reason to not just stick with UTF-8 I think. (For example, interoperating with a legacy system that does not use UTF-8).
- jeremy
On Fri, Dec 9, 2011 at 6:20 PM, Asafe Ribeiro <asafe.hai.kai@gmail.com> wrote:
Does Happstack offer anything for internationalization ?
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber <greg@gregweber.info> wrote:
Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack.
Right. That sounds useful and easy to do.
Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack.
We already have Hamlet support in Happstack. But, it seems like that is not enough? We also need some stuff that is in Yesod.Message, etc? In my ignorance, it seems like there are three pieces: 1. a little bit of framework/application specific code that detects/sets the language to use 2. a bunch of framework independent code that deals with mapping data-types to translated strings 3. some glue code that makes it easy to use #2 with a particular templating library But, right now it seems that #2 is wrapped up in the yesod hierarchy even though it would be useful for any Haskell program that wants i18n? Or am I missing something? - jeremy
On Fri, Dec 9, 2011 at 11:17 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
Hello,
Happstack does not offer anything special for internationalization. And, it probably shouldn't either. I18N is a more general problem, and it seems like a more general solution is what you want.
That said, to the best of my knowledge, I18N and L10N are not a very well explored areas of Haskell development.
This page suggestions some methods:
http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs
What template system are you trying to use?
Also, if you have suggestions for how Happstack could make I18N easier -- we'd be happy to hear them. But it seems like the problem is largely orthogonal to Happstack itself?
One area where Happstack could be involved is if you wished to use text encodings than UTF-8. That is mostly possible with Happstack already. But you would need a pretty compelling reason to not just stick with UTF-8 I think. (For example, interoperating with a legacy system that does not use UTF-8).
- jeremy
On Fri, Dec 9, 2011 at 6:20 PM, Asafe Ribeiro <asafe.hai.kai@gmail.com> wrote:
Does Happstack offer anything for internationalization ?
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber <greg@gregweber.info> wrote:
Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack.
Right. That sounds useful and easy to do.
Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack.
We already have Hamlet support in Happstack. But, it seems like that is not enough? We also need some stuff that is in Yesod.Message, etc?
In my ignorance, it seems like there are three pieces:
1. a little bit of framework/application specific code that detects/sets the language to use
2. a bunch of framework independent code that deals with mapping data-types to translated strings
3. some glue code that makes it easy to use #2 with a particular templating library
But, right now it seems that #2 is wrapped up in the yesod hierarchy even though it would be useful for any Haskell program that wants i18n? Or am I missing something?
Looks like you hit everything. You're correct, (2) is currently included in the yesod-core package, but could easily be moved out to a common, shared package. Any ideas on package/module name? Michael
On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman <michael@snoyman.com> wrote:
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber <greg@gregweber.info> wrote:
Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack.
Right. That sounds useful and easy to do.
Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack.
We already have Hamlet support in Happstack. But, it seems like that is not enough? We also need some stuff that is in Yesod.Message, etc?
In my ignorance, it seems like there are three pieces:
1. a little bit of framework/application specific code that detects/sets the language to use
2. a bunch of framework independent code that deals with mapping data-types to translated strings
3. some glue code that makes it easy to use #2 with a particular templating library
But, right now it seems that #2 is wrapped up in the yesod hierarchy even though it would be useful for any Haskell program that wants i18n? Or am I missing something?
Looks like you hit everything. You're correct, (2) is currently included in the yesod-core package, but could easily be moved out to a common, shared package. Any ideas on package/module name?
Michael
OK, it's a Shakespeare-like system, and it's for translations. Any objections to titus (and Text.Titus)? Michael
I would much prefer something like Text.Shakespeare.I18n and shakespeare-i18n or shakespeare-translate over requiring an extra mental translation step to understand the name. Especially since this is under the hood, there is no reason to try to give it a themed name. On Mon, Dec 12, 2011 at 5:01 AM, Michael Snoyman <michael@snoyman.com>wrote:
On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman <michael@snoyman.com> wrote:
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber <greg@gregweber.info> wrote:
Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack.
Right. That sounds useful and easy to do.
Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack.
We already have Hamlet support in Happstack. But, it seems like that is not enough? We also need some stuff that is in Yesod.Message, etc?
In my ignorance, it seems like there are three pieces:
1. a little bit of framework/application specific code that detects/sets the language to use
2. a bunch of framework independent code that deals with mapping data-types to translated strings
3. some glue code that makes it easy to use #2 with a particular templating library
But, right now it seems that #2 is wrapped up in the yesod hierarchy even though it would be useful for any Haskell program that wants i18n? Or am I missing something?
Looks like you hit everything. You're correct, (2) is currently included in the yesod-core package, but could easily be moved out to a common, shared package. Any ideas on package/module name?
Michael
OK, it's a Shakespeare-like system, and it's for translations.
Any objections to titus (and Text.Titus)?
Michael
I personally hate the thought of typing Shakespeare so often, but in this case you're right that it will be mostly under-the-hood. I'm fine either way. On Mon, Dec 12, 2011 at 11:54 AM, Greg Weber <greg@gregweber.info> wrote:
I would much prefer something like Text.Shakespeare.I18n and shakespeare-i18n or shakespeare-translate over requiring an extra mental translation step to understand the name. Especially since this is under the hood, there is no reason to try to give it a themed name.
On Mon, Dec 12, 2011 at 5:01 AM, Michael Snoyman <michael@snoyman.com> wrote:
On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman <michael@snoyman.com> wrote:
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber <greg@gregweber.info> wrote:
Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack.
Right. That sounds useful and easy to do.
Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack.
We already have Hamlet support in Happstack. But, it seems like that is not enough? We also need some stuff that is in Yesod.Message, etc?
In my ignorance, it seems like there are three pieces:
1. a little bit of framework/application specific code that detects/sets the language to use
2. a bunch of framework independent code that deals with mapping data-types to translated strings
3. some glue code that makes it easy to use #2 with a particular templating library
But, right now it seems that #2 is wrapped up in the yesod hierarchy even though it would be useful for any Haskell program that wants i18n? Or am I missing something?
Looks like you hit everything. You're correct, (2) is currently included in the yesod-core package, but could easily be moved out to a common, shared package. Any ideas on package/module name?
Michael
OK, it's a Shakespeare-like system, and it's for translations.
Any objections to titus (and Text.Titus)?
Michael
OK, the new package is on Github, under the hamlet repo: https://github.com/yesodweb/hamlet/tree/master/shakespeare-i18n Jeremy: Can you review the code and let me know if anything needs to change before it can be used by Happstack? Thanks, Michael On Mon, Dec 12, 2011 at 11:58 AM, Michael Snoyman <michael@snoyman.com> wrote:
I personally hate the thought of typing Shakespeare so often, but in this case you're right that it will be mostly under-the-hood. I'm fine either way.
On Mon, Dec 12, 2011 at 11:54 AM, Greg Weber <greg@gregweber.info> wrote:
I would much prefer something like Text.Shakespeare.I18n and shakespeare-i18n or shakespeare-translate over requiring an extra mental translation step to understand the name. Especially since this is under the hood, there is no reason to try to give it a themed name.
On Mon, Dec 12, 2011 at 5:01 AM, Michael Snoyman <michael@snoyman.com> wrote:
On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman <michael@snoyman.com> wrote:
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber <greg@gregweber.info> wrote:
Yesod guesses the user's locale from the request headers and allows it to be overridden - this could easily be ported to Happstack.
Right. That sounds useful and easy to do.
Yesod also directly supports putting i18n into Hamlet templates, which I think can also be done in Happstack. Yesod also provides a translator friendly veneer over Haskell data types- I think this could also be ported to different settings like Happstack.
We already have Hamlet support in Happstack. But, it seems like that is not enough? We also need some stuff that is in Yesod.Message, etc?
In my ignorance, it seems like there are three pieces:
1. a little bit of framework/application specific code that detects/sets the language to use
2. a bunch of framework independent code that deals with mapping data-types to translated strings
3. some glue code that makes it easy to use #2 with a particular templating library
But, right now it seems that #2 is wrapped up in the yesod hierarchy even though it would be useful for any Haskell program that wants i18n? Or am I missing something?
Looks like you hit everything. You're correct, (2) is currently included in the yesod-core package, but could easily be moved out to a common, shared package. Any ideas on package/module name?
Michael
OK, it's a Shakespeare-like system, and it's for translations.
Any objections to titus (and Text.Titus)?
Michael
participants (4)
-
Asafe Ribeiro -
Greg Weber -
Jeremy Shaw -
Michael Snoyman