-
Bug
-
Resolution: Fixed
-
P2
-
1.4.0
-
hopper
-
generic
-
generic
The message resources divided on both sides of the variable and
the message resources divided due to the long message are hard to
hold a whole image of the message without a comment and there is
a possibility of becoming the cause of a mistranslation.
And also, the message resources divided on both sides of the
variable do not have the variable itself and it may be troubled
by judgment where it is in.
Ex. from Converter.java:
The following case may be judged easily that a variable exists between
"about_dialog.info" and "about_dialog.info2" and the resources will be
combined.
{ "about_dialog.info", "Java(tm) Plug-in HTML Converter v" },
{ "about_dialog.info2", "\nCopyright 2001 Sun Microsystems, Inc." },
It's actually "Java(tm) Plug-in HTML Converter v<version#>\nCopyright 2001 Sun Microsystems, Inc.".
The following case can be judged somehow because there are parentheses.
{ "notemplate_dialog.info0", "The default template file ("},
{ "notemplate_dialog.info1", ") could" + newline + "not be found. Either it is not in the classpath" + newline +
"or it is not in the working directory."},
However, the location of the variable is fixed so there is no flexibility
at the time of translation.
The following case can't be judged whether a variable exists or not
without the source code and also there is no flexibility for translation.
{ "static.versioning.radio.button", "Use only Java "},
When using a variable especially in an itemized statement, it may
become explanation unnatural at the time of translation.
Therefore, the location of the variable should be clarified by using '{n}'.
More natural translation can be performed by doing so.
###@###.### 2001-09-27
the message resources divided due to the long message are hard to
hold a whole image of the message without a comment and there is
a possibility of becoming the cause of a mistranslation.
And also, the message resources divided on both sides of the
variable do not have the variable itself and it may be troubled
by judgment where it is in.
Ex. from Converter.java:
The following case may be judged easily that a variable exists between
"about_dialog.info" and "about_dialog.info2" and the resources will be
combined.
{ "about_dialog.info", "Java(tm) Plug-in HTML Converter v" },
{ "about_dialog.info2", "\nCopyright 2001 Sun Microsystems, Inc." },
It's actually "Java(tm) Plug-in HTML Converter v<version#>\nCopyright 2001 Sun Microsystems, Inc.".
The following case can be judged somehow because there are parentheses.
{ "notemplate_dialog.info0", "The default template file ("},
{ "notemplate_dialog.info1", ") could" + newline + "not be found. Either it is not in the classpath" + newline +
"or it is not in the working directory."},
However, the location of the variable is fixed so there is no flexibility
at the time of translation.
The following case can't be judged whether a variable exists or not
without the source code and also there is no flexibility for translation.
{ "static.versioning.radio.button", "Use only Java "},
When using a variable especially in an itemized statement, it may
become explanation unnatural at the time of translation.
Therefore, the location of the variable should be clarified by using '{n}'.
More natural translation can be performed by doing so.
###@###.### 2001-09-27
- relates to
-
JDK-5003795 message resources in Deployment.java should include variable(s) in itself
- Resolved
-
JDK-5004510 message resources in JarSignerResources.java should include variable(s) in itsel
- Resolved
-
JDK-4653292 some incomplete messages are in HtmlConverter
- Closed