Community
Participate
Working Groups
Summary: Java error messages that are displayed in the Task List or status line have double apostrophes in the translated versions. This occurs because the translators have assumed that MessageFormat would be used for messages with substitution parameters, and it requires that single quotes be doubled. If the quote is not doubled, then the message is truncated. For example: errorMessage101=This parameter "{0}" doesn''t look right. A call to: MessageFormat.format(errorMessage101, (new String[] {"x"}) will correctly return "This parameter "x" doesn't look right." However, if the apostrophe is not doubled, the above returns "This parameter {0} doesn". This apparently is a well-known Java bug. A few weeks back, we discovered that the translators were not consistently specifying single quotes in the message files. Based on the assumption that MessageFormat would be used to insert parameters, we told them to put two single quotes if there was a message parameter present, otherwise only put one (with Greg Adam's agreement). This has worked for the majority of the product. The translators worked many hours to do so, and now we find that not all code uses MessageFormat. Specifically, org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.getLocal izedMessage(int, String[]) org.eclipse.jdt.internal.compiler.problem.ProblemFactory.getLocalizedMes sage(int, String[]). These two methods implement there own formatting, and don't expect the formatting rules that MessageFormat does. This wouldn't be a big problem, except that our translators don't have a good inclination for which message will be displayed by what code. So I suggest that this code be modified to "tolerate" the two single quotes and treat them as one. BTW, one of the translation testers tells me that during Toronto's TVT, they changed their code to use a centralized formatter that would tolerate either format. Not a bad idea for the next time around. Regards, Dan PS: This problem isn't isolated to non-English languages. I've seen a few "doesnt" and "dont" in the English product (sorry, forgot to note where). ----------------------------- Here is some more details from my note to Greg Adams: Subject: Re: Translation Verification Testing - potential problem with single quotes Greg, Please see my note below for details. Basically it boils down to this: if you use MessageFormat to insert parameters into messages, then all single quotes (apostrophes) must be doubled. The translators have assumed that if a message did not have substitution parameters ("{0}"), then single quotes are not doubled. If a substitution parameter was present, they assumed that MessageFormat would be used to insert the value, so single quotes are doubled. That seems like a reasonable expectation, but I understand some in WSAD have avoided using MessageFormat altogther to avoid this duality. The translators need a definitive rule to follow. Are their assumptions consistent with the code? FWIW, I'll forward you a note that covers the problem in more detail.
The reason for not using MessageFormat in the JavaCore (at least for the compiler piece) is that we do not want to introduce a dependency on this type, which does not exist on JCl extreme.
OK, thanks for the clarification, that makes sense. I think the best approach is to modify this code to be tolerant of '', since translators will never know which API will be used. Also consider moving the rest of the platform away from MessageFormat in another release. According to our translation testers, other Toronto products have already done so and it has greatly simplified the translation process and reduced errors. BTW, this is an urgent version 1.0 NLV problem. I'll coordinate with Cam-Thu Le and Greg Adams on the code fix schedule issues...
We made the appropriate change in 2.0 stream (double quotes are turned into signle ones - outside message arguments). However it appears that many more components are affected than just the Java Core. All implementers of #bind(String id, String[] bindings)have the same bug. bind(String, String[]) - org.eclipse.ant.core.Policy bind(String, String[]) - org.eclipse.ant.internal.ui.Policy bind(String, String[]) - org.eclipse.core.internal.boot.Policy bind(String, String[]) - org.eclipse.core.internal.runtime.Policy bind(String, String[]) - org.eclipse.core.internal.target.Policy bind(String, String[]) - org.eclipse.core.internal.utils.Policy bind(String, String[]) - org.eclipse.jdt.internal.compiler.batch.Main bind(String, String[]) - org.eclipse.jdt.internal.compiler.util.Util bind(String, String[]) - org.eclipse.jdt.internal.core.ant.Util bind(String, String[]) - org.eclipse.jdt.internal.core.search.Util bind(String, String[]) - org.eclipse.jdt.internal.core.Util bind(String, String[]) - org.eclipse.pde.internal.core.Policy bind(String, String[]) - org.eclipse.vcm.internal.core.Policy bind(String, String[]) - org.eclipse.webdav.client.Policy bind(String, String[]) - org.eclipse.webdav.internal.kernel.Policy bind(String, String[]) - org.eclipse.webdav.Policy
I understand from John Kellerman that you can help us by identifying which propertie files are affected by this inconsistency (i.e., two single quotes expected by MessageFormat versus one expected by formatting routines within Eclipse). That would be greatly appreciated by our TVT team. Please add the list of affected files as a comment to this bug report. FYI, if you are unable to do so, the translators plan to systematically double all quotes, since they believe that while such an approach is flawed, it is more readable (e.g., they would rather see a phrase like "it doesn''t work" than "it doesnt work").
In 1.0, the following plugins provide an alternative to MessageFormat: org.eclipse.ant.core org.eclipse.ant.ui org.eclipse.core.boot org.eclipse.core.runtime org.eclipse.core.target org.eclipse.core.resources org.eclipse.jdt.core org.eclipse.pde.core org.eclipse.webdav *.properties files in these plugins do not need to double apostrophes, even if a message parameter is present. For the remainder of the plugins, the strategy already being applied: two single quotes if there is a message parameter present ({0}), otherwise only put one, SHOULD continue to work. (No formatting required so MessageFormat not used)
Created attachment 72 [details] Impossible de supprimer l'emplacement
Below is a note from one of our testers. In the translation, it requires a single quote (see attachment). She followed the "rule" for single quotes: in this case there are no variables, so she put only one single quote. It doesn't appear in the message box. Is this another exception to the "rules" for single quotes? Our translator can obviously correct this one case ---------------------------------------------- Dan, According to what i see in the interface, the following string should contain two quotes instead of one although it does not contain any variable. File eclipse\plugins\org.eclipse.vcm.ui\vcmui_jar\org\eclipse\vcm\internal\ui\Workben chVCMPluginResources.properties RemoveRepositoryAction.messageTitle=Cannot Discard Location In French, it is "Impossible de supprimer l'emplacement". But the single quote is not displayed, see attached image. So what is the rule for this file? (or similar files) Thanks for helping us Marjorie
My initial test suggests that this is a coding error rather than a rule. On the positive side, I could only find two instances of the error (invoking MessageFormat on a zero-parameter string)in the VCM component. The coding problem is exposed when passing null as the second argument to MessageFormat. This causes formatting on a zero-parameter string and therefore requires apostrophes to be doubled when not expected.
The two problematic keys in org.eclipse.vcm.internal.ui.WorkbenchVCMPluginResources.properties are RemoveRepositoryAction.messageText RemoveRepositoryAction.messageTitle
added Kevin to the CC list, the messages are contributed by VCM
Marked as to be fixed for R1, per agreement with TVT testers for NL signoff.
I noted that the "1.0 fix candidates" list included this problem, saying that "Workaround already done: Translation teams have determined which formatter was used." This isn't true, the complete list was NOT provided in time to the translation team during TVT. So this problem will be present in the 1.0 translations. FWIW, even with a complete list, it is evident from the multiple modifications to this bug report that this "workaround" is a tenuous solution at best. I suggest that the message formatting code be isolated and changed to be tolerant of either a single or two quotes. This is the approach taken in other TVTs (or so I'm told).
no further action is planned on this bug - closing
