2007/5/14, Ramiro Diaz Trepat <ramirodt at gmail.com>:
> Sorry Philippe, I am not sure what you mean.
>
> When you say "a custom Kom" I suppose you mean extensions like
> Norbert's.

A special version of the KomHttpServer

> But then, when you say "or get WideStrings".  What do you
> mean? from where?

In input fields and the strings you render.
WAKom: no encoding conversion, a Character is in fact only a byte,
that may or may not correspont to a character depending on your
encoding, for utf8 that's not the case
WAKomEncoded39: utf8 <-> new Squeak encoding conversion, a Character
is more or less a unicode character, this is "better" than Java/C#
because it's also true for character outside the BMP.

> What happened between 3.8 and 3.9?

Semantics of #unescapePercents changed.

> Why does Kom not work with utf8 in 3.9?

Maintainer is too busy to change two methods.

Cheers
Philippe

> There are plenty of Spanish, German, Swedish and French speakers in
> this list, what do you guys use in production?
> I suppose that Norbert's solution of adding hooks to translate strings
> everytime fixes the problem, but it also introduces a major
> performance penalty, because every string that comes and goes has to
> get translated (everytime, unless you cache the translations you
> make), and I guess these translations are not that cheap.
>
>
>
> On 5/14/07, Philippe Marschall <philippe.marschall at gmail.com> wrote:
> > No, you can either use a custom Kom or get WideStrings.
> >
> > 2007/5/14, Ramiro Diaz Trepat <ramirodt at gmail.com>:
> > > Wow...
> > > So I assume that mostly everyone not in an English speaking country
> > > with a Seaside application in production is using Squeak 3.8?
> > > Is that correct?
> > >
> > >
> > >
> > >
> > > On 5/14/07, Philippe Marschall <philippe.marschall at gmail.com> wrote:
> > > > 2007/5/14, Ramiro Diaz Trepat <ramirodt at gmail.com>:
> > > > > Indeed, probably another great thing it would  be if I could configure
> > > > > Seaside to directly send me utf8 strings from the input taken on a
> > > > > form´s entry fields.
> > > > > Is it possible?
> > > >
> > > > Yes, this is what WAKom is doing. Just remember that you also have to
> > > > send utf8 strings to Seaside. Unfortunately WAKom does not work on
> > > > Squeak 3.9.
> > > >
> > > > Cheers
> > > > Philippe
> > > >
> > > > >
> > > > > On 5/13/07, Ramiro Diaz Trepat <ramirodt at gmail.com> wrote:
> > > > > > Hello Todd and Marcelo,
> > > > > >    I am using Squeak 3.9.
> > > > > >    I know about how to set the encoding on postgres.  Indeed, utf8 is
> > > > > > the encoding I need on the database.
> > > > > >    What I want to know is if there is any place on the Postgres, Glorp
> > > > > > or MagritteGlorp packages where I could configure for the strings to
> > > > > > be translated to Squeak´s default (I think it´s iso).
> > > > > >    If I have, for example a Person on Glorp, and I want to set a last
> > > > > > name like mine Díaz (with an accented vowel), coming from a Magritte
> > > > > > form for instance, on the setter I translate it to UTF8 (#isoToUtf8)
> > > > > > before I assign it to my class i.var.  And it gets stored on the
> > > > > > database with no errors.  Later on, when Glorp "hydrates" my instance,
> > > > > > of course it brings a weird string like  "DÃ≈az", instead of "Díaz".
> > > > > >    Of course I would love that conversion to happen automatically with
> > > > > > a little configuration.
> > > > > >    Otherwise, what are you guys doing?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 5/13/07, marcelo Cortez <jmdc_marcelo at yahoo.com.ar> wrote:
> > > > > > > Ramiro
> > > > > > >
> > > > > > >  I'm postgres user , i hope help you , postgres
> > > > > > > encondig can be configurated at database creation,
> > > > > > > postgres client can configurated using statements
> > > > > > > SET CLIENT_ENCODING TO 'value';
> > > > > > > take a look at
> > > > > > > http://www.postgresql.org/docs/8.2/static/multibyte.html
> > > > > > > best regards
> > > > > > > mdc
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --- Ramiro Diaz Trepat <ramirodt at gmail.com> escribió:
> > > > > > >
> > > > > > > > Well... sorry for building this thread by myself.
> > > > > > > > The issue now is that conversion does not happen
> > > > > > > > automatically.  I can
> > > > > > > > properly store a string on a UTF8 database, by
> > > > > > > > previously converting
> > > > > > > > it using #isoToUtf8.
> > > > > > > > But when strings come back after a query (using
> > > > > > > > Glorp), they are not
> > > > > > > > converted to iso, and hence they show all screwed
> > > > > > > > up.
> > > > > > > > Is there any place in Glorp or the Postgres driver
> > > > > > > > to configure the
> > > > > > > > encoding of the underlying database for these
> > > > > > > > conversions to happen
> > > > > > > > automatically?
> > > > > > > > Thanks !
> > > > > > > >
> > > > > > > > r.
> > > > > > > >
> > > > > > > >
> > > > > > > > On 5/13/07, Ramiro Diaz Trepat <ramirodt at gmail.com>
> > > > > > > > wrote:
> > > > > > > > > Sorry, it does work.
> > > > > > > > > I don´t know what happend.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 5/13/07, Ramiro Diaz Trepat
> > > > > > > > <ramirodt at gmail.com> wrote:
> > > > > > > > > > I was unable to use databases with UTF8
> > > > > > > > encoding, only SQL_ASCII
> > > > > > > > > > encoding worked for me.
> > > > > > > > > > is it something trivial to configure that I did
> > > > > > > > not see or is it a limitation?
> > > > > > > > > > Thanks
> > > > > > > > > >
> > > > > > > > > > r.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > __________________________________________________
> > > > > > > Preguntá. Respondé. Descubrí.
> > > > > > > Todo lo que querías saber, y lo que ni imaginabas,
> > > > > > > está en Yahoo! Respuestas (Beta).
> > > > > > > ¡Probalo ya!
> > > > > > > http://www.yahoo.com.ar/respuestas
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>