FreeTDS Development Group

["Eric Deutsch" <edeutsch AT systemsbiology.org>]

> From: James K. Lowden [mailto:jklowden AT schemamania.org]
> 
> On Fri, 10 Jan 2003 10:42:17 -0600, Steve Langasek
<vorlon AT netexpress.net>
> wrote:
> >
> > Is there such a thing as iso_15 in the char set list (for
iso-8859-15)?
> 
> Not in Sybase 11.9.2.3, no.
> 
> > > I said that the value of LANG was controlled by ISO standards.
That's
> > > not quite true.  It *should* be controlled that way, but some OS
> > > vendors use different values.  We have no way to cope with that
except
> > > by adding sections to locales.conf for every conceivable key.
Also,
> > > the setlocale(3) function is standardized by ANSI, so we should
use
> > > that instead of reading the LANG variable directly.
> >
> > Well, I think we should be able to get rid of locales.conf
altogether in
> > the long run, and just use libc i18n facilities to figure everything
out
> > from the locale.  I've started work in this direction, but it needs
> > polishing before I'm ready to commit it.
> 
> I don't think locales.conf has ever done anyone any good.  We don't
have
> many non-English speakers who regularly participate here, and I can't
> think of a single time anyone ever said, "Oh, locales.conf saved the
> day!".  No one's ever sent a patch for a new section.  Frediano
doesn't

locales.conf saved the day!

I used to have to insert my strftime string "%Y-%m-%d %H:%M:%S" into the
source code before locales.conf.  I may the only American who thinks ISO
date format is a good idea, but having it encoded in locales.conf is
good for me.  Admittedly, it could be put elsewhere, but it does make
sense here.  Don't eliminate sysadmin-settable date formats, please!


> need it, because he uses TDS 7/8, which don't send charset information
to
> the server.  Freddy, are you getting your error messages from the
server
> in English?  Or don't you make any mistakes?  :)
> 
> In short, I think locales.conf has yet to be used by anyone.  We can
> eliminate it now.  :(

eek!

> Then we have the problems of L10N and the LANG rat's nest.  It could
be
> two characters, or five, or the English name of the language (eg,
> "Spanish").  It might have a charset attached to it, delimited by '.'
or
> '@' or no doubt something else.  Futhermore, there's no rule that LANG
has
> to be populated; the same information could come from ~./login_conf or
> something.
> 
> I would like to use setlocale(3), but ANSI standardized the signature
> while saying nothing about its inputs or outputs.  It gets us a step
away
> from $LANG, but only a small amount closer to knowing what character
set
> and language to tell the server to use.
> 
> 
> It's tempting to add "server charset" and "server language" to
> freetds.conf and go home.  But I hate to ignore the work of people who
go
> to the trouble of setting up their locale correctly.
> 
> What to do?
> 
> I propose we address this in 4 steps:
> 
> 1.  Get the output of "setlocale(LC_ALL,NULL)"
> 2.  Convert that into 3 cannonical IDs
> 3.  Override from freetds.conf, if provided
> 4.  Convert cannonical IDs to vendor labels.
> 
> Steps 1, 3, and 4 are easy.
> 
> Step #2 should be a single function, or at most a library with a
single
> public function:
> 
> typedef struct {
>       char language[4];       /* ISO 639-2 */
>       char country[4];        /* ISO 3166 */
>       char character_set[20]; /* Gnu libiconv */
> } LOCALE_PARTS;
> 
> int parse_locale( const char locale[], LOCALE_PARTS *parts );
> 
> The parse_locale is an inference engine, an example of Larry Wall's
dictum
> to "be liberal in what you accept, and conservative in what you emit".
It
> doesn't query the OS; it heuristically parses the string its given.
It
> returns a count of how many things it matched, filling indeterminate
> fields will nulls.
> 
> Then I say we place it in the public domain so no one has to worry
about
> this again.
> 
> I think I can have version 1 ready tomorrow.  In case I've lost my
mind, I
> sure hope someone's listening.
> 
> --jkl
> 
> 
> 
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds