Community
Participate
Working Groups
Created attachment 277763 [details] wrong text direction for sample code of content assist Version: I20190207-1800 Issue: The source code lines in content assist panel should have a LTR text direction thus the code will be readable. How to reproduce: Create service provider method https://www.eclipse.org/eclipse/news/4.11/jdt.php#service-provider-quick-fix
Usually the additional info is considered normal text. We also treat Javadoc info the same. Therefore the RTL orientation is correct. I would assume that one could fix this in the translations. Kit?
Created attachment 277790 [details] Bug 545037 - pseudo translations Dani, I tested the scenario with pseudo translations. See attachment. It's true that translator could use Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to fix the "normal text" in the additional info popup. However, the "preview code" for this proposal is generated (not externalized). The only externalized string is the TODO comment. Translator could not add RLM or LRM to fix this "preview code". Is it possible to add a check when generating the "preview code" and set the text orientation to be the same as the editor?
(In reply to Kit Lo from comment #2) > Created attachment 277790 [details] > Bug 545037 - pseudo translations > > Dani, I tested the scenario with pseudo translations. See attachment. > > It's true that translator could use Unicode right-to-left mark (RLM) or > left-to-right mark (LRM) to fix the "normal text" in the additional info > popup. However, the "preview code" for this proposal is generated (not > externalized). The only externalized string is the TODO comment. Translator > could not add RLM or LRM to fix this "preview code". I see. > Is it possible to add a check when generating the "preview code" and set the > text orientation to be the same as the editor? The problem is that many Quick Assists/Fixes do have natural text (like Javadoc) that's why we use RTL direction for that shell. We would have to fully externalize all the additional infos so that the (preview) code can be injected. Given it is like that since day one I suggest to defer this.
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. -- The automated Eclipse Genie.
