Community
Participate
Working Groups
In RTL orientation, there are some strings that should maintain basic LTR reading order - examples are file paths, URLs and file associations. Even though Eclipse provides full BiDi support as of 3.1, these strings are special cases and so are not rendered correctly due to the presence of neutral characters - that is, characters whose directionality is determined based on the directionality of its surrounding text. See http://www.unicode.org/reports/tr9/ for the full specification on the Bidirectional algorithm. The Eclipse platform now provides API that will render these strings correctly in RTL locales (Hebrew and Arabic) by inserting directional marker characters into the string in the appropriate places. Strings that utilize this API are intended to have an overall reading order of left to right (e.g.file paths, file associations, URLs) and are segmented according to delimiter characters where each segment will have the usual BiDi rendering algorithm applied to it. To use this API, call org.eclipse.osgi.util.TextProcessor.process(String, String) where the first string is the string to manipulate (e.g. a file path, URL, etc) and the second string is a string of delimiters which define how the string should be segmented. Example 1 string=d:\AAA\bbb\CCC\ddd.html delimiter=".:\" Example 2 string=*.html delimiter="*." Example 3 http://AAA/bbb/ccc.html delimiter=".:/" Since file paths and URLs will likely be the most common use case for this API, a set of default delimiters="./\:" is provided so a call to org.eclipse.osgi.util.TextProcessor.process(String) is all that is required in these cases. Test cases to check for: URL example to test = http:\\abc\ABC where lower case is Latin (e.g. English) and upper case is Hebrew/Arabic Without using the new API, it renders CBA\http:\\abc File path to test = d:\abc\ABC where lower case is Latin (e.g. English) and upper case is Hebrew/Arabic Without using the new API, it renders CBA\d:\abc Originating from bug 119517. Please do a complete review of the UI elements of this component in order to identify and call the new API for all occurrences of file/directory paths, URLs, file associations and any other strings that should have overall left to right reading order. Check views, wizards, property and preference pages, and dialogs as a starting point. Some examples of this problem that I have found in this component thus far are: *Search View (choose Show as List option)
Created attachment 35772 [details] screen shot of example of incorrect rendering
This looks like major work, especially in JDT. It seems that we need help here from a RTL expert. Which strings need this special treatment. Paths, URL you say. What about file names (x.java)? packages (org.eclipse.jdt), qualified names ('a.b.X$E'), method signatures (foo(int x, int y)) To encapsulate that knowledge, it would be good to have specific formatters, or label providers. E.g. We have JavaElementLabels.getMethodLabel(..) that could do the correct thing. Everybody playing around with TextProcessor.process might lead to more confusion than goodness (why is this utility in osgi?) So what do you think of helpers like JavaElementLabels.getWorkspacePathLabel(IPath) get getExternalPathLabel() in core resources. (or something along these lines) An advantage of such a utility is that much we can we also promote an Eclipse wide consistent rendering of paths. E.g. once (in 1.1) it was enforced that rendered workspace paths should always remove the leading separator 'MyProject/file.txt' instead of '/MyProject/file.txt' but many components don't follow this. Ok I see, this would mean new API. But if this fix is as much work as a imagine it to be, it could be worth it.
I agree it will be alot of work. I have been communicating with the Globalization Center of Competency and they helped us come up with this solution. The reason why the API is generic is because I don't see how we can completely identify all the specific possible uses for it, as your suggested implementation would require (before the API freeze, too). At this point, we could only identify what is useful for the Platform (and JDT and PDE) and that will very likely not encompass every need for API like this for all applications built on Eclipse. I definitely see the point of your suggested implementation, but I don't see it working pragmatically since the API freeze has already taken place and I believe some additional uses will arise for this API in the Platform and in other products, post-API freeze.
This only occurs on Windows (and maybe Mac), but not Linux.
I filed bug 146220 to request label renderers for paths where RTL/LRT issues can be encapsulated and not everybody has to know all the details.
*** Bug 181300 has been marked as a duplicate of this bug. ***
fixed for 3.4 M7 see bug 222889, bug 222927
Paul, did you use the wrong bug number? How can this fixed bug block another one?
