[Pending] Adding support for Right-to-left languages (Hebrew, Arabic...) (1 Viewer)

[morpheus_xx]

This thread is about adding support for languages that are written right-to-left.

still no Hebrew support on version 2, although me and some other members have translated the whole program to hebrew in Transifex project...

Supporting Hebrew depends on two things:

• using a font which supports Hebrew characters
• updating layouting engine to support "right to left" (RTL) languages

First I'd like to show the current situation:
This is the source, translation added at transifex webservice:

And this MP2 in default skin looks like:

I put a color border around the same words. If you look at them, you see them in "reversed order" rendered in MP2. This is due to the "right to left" writing order in Hebrew.

Does any of our [USERGROUP=39]@Developers[/USERGROUP] [USERGROUP=40]@Testers[/USERGROUP] [USERGROUP=92]@SuperUser[/USERGROUP], @yoavain have experiences with those kind of languages?

What other requirements to layout are there? Would it be required to switch complete menu to the right side (instead as shown above on left side)? Or would it be enough to support text properly?

@staticx as you pointed us to the issue, what do you think?

 

[morpheus_xx]

I made a quick test and reversed the string before rendering:

While this is no valid approach, it shows an important fact to consider: if you look at the screen, you will find english "Latest media" also reversed. This means, a proper RTL-support is not a global "switch", but you need to consider each string (or even substring?) individually.

 

[yoavain]

What about reversing strings at runtime only if they contains Hebrew/Arabic letters? (Runtime can also mean when reading once from transifex )

 

[morpheus_xx]

I think we need a clearer definition, as this won't work for a mixed letter string: (I copied this one from transifex as I can type and read any of those letters )
שרת MP2 לא זמין
You see, reversing the whole string is wrong, it would make MP2 to 2PM.

But we could check each character for being in range of Hebrew (or any other RTL language): http://www.utf8-chartable.de/unicode-utf8-table.pl?start=1280 U+0590 - U+05FF.

My test with string reversal was only to try if there will be a proper string rendered for Hebrew. Can you confirm this, is the text readable for you?

The main problem will be the layout question: is it expected that everything (Menu, Controls, etc.) is also aligned RTL? I've seen Microsoft sites in Arabic, there is everything "mirrored". If we need this also for MP2, this will cause a lot of work for the layouting engine.

 

[morpheus_xx]

@yoavain can you please check my bold marked questions above?

A new question: is everything on this new screenshot is "written" correctly? I already know the text in player controls is wrong, because I only reversed strings that starts with a RTL character (which "-" is not).

I'm still not sure if this is a way to go, I don't know if this is "enough"..

 

[ysmp]

A new question: is everything on this new screenshot is "written" correctly? I already know the text in player controls is wrong, because I only reversed strings that starts with a RTL character (which "-" is not).

I'm still not sure if this is a way to go, I don't know if this is "enough"..
[ATTACH=full]156481[/ATTACH]

Hi Morpheus, my wife can read Hebrew ... she say yes this all screen (above post) read fine and correct.

 

[morpheus_xx]

I think I can fix the known issue inside player control texts on top of screen. But after all this is only a very small part to support RTL layout:

If you consider following parts:

• menu: should it be on right side then?
• the text inside the button: shouldn't it be right aligned for RTL? And what about the latin texts? Should they still remain left aligned or also right?
  
• scrolling text: imagine the news ticker, if text is RTL and we scroll from right (as we do for latin alphabet), you would get the text from end to beginning

This all means, that we properly can't simply do a "bit of support", as it would look strange in many parts.

 

[staticx]

I think I can fix the known issue inside player control texts on top of screen. But after all this is only a very small part to support RTL layout:

If you consider following parts:

• menu: should it be on right side then?
• the text inside the button: shouldn't it be right aligned for RTL? And what about the latin texts? Should they still remain left aligned or also right?
  
• scrolling text: imagine the news ticker, if text is RTL and we scroll from right (as we do for latin alphabet), you would get the text from end to beginning

This all means, that we properly can't simply do a "bit of support", as it would look strange in many parts.

Hello

Thanks for your support!
I think, that for first step, I can give up on the right-side menu. For start all I want is to be able to use the program, so what you've showed at post #5 is fine for now.
please remember that MP Hebrew community is very small (we've "lost" most of MP users to XBMC....) so It's not urgent to move the men to right side and some other things...

as for the text inside a button, I think it has to be RTL...
scrolling text - not very important... we can give up the news ticker for now.. (anyway all the news are bad news )

thanks!

 

[morpheus_xx]

Yesterday I've read a lot more about the text handling. I did wonder why we have to deal with different orders at all inside MP2 rendering.

The answer is, that the rext rendering engine is based on FreeType to get the glyphs (single character) from a given font. That glyph is then added to a texture. When a text is going to be rendered, all contained glyphs will be added to the texture when they are needed.
The actual rendering then in principle renders every character separately using texture coordinates of the glyph and the "big character map" texture.

This is the cause why read order is not yet considered correctly and the partial string reversal could be a temporary workaround.

The workaround wouldn't work for Arabic, because there letters are different if they are combined differently. This means "A B" looks different then "AB" or the 'a' inside "ab" might look different to the 'a' inside "ac". (Correct me if I'm wrong).

Now what should we do now?

One possible solution would be DirectWrite (available through SharpDX), which allows drawing any text correctly, LTR, RTL and mixed cases are fine. We could replace the current implementation of FontAssetCore by a DirectWrite text renderer, which then either renders directly to render target, or we need to take the way over a Texture that then will be rendered into scene.

@Stéphane Lenclud , you wrote in another thread that you have experience with graphic coding, what do you think how we should handle text rendering in future inside MP2? Could the explained rendering of characters be a cause for a performance bottleneck? Would be my proposal a bottleneck?

Finally this means a big rework of one central part of rendering engine that requires much work for developing, testing, and fixing. But I think we would benefit of this step.

 

[velis]

I have a bit of experience with farsi in my Android app:
Generally, RTL users *prefer* everything to be mirrored, but they are used to western layouts and don't complain about them too much. My farsi translator told me multiple times that I needn't bother that much, but was still quite happy that I went so far as to mirror the entire app.

In my experience, straight mirror will usually do it (also relatively easy to support in rendering engine), but there may be cases where that's not a good solution. I have no idea what such cases might be, but Google specifically mentions that they don't want to do the straight mirror because it might break something. My guess is that if there was something to break, it would be the developer's LTR assumption and manual layout of components in LTR order. Mirroring certain component combinations might then prove to be a bad idea, but not much worse than not mirroring at all.

As for string reversing: don't do it!!! Even in RTL languages, there are expressions / acronyms / formulas / whatever that are written in a western-like script. The default Windows API should normally take care of proper string rendering, as long as you use a font that has the required language characters.

Personally, I think there needs to be one more item observed: current layout engine only supports fixed coordinates. The problem is that some languages require more space to say the same thing than others. So in my translation of MP, I have noticed repeatedly that my translation would be cut off because there simply was no translation short enough. In other places though, there was too much space left because slovene translation was much shorter than english original. This is perhaps unrelated, but essentially it has the same roots as RTL support.

Oh, and BTW: some languages have different glyphs for numerals (0 - 9). They are also in different unicode code ranges. Just a heads-up for all those %d sprintfs

About FreeType rendering issues: http://stackoverflow.com/questions/6431624/freetype-support-for-right-to-left-languages (there's a layout lib mentioned there)