Обсуждение: Potential to_char localization bug
Here is a localization bug waiting to happen:
static char *
localize_month_full(int index)
{ char *m = NULL;
switch (index) { case 4: m = _("May"); break;
static char *
localize_month(int index)
{ char *m = NULL;
switch (index) { case 4: m = _("May"); break;
Haven't thought of a fix yet.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
> Here is a localization bug waiting to happen:
>
> static char *
> localize_month_full(int index)
> {
> char *m = NULL;
>
> switch (index)
> {
> case 4:
> m = _("May");
> break;
>
>
> static char *
> localize_month(int index)
> {
> char *m = NULL;
>
> switch (index)
> {
> case 4:
> m = _("May");
> break;
>
>
> Haven't thought of a fix yet.
Build a table/function to return short names for full month names, and
use full-length month names on localize_month?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Peter Eisentraut skrev:
> case 4:
> m = _("May");
> break;
>
>
> Haven't thought of a fix yet.
A common way is to use something of the form
m = _("S:May") + 2;
and a comment above (that is copied to the .po file) explaining that the
S: should be in the translated string as well.
/Dennis
Dennis Bjorklund wrote:
> Peter Eisentraut skrev:
> > case 4:
> > m = _("May");
> > break;
> >
> >
> > Haven't thought of a fix yet.
>
> A common way is to use something of the form
>
> m = _("S:May") + 2;
>
> and a comment above (that is copied to the .po file) explaining that the
> S: should be in the translated string as well.
OK, I am ready to admit I am lost. What is the problem here?
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
> Dennis Bjorklund wrote:
> > Peter Eisentraut skrev:
> > > case 4:
> > > m = _("May");
> > > break;
> > >
> > >
> > > Haven't thought of a fix yet.
> >
> > A common way is to use something of the form
> >
> > m = _("S:May") + 2;
> >
> > and a comment above (that is copied to the .po file) explaining that the
> > S: should be in the translated string as well.
>
> OK, I am ready to admit I am lost. What is the problem here?
The problem is that "May" is both a month name, and the shorthand for a
month name. So there is no way to determine which is which for the
translation machinery. (Incidentally I noticed that what I proposed
doesn't fix the problem, in fact it doesn't work at all).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Bruce Momjian skrev:
>> A common way is to use something of the form
>>
>> m = _("S:May") + 2;
>>
>> and a comment above (that is copied to the .po file) explaining that the
>> S: should be in the translated string as well.
>
> OK, I am ready to admit I am lost. What is the problem here?
That May is the same word in english both as a full name and a short
name. Both used _("May") and thus both the short name and full name has
to be translated into the same word in other languages as well.
/Dennis
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Dennis Bjorklund wrote:
> > > Peter Eisentraut skrev:
> > > > case 4:
> > > > m = _("May");
> > > > break;
> > > >
> > > >
> > > > Haven't thought of a fix yet.
> > >
> > > A common way is to use something of the form
> > >
> > > m = _("S:May") + 2;
> > >
> > > and a comment above (that is copied to the .po file) explaining that the
> > > S: should be in the translated string as well.
> >
> > OK, I am ready to admit I am lost. What is the problem here?
>
> The problem is that "May" is both a month name, and the shorthand for a
> month name. So there is no way to determine which is which for the
> translation machinery. (Incidentally I noticed that what I proposed
> doesn't fix the problem, in fact it doesn't work at all).
Thanks, I get it now. ;-)
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
> > > case 4:
> > > m = _("May");
> > > break;
> > >
> > >
> > > Haven't thought of a fix yet.
> >
> > A common way is to use something of the form
> >
> > m = _("S:May") + 2;
You need to make sure the prefix in the translation is also 2 bytes.
(Not possible with UTF32, so may be better to use _("Abr:May") + 4 ?)
> >
> > and a comment above (that is copied to the .po file)
> explaining that the
> > S: should be in the translated string as well.
>
> OK, I am ready to admit I am lost. What is the problem here?
That you can only translate "May" once, but you need an abbreviated and
a long translation.
(And that you don't want an en.po file, cause that would be the standard
approach
using "_May")
Andreas
Zeugswetter Andreas ADI SD wrote:
> > > m = _("S:May") + 2;
>
> You need to make sure the prefix in the translation is also 2 bytes.
All backend encodings are ASCII compatible.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Dennis Bjorklund wrote:
> A common way is to use something of the form
>
> m = _("S:May") + 2;
>
> and a comment above (that is copied to the .po file) explaining that
> the S: should be in the translated string as well.
Nice idea. Fixed.
It took a while to find a language for testing where this actually
matters. :)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
> Dennis Bjorklund wrote:
>> A common way is to use something of the form
>>
>> m = _("S:May") + 2;
>>
> Nice idea. Fixed.
But not for 8.2 I assume? Or did you fix the translations as well. It's
not very nice if every month is translated except May.
/Dennis
Peter Eisentraut <peter_e@gmx.net> writes:
> Dennis Bjorklund wrote:
>> A common way is to use something of the form
>> m = _("S:May") + 2;
> Nice idea. Fixed.
This will require the .po files to be updated, whether or not they need
to make the distinction. Will that happen before we need to wrap 8.2
final (probably Friday)?
regards, tom lane
Tom Lane wrote: > This will require the .po files to be updated, whether or not they > need to make the distinction. Will that happen before we need to > wrap 8.2 final (probably Friday)? I've just fixed them all by hand, so there is no worry. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > > This will require the .po files to be updated, whether or not they > > need to make the distinction. Will that happen before we need to > > wrap 8.2 final (probably Friday)? > > I've just fixed them all by hand, so there is no worry. > Oh, my fault :). I knew about that all the time but don't mention it thinking we could substitute that code with the lc_time code (that certainly doesn't have the bug). Thanks for fixing it. -- Euler Taveira de Oliveira http://www.timbira.com/