Changes have been made in Git for this ticket:

Fix rendering of subjects in RTL scripts when using LTR translations 
(vilius@lnk.lt, Bug #3511).

http://git.horde.org/diff.php/imp/docs/CHANGES?rt=horde-git&r1=acaf24888a23d55653e50f058f25157962530c5f&r2=29d05715d9b9f696cfe0e56cec8f9877a4d1235e
http://git.horde.org/diff.php/imp/message.php?rt=horde-git&r1=ee6ff322e0a8a5aa91dbffd0bda962ce51427d03&r2=29d05715d9b9f696cfe0e56cec8f9877a4d1235e
http://git.horde.org/diff.php/imp/templates/message/navbar_top.html?rt=horde-git&r1=494134b0cb53996bc9815e438ac7bf14bd3fea50&r2=29d05715d9b9f696cfe0e56cec8f9877a4d1235e

That's what I guessed. Thanks for the clarification.

If you mean that in RTL it goes like (of 110 109) then try changing 
(%d of %d) in message.php into something like (%d RTLlanguagecharset 
%d) and it should work. Translations just need to be updated.

It's not perfect, since the header is still not correct when using RTL 
translations, but it's an improvement, and RTL subjects are correctly 
rendered now. Nice work, thanks!

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/docs/CHANGES?rt=horde&r1=1.699.2.379&r2=1.699.2.380&ty=u
http://cvs.horde.org/diff.php/imp/message.php?rt=horde&r1=2.560.4.58&r2=2.560.4.59&ty=u
http://cvs.horde.org/diff.php/imp/templates/message/navbar_top.html?rt=horde&r1=1.6.2.2&r2=1.6.2.3&ty=u

I think I've fixed this without a need to make new CSS classes. Take a 
look at the patch and 
http://www.w3.org/TR/CSS21/visuren.html#direction. I'm not sure if 
this is the right way to fix it, but at least it works on IE8/7, FF3, 
Opera9 and Safari3 both on RTL and LTR languages.



Oh, and of course POT file needs to be updated.



P.S. sorry for the CVS patch. I hadn't much time to dive into Git just yet.

Can you make a patch of that?

Ah, yes you a right. The name should be the same for both ltr and rtl 
translations.

That doesn't make much sense to me. If you have two class names with 
simply implement the different text directions, you can use the css 
rule inline as well. Or do you mean that you need a class that has 
always the opposite of the default direction? But then it should have 
the same class name.

OK, I finally got server with RTL language locales and tested. SPAN 
containing message numbers is displayed left-to-right, so this doesn't 
work. Can I propose adding new .ltr { direction: ltr; } class in 
horde/themes/screen.css and .rtl { direction: rtl; } class in 
horde/themes/rtl.css to override default browser behaviour in such 
cases?

Sorry I don't have any RTL locales installed on my server, so can't test it.

And does this still work with an RTL translation enabled?

Separating string by the first "(" sign and inserting the second part 
into <span dir="ltr">second_part</span> does the trick at least on IE8 
and Firefox.

I'm pretty sure that this doesn't work, because it's a problem of the 
browser rendering, not of how the string is constructed. But if you 
can make it work somehow, that would be great.

Maybe we can split the whole string into 2 or 3 parts separating 
message topic from the rest?

Reading again what I wrote, it doesn't make much sense to me anymore, 
since this should only affect RTL translations. And obviously it only 
works with UTF-8 encoded translations. I really don't know how to 
properly deal with a mixed charset/RTL/LTR string though, yet.

I have tried couple of times inserting U+202D character into needed 
string but PHP only produces garbled characters like â&#128;. Can you 
describe a little bit more how it should be inserted?

http://horde.org/horde/docs/?f=po_README.html#right-to-left-languages

I'm pretty sure this has been fixed when I discovered the Unicode code 
points to override the normal text direction. If not, then the 
translation has to be updated accordingly, see po/README.

Jan, any change here either with newer PHP versions, or maybe the intl 
library?

This happens with all RTL languages and sprintf() calls, and I have 
absolutely no idea how to fix that.

Sample message for testing.

Hello,



if message subject is encoded in utf base64 encoding, subject is 
garbled in message view. See screenshot.