Parenthesis do not work correctly in Hebrew searches.

[miketisdell]

I reported this in a reply in the other thread, but I am not sure if was seen so I am reporting it again in its own thread. I just checked 1.1.0b22(9784) and it still doesn't work.

 

 

Parenthesis do not work correctly in Hebrew searches.

 

Example: ‏איש ‎<AND> ‏(אמר ‎<AND>‏ אלהים)

 

On the computer this search works, but on the tablet it does not.

I get the following message that appears and then disappears rather quickly: "An unexpected parenthesis was encountered.\n\n Each close parenthesis must be preceded by a corresponding open parenthesis."

 

In English the parenthesis work without a problem.

[Scott M]

Thanks for the reminder. It's on my list. I wanted to make sure that the glossing issues (VULG-T, etc.) was fixed and pushed that out without catching up the remaining issues. Which I'll be attacking next.

[Scott M]

OK, so ostensibly, this is 'fixed.' But to do so, I had to remove a long-standing function with the name:

 

ReverseHebrewParentheses

 

which makes me a bit nervous. Further, as I attempted (fumbled) to enter the search terms in the OP, this odd behavior (seems that way to me, anyways) showed up:

 

 

http://i64.tinypic.com/9ljsrb.jpg

 

When I used the Android Hebrew keyboard, and tapped their '(', the text box got an ')'. (The red arrows.) And vice versa (blue arrows). So something is going on here. And I believe if a user dutifully tapped their '(' and ')' on the Hebrew keyboard and left them unmolested in their reversed (by the Android Hebrew keyboard) state, then the reversal operation Accordance has long performed would behave. But if the user 'corrects' the reversal of the Hebrew keyboard entry, by reversing the reversal, then Accordance would reverse the reversed reversal and the search would fail.

 

All the while, I begin to accumulate a headache.

 

So in theory, this problem is 'fixed', if the standard is to make correct looking (reversed reversal) parens search properly. But it sorta feels like a potential morass to me where XX% of people are going to do it one way that 'fails' and XX% the other. Open to thoughts on this point...

[Helen Brown]

We think that the text in the Entry needs to look correct, even if to achieve that the user needs to tap the "wrong" keys to achieve it.

[Scott M]

We think that the text in the Entry needs to look correct, even if to achieve that the user needs to tap the "wrong" keys to achieve it.

 

OK, then I'll leave in the fix for the next release. Thanks.

[Λύχνις Δαν]

I had hoped that Unicode defined open and close for the various bracket types and then the direction would be chosen appropriately to context. However I was just looking again at this and it seems that brackets are considered to be neutral and Unicode defines code points for left and right not open and close. I then realized that there are ( I think there are anyway ) cases in bidi text situations where I don't think the code can do it properly without help from the user alas.

 

So in short I'm not sure the user can be oblivious and magically the right thing gets done. I should read more on it one day when I have a large cup of coffee and nothing else to do.

 

I'll try it out when it appears and I'll test it with my Android keyboard too - not that it is necessarily correct

 

Thx

D

[miketisdell]

OK, so ostensibly, this is 'fixed.' But to do so, I had to remove a long-standing function with the name:

 

ReverseHebrewParentheses

 

which makes me a bit nervous. Further, as I attempted (fumbled) to enter the search terms in the OP, this odd behavior (seems that way to me, anyways) showed up:

 

 

http://i64.tinypic.com/9ljsrb.jpg

 

When I used the Android Hebrew keyboard, and tapped their '(', the text box got an ')'. (The red arrows.) And vice versa (blue arrows). So something is going on here. And I believe if a user dutifully tapped their '(' and ')' on the Hebrew keyboard and left them unmolested in their reversed (by the Android Hebrew keyboard) state, then the reversal operation Accordance has long performed would behave. But if the user 'corrects' the reversal of the Hebrew keyboard entry, by reversing the reversal, then Accordance would reverse the reversed reversal and the search would fail.

 

All the while, I begin to accumulate a headache.

 

So in theory, this problem is 'fixed', if the standard is to make correct looking (reversed reversal) parens search properly. But it sorta feels like a potential morass to me where XX% of people are going to do it one way that 'fails' and XX% the other. Open to thoughts on this point...

 

 

Question: Are you using the Hebrew keyboard on your Android device? When I type on my keyboard, I get the correct parentheses on the Android display (Samsung Galaxy 7 & Samsung Tab2 10")

[Scott M]

Question: Are you using the Hebrew keyboard on your Android device? When I type on my keyboard, I get the correct parentheses on the Android display (Samsung Galaxy 7 & Samsung Tab2 10")

 

Yes, I'm using the Hebrew keyboard on the Android device. That's what I show in the screen shot. That's on my device, hard to say if it is entirely uniform across Android versions.

[miketisdell]

Yes, I'm using the Hebrew keyboard on the Android device. That's what I show in the screen shot. That's on my device, hard to say if it is entirely uniform across Android versions.

 

I just tried it again, and I get the backwards parenthesis (like in you example) if I begin with a parenthesis (it starts out correct but left aligned, and then changes to right aligned and backwards when I press the first Hebrew letter). If I begin with a Hebrew word and then type a parenthesis, it appears correct on the display.

 

NOTE: I can also type the first Hebrew word and then go back and add the parenthesis and it looks correct.

Edited May 10, 2018 by miketisdell

[miketisdell]

I just tried the attached search this morning in 1.1.0b23 and it WORKS!

 

And it displays correctly too.

Edited May 11, 2018 by miketisdell