<div dir="ltr">Hi Gaetan , <div>I'm Karam Qubsi from the Arab world </div><div>my native language is Arabic . </div><div>I wish I can help you . </div><div>about the Arabic in Koha , I think we have these issues  : </div>

<div>1- the directions ( from right to left ) could be done by editing the css files or create new one for all rtl languages see bug <a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8061" style="color:rgb(102,51,102);font-family:Verdana,sans-serif;background-color:rgb(240,240,240)" target="_blank">8061</a> and there is some css  files works from right to left may help you and you can help us to make some patch make it built in by default in koha for rtl languages ( i'm new to git and perl ... Im learning now ! <img src="cid:330@goomoji.gmail" style="margin:0px 0.2ex;vertical-align:middle" goomoji="330"> </div>

<div>2- Koha have problems in the current release relate to encoding and Bernardo solve this in the bug <a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6554" style="color:rgb(102,51,102);font-family:Verdana,sans-serif;background-color:rgb(240,240,240)" target="_blank">6554</a> many thanks for him . </div>

<div>3- zebra search engine : we must use ICU , but this still have problems with the suffix and prefix in Arabic ... I searched and solve this problem using transliterate rules that ICU uses you can read about this in this wiki page : </div>

<div><a href="http://wiki.koha-community.org/wiki/Correcting_Search_of_Arabic_records" target="_blank">http://wiki.koha-community.org/wiki/Correcting_Search_of_Arabic_records</a><br></div><div>I will update it with another good code . <br>

</div><div><br></div><div>4- I think there is now just one problem about encoding is when creating  </div><div><br></div><div>5- in some cases we may edit manually the .tt files like in browsing for patrons we have a b c ... but the Arabs patrons my have names in Arabic characters  so we have to add : Ã  È Ê ... and not remove tha a b c .. some libraries in Arab worlds use the abc ...  </div>

<div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Mar 28, 2013 at 11:25 AM, Gaetan Boisson <span dir="ltr"><<a href="mailto:gaetan.boisson@biblibre.com" target="_blank">gaetan.boisson@biblibre.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


 Dear all,<br>
<br>
a pretty long call for help, but please read on if you know anything about handling right to left scripts, or if you're just interested in it.<br>
<br>
I am working on a project in Iraqi Kurdistan on behalf of BibLibre and have been reading quite a lot on the various problems typically encountered with text that flows from right to left, and especially when mingling text that flow in opposite directions in the same display.<br>



<br>
 To sum it up briefly, and as far as i understood, displaying the data should be fine whenever there is only one run of text in an element. Things get tricky when your run of text ends with a neutral character (a character that doesn't have an inherent direction in which it should be read, such as a punctuation mark) or when you have different directional runs one after another (Imagine the arabic title of a book called "Learn HTML4 in 24 lessons", where "HTML4" and "24" would be written in the latin alphabet for instance. Also, reading about all this, i learnt that arabic is written from right to left, except for numbers which are written from left to right). In those cases, the "bidi algorythm" (the thing in charge of displaying bi-directionnal text properly) will find itself in an unclear situation and can make the wrong choices. This results in things like (What you will see below here seems to depend on what you use. I can tell you it's not displaying well in thunderbird 17.0.4 on Ubuntu) :<br>



<br>
ÊÚáã HTML4 Ýì 24 ÏÑÓÇ<br>
<br>
The words are the right ones, but their order is messed up. To an arabic reading person what we have here doesn't make sense, it's like "in 24 lessons HTML4 Learn".<br>
<br>
What happens here is that we have 3 directional runs (not 5 : Ýì 24 ÏÑÓÇ is just one run from left to right, with the numbers being read from left to right as they should, but it's still the same run. Yes my mind is crying too ;) )<br>



<br>
ÊÚáã<br>
HTML4<br>
Ýì 24 ÏÑÓÇ<br>
<br>
This is the order in which they display in my thunderbird, and they should display in the reverse order. (I have saved a record with this title in Koha and the display *is* messed up in a ltr interface, it's fine if the interface is in arabic.) It seems thunderbird is messing things up because it is ordering them according to its context, which is left to right. But if you copy and paste the full line in a more simple text editor such as Gedit, you will get the right order, unless you start typing things in the latin alphabet at the start of the line (which will be on the right side). Then you will have a messed up order, aligned on the left.<br>



<br>
Now, when we will migrate the data for this project i would like to take all measures to make sure things will be understandable in all possible contexts. That is whether the interface is displaying in a left to right or right to left language should not matter.<br>



<br>
There are unicode invisible characters that can be used to say "this whole stretch is left to right" (or the opposite), or even some characters which cannot be seen but which are "strongly typed" rtl or ltr and can be inserted at the right place to clarify the context and fix things.<br>



<br>
What i am tempted to do is to enclose all strings in those characters during the migration, according to the language used (an information i can find elsewhere in my data). Or just add the "clarifying" character at the end (or beginning ?) of the string. I guess it would be a good idea then to do this in all cases, that is not just for rtl languages in the data, but for both. (Even though chances are english books will have much less mixed scripts in their metadata than their arabic counterparts. This just seem like a justified equal treatment.) Is that the right way to proceed ?<br>



<br>
One last thing is that when cataloguing new documents, i guess the librarians should pay attention to this. Should we then train them to use these characters at the appropriate places ?<br>
<br>
If you have experience with this and can provide some advice as to the solutions usually put in place, i'd be extremely grateful if you could share it. I intend to get a good look at that and put some effort into fixing a few things on the way. ;)<br>



<br>
Thanks,<br>
<br>
If you read all this just out of interest, go to the W3C pages on bidi text, they are extremely informative and well written :<br>
<a href="http://www.w3.org/International/tutorials/bidi-xhtml/" target="_blank">http://www.w3.org/<u></u>International/tutorials/bidi-<u></u>xhtml/</a><br>
<br>
-- <br>
Gaetan Boisson<br>
Chef de projet bibliothécaire<br>
BibLibre<br>
06 <a href="tel:52%2042%2051%2029" value="+96352425129" target="_blank">52 42 51 29</a><br>
108 avenue Breteuil 13006 Marseille<br>
<a href="mailto:gaetan.boisson@biblibre.com" target="_blank">gaetan.boisson@biblibre.com</a><br>
<br>
______________________________<u></u>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-<u></u>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.<u></u>org/cgi-bin/mailman/listinfo/<u></u>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.<u></u>org/</a></blockquote></div><br><br clear="all"><div><br></div>
</div></div></div>