I did some research and can report what was happening with *printf and
libintl.
Basically, there are two versions of libintl. Versions before 0.13
(November 2003) use the libc version of *printf to handle printing of
translation strings. Version 0.13 and after provide their own *printf
functions which understand %$ functionality. The 0.13 change is:
- C format strings with positions, as they arise when a translator needs to
reorder a sentence, are now supported on all platforms. On those few
platforms (NetBSD and Woe32) for which the native printf()/fprintf()/...
functions don't support such format strings, replacements are provided
through <libintl.h>.
In addition, reports in April 2003 that libintl did not compile with our
custom pg *printf functions on Win32 caused us to disable pg *printf
functions on Win32. The assumption was that libintl had a special
*printf version to handle %$, but in fact only post-0.13 had that
feature.
If we had built pginstaller with a post-0.13 libintl, pginstaller would
have handled %$ translation strings fine. The problem was that
pginstaller was built using pre-0.13 libintl, meaning it was using the
Win32 *printf, which doesn't understand %$.
Added to this was that our *printf functions had a bug that made %$ not
work.
Aside from fixing our own *printf, we have two ways of fixing this,
either use a post-0.13 version of libintl, or use the pre-0.13 libintl.
Based on risk analysis, we have chosen to continue using the same
pre-0.13 version of libintl, and to rely on our pg *printf functions to
handle %$. We hope to put out a new pginstaller in the next few days
for testing to make sure this has been resolve before releasing 8.1.1.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >
> >>However, a very simple test shows that the libintl printf does indeed do
> >>%m$ processing:
> >>...
> >>So the next question is why isn't it working in the build.
> >>
> >>
> >
> >Is it possible that the build that was being complained of was using our
> >previous, very-broken snprintf.c?
> >
> >
> >
> >
>
> There's currently a config setting that is supposed to inhibit its use
> on Windows. I am quite confused.
>
> What is more, when I set the locale of my machine to Turkish and run the
> installer project's 8.1_RC1 which I happen to have installed there, and
> set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
>
> LOG: "$s" veritaban?n transaction ID warp limiti $u
>
> I see this:
>
> LOG: "2147484146" veritabanin transaction ID warp limiti postgres
>
> So I'm inclined to think there might be something odd about his setup and
> maybe we aren't quite so broken after all.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
