Hi All,

We have added two-lines to "class/module.textsanitizer.ph" in order to make right-to-left comments/messages/submissions render correctly in XOOPS.
This is necessary for languages like Farsi (our case), Arabic and Hebrew. See here for an example.
This is the code added:



Can we have this added to XOOPS as a feature? That would be great. We can enhance it a bit more, e.g. with a button, but for now this will do.

Greetings,
azeini

There are some other discussions on RTL languages in the forums if you search for them.

However, I think none addresses this point. If the whole site is in one language then you can just set a global LTR or RTL flag for the whole page, but when you have the possibility of mixed languages that breaks down. I think that is what your comment is addressing. e.g. If you use the multilingual content hack with [english]abc[/english][farsi]xyz[/farsi] then sometimes you have to switch text direction. I guess one way is for the multilingual hack to automatically make 'english' text LTR and 'farsi' text 'RTL'. The other option is as you have suggested.. an extra square bracket code for 'rtl' text. I think automatically tying it to the language is the best way to go. Would there be any reason not to do that? Am I maybe misinterpretting your usage?

Anyways, thanks for bringing up this important point, which ties into the multilingual content idea.

Thanks for taking this matter up.

I think, we have to differentiate between two distinct areas concerning RTL scripts:
1. Site layout and language/script
2. Content: i.e. news submissions

To 1: In order to make things easy, I would like to see this setup during the installation procedure. A question about the language or direction of the site would add a dir="RTL" to the main tag. A pre-requirement for this to function correctly, would be the UTF-8 setting.
Something like this could be done.

To 2: But this doesn't solve the problem of news submissions, comments and posts to the forums. There you might still have LTR and RTL content mixed. Here the tag that I mentioned would be enough, I would not use language specific tags, because it is not necessary. The character set that you are using is handled by the charset setting of the site, stylesheets and fonts specified. The only thing needed, which AFAICS is common to all three or four RTL languages is the direction. So a [rtl]test[/rtl] would do just fine for Farsi, Hebrew, Arabic and other Arabic script using languages (which Farsi is one of).
You are right with language specific tags in the event that this feature is going to be added to XOOPS anyhow and it would be added for these language because of the direction. Otherwise i see in it more of a complication rather than a simplification.

Hope this helps.

OK, I think I see what you are saying. I think I was assuming too much this is like the 'multilingual content hack' thread. i.e. I thought you wanted to enter the content of e.g. a news article in multiple languages using the square bracket notation described in that hack. The reason for the language tag is so that only *one* version is shown when someone visits the site. The tag is the only practical way for XOOPS to know which part is to be shown to users who have selected each language. Because you would specify the language, there is no reason it could not automatically know whether that language is RTL or LTR.

What I *think* you mean is that you would enter the post content in one langauge e.g. Farsi, and you want to force this to be RTL with the [rtl] tag. You would never actually indicate this is in Farsi other than the specific characters you had entered... The purpose would be to always show this text as RTL regardless of the "main" langauge of navigation etc. for the site. Is this a correct interpretation of what you mean? If so, I can understand your desire to have RTL.

However, I think XOOPS will eventually have in the core some support for multilingual *content* and as you seem to agree, the rtl/ltr tags would be redundant. I think a lot more discussion is needed on how best to improve the multilingual capabilities of xoops.

Quote:
Yes, this is exactly what I mean. The multinlingual hack "sorts" content based on the interface language which can be choosen from a drop down list. But this is only one issue.
Important for us is to be able to mix content. Our site for example is in English only, but we use a lot of Farsi content and in the same post we mix RTL and LTR. Our hack enables us to do this and just this.
But even the multilingual hack that you mentioned still needs this tags IMHO. Because RTL users need to be able to post a News, let's say, in Farsi to be sorted under the Farsi interface of the site, but at the same time they are mixing in that post RTL and LTR. Which means you need to be able to tag the interface language and the text direction.

Since this hack of ours is little and fits well within the XOOPS concept, so I think, is there a possibility to add it to XOOPS regardless the progress of the multilingual hack?
Thanks a lot for your attention.

Hmmm, OK, point taken. For mixed content it seems necessary. How do other scripts deal with this? Do they tag each component part and auto-determine LTR or RTL or do they just use UTF-8 and the characters basically 'determine' the language and explicit LTR or RTL is needed??

Anyways, will consider this for XOOPS core. I think there is a CSS text-alignment directive, e.g. in a 'div' or 'span' which would be preferable to the 'table'. This is because 'table' may have all kinds of other CSS associated with it which might introduce borders and other alignment and percentage widths around the e.g. farsi text. I will look into this.

I am not sure if I understand the question about the other scripts. But if I get it right, for a correct HTML rendering you need always the explicit LTR or RTL attribute in your tags. Just using UTF-8 won't work.

And thanks, it would be very useful to have these tags inside XOOPS core. As long as it is there and it renders correctly, it is fine with me :) no matter if it is inside table or somewhere else. In fact, I have noticed that Mozilla has a problem with rendering these mixed contents correctly. This might have something to do with the fact that we use it in 'table'.