Hi all,
I have a client that need to review if their application will be able to run in Saudi Arabia where there seems to be a law that all data must be stored in their Arabic language. If we leave the fact out that there is the R2L input issue and we assume they will capture it like the English language and just use the special characters and we set the code page for the database and application to something that supports Arabic (if at all possible), is there anyone out there that might have any experience with doing something like this and perhaps have some pointers or 'gotchas' that we need to look out for?
This is for OE11.5 running Windows (WebClient) with a Linux (*nix) database.
Thanks in advance.
I'm far from being an Internationalization expert and I'm confident other Community users will share their working experience with Arabic language but here are a couple of useful places where you should hopefully find some relevant information about Internationalization and OE.
Our Product documentation has a full book about it. Here is a link: documentation.progress.com/.../dvint.pdf
Our Support guys have put together a good KB about all I18N startup parameters. Here is the link to that kb: knowledgebase.progress.com/.../20633
Hi,
OpenEdge has support for Arabic. For working with Arabic data using OE, it needs to use supported code pages.
Following code pages can be used for arabic, 1256, 709, 708, 721, 711, 786, 714, 710, 720
Or you can create UTF-8 enabled OE database, and OpenEdge run time startup parameters as UTF-8.
and you need to download arab specific promsgs from ESD.
For more information on code pages for languages
knowledgebase.progress.com/.../19799
Regards,
Rajesh
Hello Mark,
I've used used progress and Hebrew (which is also r2l) for many years on both gui and chui, windows and linux, with english l2r labels and all hebrew r2l ui's.
Codepages are not a problem whether it's the traditional single byte codepage or unicode codepages.
If you have a mix of gui and chui ui's, you will need to be aware of the bi-directional algorithm (bidi).
In gui, text is displayed in the order it is written (r2l for arabic and hebrew) and stored in the order it is read.
In chui, text is displayed in the same way it is stored which is in the order it is written, and which is a problem for sorting, indexing etc. and does not match with gui. I can provide further examples.
Progress does not have support for bidi.
If you are going to have a complete Arabic labels and r2l ui and your framework or application does not support it then it could be a huge redesign.
I'm more in favor of web ui's and would be happy to recommend ui frameworks, I've used.
HTH