Right-to-left override should include the colon

[GoogleCodeExporter]

Using pseudolocalization-tool (actually, my own ruby-based clone of the tool 
which I had to write because of issue #8, but which generates exactly the same 
output) I created pseudolocalised copies of all of our properties files.

The result is kind of odd though. The colons attached to strings for label text 
don't move to the left, but rather float on the right, so you end up with 
fields like "emaN:".

Looking at your output, you have this:

  Pane.nameLabel.text=\u202EName\u202C\:

You should probably move the LRO to cover the \: as well:

  Pane.nameLabel.text=\u202EName\:\u202C

Doing so makes the colon appear in the proper location.

Original issue reported on code.google.com by trejkaz on 1 Aug 2014 at 3:18

[GoogleCodeExporter]

Another edge case. If you have a format like this:

    SourceList.detailFormat = {0} ({1})

Converting this RTL requires something like this:

    SourceList.detailFormat = [RLO][PDF]{0}[RLO] ([PDF]{1}[RLO])[PDF]

Otherwise, if the values substituted into the {0} happen to be left-to-right, 
you end up with mixed layouts. Perhaps *every* character in all strings should 
be surrounded by RLO...PDF pairs?

Original comment by trejkaz on 7 Aug 2014 at 1:47

[GoogleCodeExporter]

Aharon, can you comment on this?

Original comment by jat@jaet.org on 7 Aug 2014 at 2:30

[GoogleCodeExporter]

No, this is working as intended. The "fake bidi" pseudolocalization tool is not 
meant to produce output that looks nice; it is meant to produce output that 
faithfully emulates RTL text. If you have a real RTL word, e.g. the Hebrew word 
for "name", "שם", followed by a colon, and display that in an LTR context 
like this page, the colon goes to the right of the word: "שם:". Of course, 
that is not how you would want that to appear on a Hebrew page, where you would 
want the colon to the left of "שם". But to get that, you have to set the 
directionality of the page to RTL by adding a dir="rtl" attribute to the HTML 
element, which is exactly what you are supposed to do for any page in an RTL 
language - including the "fake bidi" pseudolocale. So, that the colon did not 
look like it should in your "fake bidi" page is proof that the fake bidi 
pseudolocale does its job of exposing bugs: the lack of the dir="rtl" on your 
page is the bug.

BTW, there is nothing special about the colon. All punctuation is neutral, and 
trailing punctuation appearing at the wrong end of a string (e.g. a full stop 
being displayed next to the first letter of a sentence) is a classic sign of 
missing directionality declaration.

Original comment by aha...@google.com on 7 Aug 2014 at 5:44

[GoogleCodeExporter]

Thanks for looking at it.

Original comment by jat@jaet.org on 7 Aug 2014 at 8:44

• Changed state: WontFix

[GoogleCodeExporter]

I don't know about web sites, because I generally work on real, GUI 
applications.

Taking the following test program:

    import javax.swing.JFrame;
    import javax.swing.JLabel;
    import javax.swing.SwingUtilities;
    import javax.swing.WindowConstants;
    import java.awt.ComponentOrientation;
    import java.awt.FlowLayout;

    public class RtlDemo implements Runnable {
        public static void main(String[] args) {
            SwingUtilities.invokeLater(new RtlDemo());
        }

        @Override
        public void run() {
            //String text = "\u202EName\u202C:";
            String text = "שם:";
            JLabel label = new JLabel(text);

            JFrame frame = new JFrame("RTL Test");
            frame.setLayout(new FlowLayout());
            frame.add(label);
            frame.applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
            frame.pack();
            frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
            frame.setVisible(true);
        }
    }

This test program does set RIGHT_TO_LEFT orientation for the frame, but I'm 
using applyComponentOrientation, which does apply that to all descendants. When 
you run this program, the Hebrew example comes out with the colon on the left. 
I would call that correct RTL treatment.

Now switch the comments around to put your "pseudolocalised" text into the 
label and run the program again. Now the colon is on the right.

Do you still think *my* program has the bug? I hope not.

Original comment by trejkaz on 7 Aug 2014 at 10:24

Attachments:

• [Screen Shot 2014-08-07 at 8.17.17 pm.png](https://storage.googleapis.com/google-code-attachments/pseudolocalization-tool/issue-9/comment-5/Screen Shot 2014-08-07 at 8.17.17 pm.png)
• [Screen Shot 2014-08-07 at 8.17.36 pm.png](https://storage.googleapis.com/google-code-attachments/pseudolocalization-tool/issue-9/comment-5/Screen Shot 2014-08-07 at 8.17.36 pm.png)

[GoogleCodeExporter]

I don't know much about Swing, but it is quite possible that it does 
first-strong paragraph direction estimation on each paragraph of text, e.g. the 
text in a JLabel. If so, the problem you are seeing is a result of issue 10, 
which includes the fact that according to the rules of the first-strong method 
(as specified in UAX9, P2 and P3), fake-bidi-localized text is LTR (since it 
contains no RTL characters - RLO is not RTL according to first-strong). Issue 
10 also suggests a fix, putting RLM characters before the RLO and after the 
PDF, which will make the first-strong method deem it RTL (as would be the case 
with real RTL text like Hebrew). I have also inadvertently submitted r14 and 
r15 implementing a fix to issue 10. To my shame, I did so without checking that 
it compiles and passes the tests. Try your example with the fix, please.

Original comment by aha...@google.com on 7 Aug 2014 at 10:49

[GoogleCodeExporter]

The colon does indeed now move to the left, although it's also on the left if I 
forget to set RIGHT_TO_LEFT on the window...

Original comment by trejkaz on 8 Aug 2014 at 1:56

[GoogleCodeExporter]

But if my guess is correct, that is also the case for real RTL text, which is 
exactly what we want: fake bidi working just like real RTL text.

Original comment by aha...@google.com on 8 Aug 2014 at 6:38

[GoogleCodeExporter]

Ah, yep. Quite right - the real RTL text also puts the colon in the right place 
even if I forget to set the orientation. So now the behaviour is totally 
consistent.

For some reason, I assumed that having the component orientation wrong would 
have ended up putting the colon in the wrong place.

Original comment by trejkaz on 8 Aug 2014 at 2:18

[GoogleCodeExporter]

That can happen in some cases if you have a mix of RTL/LTR text.  The UI 
components try to do the right thing, but can guess wrong so it is always 
better to set LTR vs RTL at the top level when you know it.

Original comment by jat@jaet.org on 8 Aug 2014 at 2:52

[GoogleCodeExporter]

Re comment 10: In Swing, setting the orientation apparently affects only the 
layout of UI components relative to one another. The text directionality is 
apparently always set using the first-strong algorithm.

Original comment by aha...@google.com on 10 Aug 2014 at 6:25

[GoogleCodeExporter]

Ah, interesting. That explains why I had to put rtl marker characters into the 
{0} ({1}) example to get sane behaviour even with the component orientation set 
correctly.

Original comment by trejkaz on 10 Aug 2014 at 7:29