Thread: 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.
Attachment
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.
>
Attachment
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 <[email protected]> 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