Обсуждение: 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@free.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