Potential to_char localization bug

Started by Peter Eisentrautabout 19 years ago14 messages
#1Peter Eisentraut
peter_e@gmx.net

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/

#2Alvaro Herrera
alvherre@commandprompt.com
In reply to: Peter Eisentraut (#1)
Re: Potential to_char localization bug

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

#3Dennis Bjorklund
db@zigo.dhs.org
In reply to: Peter Eisentraut (#1)
Re: Potential to_char localization bug

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

#4Bruce Momjian
bruce@momjian.us
In reply to: Dennis Bjorklund (#3)
Re: Potential to_char localization bug

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. +

#5Alvaro Herrera
alvherre@commandprompt.com
In reply to: Bruce Momjian (#4)
Re: Potential to_char localization bug

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.

#6Dennis Bjorklund
db@zigo.dhs.org
In reply to: Bruce Momjian (#4)
Re: Potential to_char localization bug

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

#7Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#5)
Re: Potential to_char localization bug

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. +

#8Zeugswetter Andreas ADI SD
ZeugswetterA@spardat.at
In reply to: Bruce Momjian (#4)
Re: Potential to_char localization bug

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

#9Peter Eisentraut
peter_e@gmx.net
In reply to: Zeugswetter Andreas ADI SD (#8)
Re: Potential to_char localization bug

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/

#10Peter Eisentraut
peter_e@gmx.net
In reply to: Dennis Bjorklund (#3)
Re: Potential to_char localization bug

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/

#11Noname
db@zigo.dhs.org
In reply to: Peter Eisentraut (#10)
Re: Potential to_char localization bug

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

#12Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#10)
Re: Potential to_char localization bug

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

#13Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#12)
Re: Potential to_char localization bug

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/

In reply to: Peter Eisentraut (#13)
Re: Potential to_char localization bug

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/