-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
5.0
-
generic
-
generic
Our Java development uses ResourceBundle to separate language specific
content from Java sources, and MessageFormat to express dynamic
(parametrized) messages. Furthermore, we are using formatting
patterns as specified in the MessageFormat API.
Our translation workflow feeds property files into a translation
system, which is used by employees of external agencies to translate
texts on a line-by-line basis. This way, all our texts get translated
into many languages. Needless to say, that these translators are no
(Java) programmers. They are directed to simply pass all formatting
content (like a {0} argument) through to their target language variant.
At the output side of the translation system, these target variants
are again stored in property files.
Both - MessageFormat and ResourceBundle - rely on entries, that are
stored in property files. However, certain characters are treated
differently, depending on their use. For example, the apostrophe (')
character must be duplicated in a property file, to be visible in a
text (C''est la vie). On the other hand, a single apostrophe is also
valid, if used in the context of a format pattern.
A translator usually can't know this rule, since it is specific to
Java. In fact, he can't even adapt to it, since he can never be sure,
that a given line belongs to a Java program. Actually, there is
sophisticated technology (translation memories / proposal pools) built
into a translation system, that should relief translators from translating
the same text over and over again. However, since Java''s texts would
always look slightly different than those of other programming languages,
this technology would not be of much help anymore.
This is a rather important issue, since in languages like French, the
apostrophe is a frequently used character. In contrast to English, the
apostrophe in French cannot be replaced by a more elaborate notation.
I'm writing this message, since we are probably not the only ones who
fully separate translation from development. I would be interested
to learn, how other parties handle this problem, or how to proceed
on this I18N issue.
content from Java sources, and MessageFormat to express dynamic
(parametrized) messages. Furthermore, we are using formatting
patterns as specified in the MessageFormat API.
Our translation workflow feeds property files into a translation
system, which is used by employees of external agencies to translate
texts on a line-by-line basis. This way, all our texts get translated
into many languages. Needless to say, that these translators are no
(Java) programmers. They are directed to simply pass all formatting
content (like a {0} argument) through to their target language variant.
At the output side of the translation system, these target variants
are again stored in property files.
Both - MessageFormat and ResourceBundle - rely on entries, that are
stored in property files. However, certain characters are treated
differently, depending on their use. For example, the apostrophe (')
character must be duplicated in a property file, to be visible in a
text (C''est la vie). On the other hand, a single apostrophe is also
valid, if used in the context of a format pattern.
A translator usually can't know this rule, since it is specific to
Java. In fact, he can't even adapt to it, since he can never be sure,
that a given line belongs to a Java program. Actually, there is
sophisticated technology (translation memories / proposal pools) built
into a translation system, that should relief translators from translating
the same text over and over again. However, since Java''s texts would
always look slightly different than those of other programming languages,
this technology would not be of much help anymore.
This is a rather important issue, since in languages like French, the
apostrophe is a frequently used character. In contrast to English, the
apostrophe in French cannot be replaced by a more elaborate notation.
I'm writing this message, since we are probably not the only ones who
fully separate translation from development. I would be interested
to learn, how other parties handle this problem, or how to proceed
on this I18N issue.
- relates to
-
JDK-4616469 [Fmt-Me] java messages will not allow argument with apostrophe
-
- Closed
-