[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments (5)

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.



On Sun, Apr 21, 2002 at 12:57:37AM +0200, 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.
> 
I agree.

> 2) not enough opaqueness - specificly, the whole part on creating bundles
> from assoc lists isn't imho a good idea. Also, declare-bundle, being a
> "global" mutator should probably be named differently.
Do you have any suggestions for a more appropriate name?  As to
opaqueness, the alternative is clearly to define messages individually 
into the bundle, but this has a couple of problems.  First, it doesn't
allow an implementation to optimize the bundle in any way.  If the 
messages must be added individually, then the underlying system must
be able to accept these messages and store them at any time, as opposed 
to being able to process them in bulk.  Secondly, (at a more conceptual 
level), it breaks up the idea of a set of messages defining a 
'translation'.  

> 
> 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.
> 
I'm at a loss to think of many examples of this.  The best I can imagine 
is a network server serving clients in multiple locales.  At any rate, I 
think this is quite trivially solved by leaving current-locale alone and 
defining a new function that is able to set the current locale.  Making 
'current-locale' a parameter that is set by the Scheme system is the 
obvious way.

> 4) the language/country system has its problems aswell (want to localise
> to latin?), and these would more or less be resolved by using a string
> instead. Also, having just language and country doesn't solve the problem
> that the encoding may also need to be present - for example
> fr_FR.ISO_8859-1 and fr_FR.UTF-8 will very probably need to be
> distinguishable.
We can generalize the locale as being a list of symbols, from greatest 
to least significant.  (country-code language-code encoding) could be 
standardized, with any succeeding elements optional and up for 
interpretation.

> 
> 5) the process - I think its wrong to depend on another srfi (srfi 28 in
> this case) that is not yet final.

SRFI-28 was created solely to support SRFI-29.  It was kept logically 
separate in order to allow a standardization of basic format 
functionality without having to implement all of SRFI-29.  If SRFI-28 is 
rejected, then we can simply roll that specification into 29, but in 
such a case there are larger issues anyway (such as why its impossible 
to standardize on the very simple functionality of 28).

	Scott

Attachment: pgpjbqd0Re9B1.pgp
Description: PGP signature