Issue 9 in pseudolocalization-tool: Right-to-left override should include the colon

[pseudolocal...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 9 by trejkaz: Right-to-left override should include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[pseudolocal...@googlecode.com]

Comment #1 on issue 9 by trejkaz: Right-to-left override should include the
colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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?

[pseudolocal...@googlecode.com]

Updates:
Owner: aha...@google.com

Comment #2 on issue 9 by j...@jaet.org: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

Aharon, can you comment on this?

[pseudolocal...@googlecode.com]

Comment #3 on issue 9 by aha...@google.com: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.

[pseudolocal...@googlecode.com]

Updates:
Status: WontFix

Comment #4 on issue 9 by j...@jaet.org: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

Thanks for looking at it.

[pseudolocal...@googlecode.com]

Comment #5 on issue 9 by trejkaz: Right-to-left override should include the
colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.


Attachments:
Screen Shot 2014-08-07 at 8.17.17 pm.png 15.5 KB
Screen Shot 2014-08-07 at 8.17.36 pm.png 15.8 KB

[pseudolocal...@googlecode.com]

Comment #6 on issue 9 by aha...@google.com: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.

[pseudolocal...@googlecode.com]

Comment #7 on issue 9 by trejkaz: Right-to-left override should include the
colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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...

[pseudolocal...@googlecode.com]

Comment #8 on issue 9 by aha...@google.com: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.

[pseudolocal...@googlecode.com]

Comment #9 on issue 9 by trejkaz: Right-to-left override should include the
colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.

[pseudolocal...@googlecode.com]

Comment #10 on issue 9 by j...@jaet.org: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.

[pseudolocal...@googlecode.com]

Comment #11 on issue 9 by aha...@google.com: Right-to-left override should

include the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.

[pseudolocal...@googlecode.com]

Comment #12 on issue 9 by trejkaz: Right-to-left override should include
the colon
http://code.google.com/p/pseudolocalization-tool/issues/detail?id=9

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.