Community
Participate
Working Groups
3.3 For 'Strings with basic LTR reading order not rendered correctly in RTL locales', new API TextProcessor.process(String, String) got added that can give support to keep certain substrings LTR in an RTL environment. The big problem remaining is to know which strings need this treatment. This knowledge needs to be shared or even better, encapsulated. As we identified paths and URL and file names/patters as such, I suggest that platform adds label provider for these. These label providers can also unify the way how paths are rendered in the UI, e.g. we once had a rule that the leading slash shouldn't be shown. Of course olny a few plugins try to fix this In JDT.UI we have e.g. a class JavaElementLabels that provides API to render labels for Java elements in varions ways: qualified, post qualied... I suggest to add similar class that renders labels for paths, names and URLs
The biggest downfall of this solution is we almost surely will not identify every case for which the generic TextProcessor API should be used - there always seem to be new cases that pop up. Also, where will these additional APIs reside so that everyone can use them (we should consider that more than just Platform, JDT and PDE will want to use these APIs)?
Martin, I disagree that this bug blocks bug 130589 and bug 130592 - it would be nice to have, but is not a necessity to resolve those bugs.
Ok, agree, 'block' is the wrong term here. You can unblock if you want. But I still think it would be sub-optimal if each component solves this problem individually.
Bug 181749 looks to be a use case of this in BIRT.
Cheng-Yee, mentioned in comment #2, this bug is not a necessity to resolve bug 181749. The TextProcessor#process(String) method will solve the problem for file paths, which is the most common use case for this API. I removed all bugs from the blocks field.
I played around with the TextProcessor API a bit, and it works fine for my read-only cases. In other words, displaying paths in the properties view and the navigator of our product yielded the correct results. However, I'm having trouble with read/write widgets. For example, say we have a widget pair consisting of a Text field and a browse Button. The text field allow the user to enter a relative folder path (abc/def or abc\def). The browse button opens a chooser dialog to select an existing folder. If I process the IPath result from the chooser dialog, and put the results in the Text field, then the string content contains additional characters, causing our validators to throw failure status. I could work around this problem by storing the unprocessed string in the data of the widget, although a bunch of code would need to be changed. It would be nice if the Text widget had a flag that you could set, telling it to render set string using the TextProcessor. This would prevent a lot of code changes for my team, and probably numerous other teams. I see another problem which might suggest that the Text widget needs to be more BiDi aware. In my example, if I type the text directly into the text widget, then lots of confusion results. Let's say I'm trying to specify the relative path CBA/FED/Ga (cap letters are right to left Hebrew). After each key stroke, here is what I see, with cursor position indicated by ^. 1)^A 2)^BA 3)^CBA 4)CBA\^ 5)^D\CBA 6)^ED\CBA 7)^FED\CBA 8)FED\CBA\^ 9)^G\FED\CBA\ 10)G\FED\CBAa I think everything is correct up to step 5. As of step 5, the segmentation is not correct. I would have expected to see "CBA\^D", as I'm about to type the next right to left segment. Of course, step 10 is also incorrect. I think the text processing needs to happen on-the-fly after each key stroke. Also, the cursor position needs to be intelligent. I think this case demonstrates the need for the Text widget to be "BiDi segment aware".
This API was designed to be used for read-only widgets. We haven't explored a solution for writable widgets. I think such a solution might have to exist at the SWT level to be most effective/re-usable.
> I think such a solution might have to exist at > the SWT level to be most effective/re-usable. See Bug 230854 BIDI support for text input widgets
Created attachment 105151 [details] BasicElementLabels.java When we added BIDI support to JDT UI/JUnit and Search platform (over 1000 labels had to be changed!) I introduced this helper class to construct the labels containing paths, URL, file patterns and Java element names. As explained in comment 0, this adds another abstraction layer where clients don't need to know about BIDI and the TextProcessor and we can use the APIs to add more functionality, like consistency in path labels. I still think platform should offer something like this for paths, URL, file patterns and other basic labels we find. Everything not covered can still offered by the plug-ins that use it. Actually this should be in platform/resources or runtime as also core plugins have to construct labels for the UI (for example messages in exceptions or marker labels).
I finally took the time to understand what TextProcessor is about. The wiki page and API should have more information on when to use the TextProcessor. It should be use to format URL, paths, file names (name.extensio), and possibly full qualified java class names and java package names. The problem I'm seeing is people using the TextProcessor all over the place. For exemple: bug bug 233231, Bug 233537, etc. (Things like parenthesis, comas, collons, in the wrong place.) Sometimes they get 'lucky' and it works, sometimes it break things: Bug 235870 I think this kind of problem can't be fixed by an algorithm. They need to be fixed in the catalog (YES, the bidi control marks should be store with the translated text in the catalog file).
See Bug 235328, this is other case where TextProcessor doesn't work.
TextProcessor in general should be used for handling complex expressions of certain types only (i.e. of type FilePath, URL ). It should not be used for handling text / resource messages. This is especially true when the message is constructed from a pattern and placeholders replaced by real data at run time (i.e. The file at {1} does not exist) or from several pieces of run time data. It is true that in order to handle complex expressions of type File path, URL etc. TextProcessor can be used even if this text is later on embedded into some more general message (i.e. "The file at {1} does not exist" becomes "The file at c:\abc\def\123\ab does not exist". In this example TextProcessor should be applied only on the text replacing placeholder -{1}).However, applying TextProcessor on the whole message in general is not a good idea at all. This is for the following reasons: * TextProcessor does not do any miracles. It does not undestand the syntax of input argument. It was designed to handle FilePaths and URL which from Bidi perspective can be adequately parsed to tokens using list of separators (i.e. /.:). In case of general message this is not true. Without understanding of the syntax of text message we can't adequately handle it. * TextProcessor enforces LTR direction on the input passed to it. For translated to Bidi language messages this is not desired at all (since translated to Bidi language messages should have RTL direction). It is true that for FilePath, URL LTR direction should be enforced always. However, in case of general Bidi message this is not true. To solve a general problem of text message including placeholders we need to: 1. Understand what direction the message should have (RTL in case of translated message and LTR in case of not translated message) 2. Understand what direction each placeholder has 3. Enforce direction of data replacing the placeholder (using 2 above) 4. Enforce direction of message (using 1 above) Usually there is no need to handle 1 and 4 since this is enforced by higher level widget into which text message is embedded (i.e. in mirrored GUI RTL is enforced on the text via inheritance of direction, in not-mirrored GUI LTR is enforced via inheritance of direction). What you absolutely should do is 2 and 3. 2 depends on the syntax of data. For 3 you will need something better than TextProcessor. To sum up. 1. The problem discussed in this thread belongs to so called "Message with placeholders" type of complex expression. 2. Design for addressing such type of complex expressions was provided by Bidi architect - Mati in section "Message with placeholders" at: https://bugs.eclipse.org/bugs/attachment.cgi?id=96407 3. The implementation and best practices (aka algorithm) for using this implementation for resolution of similar issues were suggested in bug 229010 4. Sample issues of "Message with placeholders" type of complex expression can be found in bug 224921 and bug 222927 5. It is true that in some cases "Message with placeholders" type of complex expression can be resolved using changing translated resource only, or in some cases using TextProcessor. However, in general case this type of complex expression should be resolved using solution from bug 229010
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
