Happstack internationalization and localization

newer
Error catching in WAI and Warp

older
ResponseEnumerator

Asafe Ribeiro

9 Dec 2011 9 Dec '11

7:20 p.m.

Does Happstack offer anything for internationalization ?

Show replies by date

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 wrote:

...

Does Happstack offer anything for internationalization ?

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Greg Weber

10 Dec 10 Dec

5:18 a.m.

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 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 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

Jeremy Shaw

1:31 p.m.

On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber 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 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 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

Michael Snoyman

2:56 p.m.

On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw wrote:

...

On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber 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

Michael Snoyman

12 Dec 12 Dec

3:01 a.m.

On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman wrote:

...

On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw wrote:

...
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber 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

Greg Weber

4:54 a.m.

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 wrote:

...

...
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw wrote:

...
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber 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

On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman wrote: 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

Michael Snoyman

4:58 a.m.

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 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 wrote:

...
On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman wrote:

...
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw wrote:

...
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber 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

Michael Snoyman

14 Dec 14 Dec

1:32 a.m.

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 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 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 wrote:

...
On Sat, Dec 10, 2011 at 9:56 PM, Michael Snoyman wrote:

...
On Sat, Dec 10, 2011 at 8:31 PM, Jeremy Shaw wrote:

...
On Sat, Dec 10, 2011 at 4:18 AM, Greg Weber 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

4906

Age (days ago)

4910

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Asafe Ribeiro
Greg Weber
Jeremy Shaw
Michael Snoyman

Happstack internationalization and localization

tags

participants (4)