This page is part of the web mail archives of SRFI 29 from before July 7th, 2015. The new archives for SRFI 29 contain all messages, not just those from before July 7th, 2015.
sander wrote:
1) gettext - mandating that it must use gettext is imho no good - even if these days the situation is better for people with no resources to re-implement it - is probably not a good idea. Those who just want to use gettext can do so using a library binding, and it would imho be pretty pointless to have that as a SRFI . gettext will also not be available or appropriate in all places where scheme can be used.
Nobody has suggested mandating gettext. I'm just saying it seems like a really bad idea to design a localization srfi without making sure that it is compatible with and plays nicely with gettext.
3) one central locale - I think having a "one locale at a time" system is fundamentaly broken, and its not just something i think. It is very limiting and assumes just one use case. Once that use case no longer fits (say you want to use threads and some threads want to use a different locale - oops!) you end up re-implementing the system.
You can still have a notion of "current locale", as long as "current" can be thread-local. -- --Per Bothner per@xxxxxxxxxxx http://www.bothner.com/per/