Re: Patch to reduce the number of messages to translate

The attached patch reduces the number of messages to translate by using
a parameter to regroup similar messages.
For example "Bad short" => "Bad {0}" with "short" as argument.
This way "Bad int" becomes "Bad {0}" we have reduced the number of
messages to translate.

On Fri, 17 Dec 2004, Xavier Poinsard wrote:

> The attached patch reduces the number of messages to translate by using
> a parameter to regroup similar messages.
> For example "Bad short" => "Bad {0}" with "short" as argument.
> This way "Bad int" becomes "Bad {0}" we have reduced the number of
> messages to translate.
>

Is this a good idea? I'm willing to take your word as someone who
actually does translations, but I wanted to confirm that parameterizing
the message in this way won't cause translation problems. Is this only a
reasonable thing to do because the existing error message text isn't all
that informative?

Kris Jurka

Kris Jurka wrote:
> > For example "Bad short" => "Bad {0}" with "short" as argument.
> > This way "Bad int" becomes "Bad {0}" we have reduced the number of
> > messages to translate.
>
> Is this a good idea? I'm willing to take your word as someone who
> actually does translations, but I wanted to confirm that
> parameterizing the message in this way won't cause translation
> problems.

I'm pretty sure it will. Splitting the adjective away from the noun
isn't a good idea.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Kris Jurka wrote:
>
>>>For example "Bad short" => "Bad {0}" with "short" as argument.
>>>This way "Bad int" becomes "Bad {0}" we have reduced the number of
>>>messages to translate.
>>
>>Is this a good idea? I'm willing to take your word as someone who
>>actually does translations, but I wanted to confirm that
>>parameterizing the message in this way won't cause translation
>>problems.
>
>
> I'm pretty sure it will. Splitting the adjective away from the noun
> isn't a good idea.
>

I typed quickly the message with my patch ; the changes are the following :

- "Conversion of box failed: {0}." => "Conversion of {1} failed: {0}."
with box,circle,line,lseg,point

- "The JVM claims not to support the ASCII encoding." => "The JVM claims
not to support the {0} encoding."
with ASCII,UTF-8

- "Bad byte: {0}" => "Bad {1}: {0}"
with byte,short,int,long,BigDecimal,float,double,date

- "Cannot cast an instance of {0} to Types.BIT" => "Cannot cast an
instance of {0} to {1}"
with Types.BIT,Types.OTHER

As you can see, the new parameters have all the same gender : they are
all java type names or encodings. Since they have the same gender, the
adjective will be the same for all.
As far as I know, this type of replacement can't be a problem.
If the new parameters were real nouns with different genders, it would
be a problem, but not in these cases.
No ?

Xavier Poinsard wrote:
> As you can see, the new parameters have all the same gender : they
> are all java type names or encodings.

What makes you think that all Java type names have the same gender in
all languages?

You could rephrase the messages like this:

invalid input value for type "{0}": {1}

Then there should be no problem.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Xavier Poinsard wrote:
>
>>As you can see, the new parameters have all the same gender : they
>>are all java type names or encodings.
>
>
> What makes you think that all Java type names have the same gender in
> all languages?

Because we implicitly refer to them as type "java type name".

>
> You could rephrase the messages like this:
>
> invalid input value for type "{0}": {1}
>
> Then there should be no problem.

I will follow your advice to make it explicit.

Here is the modified patch with hopefully no adjective problems.

The changes are now the following :

- "Conversion of box failed: {0}." => "Conversion to type {1} failed: {0}."
with box,circle,line,lseg,point

- "The JVM claims not to support the ASCII encoding." => "The JVM claims
not to support the {0} encoding."
with ASCII,UTF-8

- "Bad byte: {0}" => "Bad value for type {1}: {0}"
with byte,short,int,long,BigDecimal,float,double,date

- "Cannot cast an instance of {0} to Types.BIT" => "Cannot cast an
instance of {0} to type {1}"
with Types.BIT,Types.OTHER

Peter Eisentraut wrote:
> You could rephrase the messages like this:
>
> invalid input value for type "{0}": {1}
>
> Then there should be no problem.
>

By replacing type names we are creating a potential confusion.
A translator who is not familiar with the code may translate
type names like "long" or "integer".

I am for leaving the strings as they are. Translators are
copy+paste then edit the messages anyways.

Best regards,
Nicolai

On Tue, 21 Dec 2004 14:47:41 +0100, Xavier Poinsard <xpoinsard(at)free(dot)fr> wrote:
> Here is the modified patch with hopefully no adjective problems.
>
> The changes are now the following :
>
> - "Conversion of box failed: {0}." => "Conversion to type {1} failed: {0}."
> with box,circle,line,lseg,point
>
> - "The JVM claims not to support the ASCII encoding." => "The JVM claims
> not to support the {0} encoding."
> with ASCII,UTF-8
>
> - "Bad byte: {0}" => "Bad value for type {1}: {0}"
> with byte,short,int,long,BigDecimal,float,double,date
>
> - "Cannot cast an instance of {0} to Types.BIT" => "Cannot cast an
> instance of {0} to type {1}"
> with Types.BIT,Types.OTHER
>
> Peter Eisentraut wrote:
> > You could rephrase the messages like this:
> >
> > invalid input value for type "{0}": {1}
> >
> > Then there should be no problem.
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>
>
>

Nicolai Tufar wrote:
> By replacing type names we are creating a potential confusion.
> A translator who is not familiar with the code may translate
> type names like "long" or "integer".

The type names are not marked for translation (or at least they
shouldn't be).

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Just discovered a small typo :

Index: TimestampUtils.java
===================================================================
RCS file:
/usr/local/cvsroot/pgjdbc/pgjdbc/org/postgresql/jdbc2/TimestampUtils.java,v
retrieving revision 1.9
diff -u -r1.9 TimestampUtils.java
--- TimestampUtils.java 22 Dec 2004 09:23:57 -0000 1.9
+++ TimestampUtils.java 22 Dec 2004 11:32:35 -0000
@@ -158,7 +158,7 @@
}
}
} catch (NumberFormatException nfe) {
- throw new PSQLException(GT.tr("Bad value for type {0} :
{1}}", new Object[]{type,s}), PSQLState.BAD_DATETIME_FORMAT, nfe);
+ throw new PSQLException(GT.tr("Bad value for type {0} :
{1}", new Object[]{type,s}), PSQLState.BAD_DATETIME_FORMAT, nfe);
}

return nanos;

On Wed, 22 Dec 2004, Xavier Poinsard wrote:

> Just discovered a small typo :

Thanks. Fixed.

Kris Jurka