locked
TextBox.Text in Right-to-Left languages

    Question

  • Hi,

    I am currently working on a document viewing app. Some of my customers have informed me that when they're using Hebrew, then the text they input in the search box is backwards.

    That is, if the user puts focus on my TextBox, then hits first the key ל, then the key כ. The text shows up correctly in the TextBox:

    But when the user clicks search, the text is reversed for my search:

    That is, the search term is read left-to-right, which gives my document search incorrect results.

    I tested this same thing on the built in Windows Reader, and there it seems to successfully search for the term in the right order.

    So, my question is, how can I make my program read the characters in the right order?

    P.S. My app doesn't not "support" Hebrew. that is, it's not listed as a supported language. Still, the TextBox seems to understand the keyboard and displays it properly. So how do I get that information?

    Thanks,

    Tomas Hofmann

    Monday, January 19, 2015 9:11 PM

Answers

  • Hi Tomas,

    Can you clarify both what you get and what you expect when you say:

    However, when I ask the TextBox for the associated text, I get them in the wrong order. That is, when typing, text goes in right-to-left, but is read left-to-right when you examine TextBox.Text

    The RTL rendering occurs only when rendered, not in the internal representation of the string.

    I would expect that if I type Lamed-Kaf (LK) then it would display RTL and if I iterate through the string I'll get L then K. (I'm using Latin characters rather than Hebrew characters so the browser doesn't render them RTL and make it difficult to follow the point: note that the rendered tooltip in your screenshot has rendered RTL, but that doesn't change the order in the underlying string. This gets wierd when you mix LTR and RTL text or if you have even more complex scripts).

    Search code typically doesn't care how the characters render since the internal representation should be consistent. The app shouldn't have to convert the input between RTL and LTR, unless the PDF itself is doing so (which I would not expect).

    Saturday, January 24, 2015 3:16 AM
    Owner

All replies

  • Hi Tomas,

    It is possible that someone use Hebrew input method but choose US as his system region, he can still see that app on the US market.

    Here we have a guideline for this language: How to support bidirectional UI, in the Text handling section, you need to some extra settings.

    --James 


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, January 20, 2015 5:46 AM
    Moderator
  • Hi James,

    The link you gave me is good. However, it assumes that I am developing an app with a specific language or layout in mind.

    The thing is that my TextBox should be able to take input from any device and any keyboard, whether or not it is laid out in a right to left fashion or if my app is listed as supporting the language or not. We're dealing mostly with PDFs, which means that the document can have any language on it, and the user may be anywhere in the world, with whatever language they've installed.

    Now, when they type Hebrew characters, they show up correctly. However, when I ask the TextBox for the associated text, I get them in the wrong order. That is, when typing, text goes in right-to-left, but is read left-to-right when you examine TextBox.Text. What I am wondering is if there is a built in way to handle this or if I have to check individual characters and determine whether or not they're LtoR or RtoL character and then re-format the string accordingly before I push it into my PDF handling code.

    Thanks,

    Tomas

    Friday, January 23, 2015 10:56 PM
  • Hi Tomas,

    Can you clarify both what you get and what you expect when you say:

    However, when I ask the TextBox for the associated text, I get them in the wrong order. That is, when typing, text goes in right-to-left, but is read left-to-right when you examine TextBox.Text

    The RTL rendering occurs only when rendered, not in the internal representation of the string.

    I would expect that if I type Lamed-Kaf (LK) then it would display RTL and if I iterate through the string I'll get L then K. (I'm using Latin characters rather than Hebrew characters so the browser doesn't render them RTL and make it difficult to follow the point: note that the rendered tooltip in your screenshot has rendered RTL, but that doesn't change the order in the underlying string. This gets wierd when you mix LTR and RTL text or if you have even more complex scripts).

    Search code typically doesn't care how the characters render since the internal representation should be consistent. The app shouldn't have to convert the input between RTL and LTR, unless the PDF itself is doing so (which I would not expect).

    Saturday, January 24, 2015 3:16 AM
    Owner