Foreign Language Interface

Actually I should get "Paid" for this suggestion!. If i were a consultant, i would have charged half my yearly salary for this .. Are you one, by any chance :-)
--
There are actually 2 levels of changes. 1- Physical/Apparent ones and 2: Code level/string handling routines.

For 1: Change all the Captions etc to new language. Your case is even more complicated because you are changing to Arabic, which is Right-to-left Reading style.
Most of VB controls support RTL reading. So you have to change the properties of *ALL* text boxes, list boxes etc. Then the Scroll bars etc need to be set to the Left hand side. Which may be automatic for RTL mode.. i dont know.

You would require a complete respositioning of all controls. Because Labels will come on the RHS of txtboxes etc. Also, keep in mind that the label size may change. So intricate positioning should be avoided, if possible.

Apparently "silly" things like Default font for text boxes etc can cause quite a bit of work..having to go thru every form etc..

Then all the message boxes need to be changed. If you have the message strings embedded in code like

Msgbox "File not present :" & strfilename

then this is the best time to move them outside. either into a resource file or custom formats or like i do - into a database.

msgbox LoadResString(someid) & strfilename ' VB Fn

You should also realise that the order of information presented would be different in other languages: So typically the above message would go to something like:
"File not present %1" or "File %1 not present", (well this is not all that perfect example, but you get the point)
which would then be translated to the target language. and then a typical overhead will be

tmpbuf = LoadResString(resourceid)
FormatMessageString tmpbuf , strfilename ' this is not Vb fn!
msgbox tmpbuf

This is specially true with multi-part messages.

For 2: Your string handling routines would require a re-look. Luckily for you VB is unicode inside, so transition would be quite smooth. and Arabic is Multi-byte, i am sure.

Functions like Len, Mid work little differently for composite strings ( ie those that contain both single byte & multi-byte sections) Most of the string handling functions have their 'Byte' conterparts. You may require to specify them occasionally!

If you are using API calls heavily, you sure need to check those sections too. API fns which change their respose under different language settings are well documented, in MSDN.

I dont know How Oracle handles Multi-byte,
I am sure there is good enough support ( lot others must be using too) but you should check that too. Parts where the data is going to/from DB...

This happens in Japanese.. so quite likely in other MB langs too.. Each of the english aplhabet also has its Multibyte Counterpart!. So normal 'a' which is Ascii 97 also has a double byte value of 0x8281 (hex). Well it is actually not the same 'a'. If you are doing some parsing logic for Spaces, Hyphens, BackSlashes etc you need to account for Double byte "Spaces", "Hyphens" ( i dont think Backslash has a MB couterpart!) or use Vb functions like StrConv etc.

If you notice, essentially all the precautions required for Multibyte support + UI modifications for the Right->Left Reading style . Just that simple!

well.. now when are you sending me my cheque :-)

RK