PR available: https://github.com/wikimedia/svgtranslate/pull/114

Patch merged.

Switched my keyboard mapping to Hebrew (il) and checked that it behaves appropriately (as far as my limited understanding of RTL goes[1]) for things like Hebrew mixed with numbers, times, parentheses, punctuation, whitespace and Hebrew mixed with English.

I also compared the behaviour with VisualEditor as a reference, because I understand it has good RTL support.

I only tested this briefly on Firefox 60 as it appears to use the HTML 'dir' attribute, which has good cross-browser support.

I also checked that the RTL text appeared correctly in the preview image.

I was unable to test uploading a translation (on svgtranslate-test I get "json_decode error: Syntax error". I think the webservice needs restarting.) But, I could look at what was POSTed when I attempted to upload a translation.

If, in the HTML form I have a translation like: "אינקוס 1 2 3", in the JSON that is POSTed it looks like: "אינקוס+1+2+3". Because I cannot upload, I don't know if the latter will be correctly interpreted. Could someone confirm? @Mooeypoo?

After Downloading, the same string appears in the SVG as "אינקוס 1 2 3" which I think is OK.

Ref:

1. After reading https://opensource.com/life/16/3/twisted-road-right-left-language-support

Yeah, this fix is mostly only for the UX of the tool and should not impact the actual SVG file.

From my (quick) checks, the rendering seems to be okay; you can also see from my screenshot -- the inputs have the ( in the wrong place (it "jumped" to the right side, since the input is in LTR, so that's the "end" of the string) but in the preview on the right, the parentheses are showing correctly.

I took that to assume that the RTL rendering in the SVG is okay, at least the common usage... 😀

The + signs are interesting, actually. I think that + is a common replacement for a space online (in URLs it used to be used a lot more) but I haven't seen it in JSON files yet. You're right that, technically, it actually does change the rendering behavior. When there's a space between the numbers, they're considered separate words in the context of RTL, so they are rendered right to left, but when we use the +, they're now a mathematical operation, which is LTR.

See:

נסיון 1 2 3

נסיון 1+2+3

So, if this was the way it would've rendered in the file itself, to the user, I'd be worried, but it looks like the SVG itself shows spaces, and renders properly, and the JSON construct is usually considered not for user-consumption so it's not too concerning if it uses weird syntax that changes the BiDi behavior (as long as the text appears correctly in the image, which it seems to)

So since the fix touches only the tool's UX, and the file is rendered correctly, I think that this is probably fine, like you're saying.

Thanks for the thorough check!

In T224294#5215710, @Mooeypoo wrote:

So since the fix touches only the tool's UX, and the file is rendered correctly, I think that this is probably fine, like you're saying.

OK. There's nothing else I want to do. Moving this to Product sign-off.