Am Samstag, 6. Oktober 2007 schrieb Tom Lane:
> It's not real clear to me whether, on a Unix machine, there is even
> supposed to be any difference between setting LC_TIME=es_ES.iso88591 and
> setting it to es_ES.utf8. Since nl_langinfo(CODESET) is supposedly
> determined only by LC_CTYPE, you cou
Am Sonntag, 7. Oktober 2007 schrieb Gregory Stark:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
> > Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
> > could argue that strftime's results should be in that encoding
> > regardless,
>
> It seems to me we aren't actually using st
Gregory Stark wrote:
> It seems to me we aren't actually using strftime any more in any case. We seem
> to be using things like _("Monday") instead. Except in my tests I don't get
> any French dates even when the server is started in French mode. I think we
> just don't have localizations for thos
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
>> could argue that strftime's results should be in that encoding regardless,
> It seems to me we aren't actually using strftime any more
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
> could argue that strftime's results should be in that encoding regardless,
It seems to me we aren't actually using strftime any more in any case. We seem
to be using things like _(
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I tried on both a UTF8 and Latin1 terminal and it works OK in all cases.
The cases that would be interesting involve to_char's locale-specific
format codes (eg Dy) along with LC_TIME settings that are deliberately
incompatible with the database encoding
Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
>>> Actually I was thinking about things like formatting.c which take
>>> localized
>>> strings and return them as data which can end up in the database. If
>>> they're
>>> in the wrong encoding then they'll be invalidly encoded strings in the
>>>
Alvaro Herrera wrote:
Actually I was thinking about things like formatting.c which take localized
strings and return them as data which can end up in the database. If they're
in the wrong encoding then they'll be invalidly encoded strings in the
database.
Oh, I didn't think of that. Let
Gregory Stark wrote:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >
> >> So does the _() macro automatically recode it to the current server
> >> encoding?
> >
> > Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
> > If I have a different cli
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> So does the _() macro automatically recode it to the current server encoding?
>
> Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
> If I have a different client_encoding and get a NOTICE, then both th
Gregory Stark <[EMAIL PROTECTED]> writes:
> So does the _() macro automatically recode it to the current server encoding?
>From the gettext manual:
---
gettext not only looks up a translation in a message catalog. It also
converts the translation on the fly to the desired output character
set. T
Gregory Stark wrote:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >>
> >> Reading the commit message about the TZ encoding issue I'm curious why this
> >> isn't a more widespread problem. How does gettext now what encoding we want
> >> messages in? How do we prevent
Gregory Stark <[EMAIL PROTECTED]> writes:
> Reading the commit message about the TZ encoding issue I'm curious why this
> isn't a more widespread problem. How does gettext now what encoding we want
> messages in? How do we prevent things like to_char(now(),'month') from
> producing strings in an en
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>>
>> Reading the commit message about the TZ encoding issue I'm curious why this
>> isn't a more widespread problem. How does gettext now what encoding we want
>> messages in? How do we prevent things like to_char(now(),'month')
Gregory Stark wrote:
>
> Reading the commit message about the TZ encoding issue I'm curious why this
> isn't a more widespread problem. How does gettext now what encoding we want
> messages in? How do we prevent things like to_char(now(),'month') from
> producing strings in an encoding different f
15 matches
Mail list logo
