>Anyone know a good reference source for issues relating to localization? We are porting one of our main apps to several languages including some with non-latin alphabets. We've got a good framework for dealing with captions, help-text, etc. but I'm not sure how one works with other language versions of VFP and Windows for that matter. For instance, all the forms in this app have a combo box that lets the user select a language from a list they are licensed to use; when the user selects a different language than the one currently in use, all prompts/help-text/etc change immediately. It would be very helpful to also switch VFP and Windoze on the fly as well. Any thoughts? (Is this possible?) I realize the VFP5ENU.DLL would need to be 'replaced' somehow (how?? :) but I'm unclear on what to do about Windows.
>
>-Arne
Just to add a couple of issues here.
First, VFP doesn't directly support Unicode. It has some functions for double-byte character sets, but they're primarily dedicated to communicating with APIs which do. Probably the Chinese and few other versions of Fox do use double-byte characters, but for that part I have no idea how it works.
This means that any string you display on the form or report will display in system's codepage; this can't be changed without a reboot, and isn't even safe, because you need .fon files for the specific codepage for your system to function, and you need all the .nls files as well. Changing the ACP value in registry may stop your Windows from being bootable if some of these files are missing and/or wrong.
One table can have only one codepage. This doesn't mean it can't contain data in more codepages, but only pure ASCII characters (which are contained in any codepage as a subset) and the characters in the table's codepage will display right - all others will be wrong. For instance, I'm using codepage 1250, so my five specific characters š (s caron), è (c caron), æ (c acute), ž (z caron) and ð (d dash) display fine for me - but if you have these bytes somewhere in a 1252 table, è (c caron) will display as e acute (and e acute displays as c caron for me), and æ (c acute) will display as ae ligature.
In report designer, it pops up a font selector which has a script picker combo, but it actually doesn't give a damn about the script - it uses the system's codepage again.
Once I experimented by running "regedit myCP.reg' from autoexec.bat, and booted into 1250, 1252, 1251 - and VFP displayed its strings as Eastern / Western / Cyrillic.
VFP5ENU.DLL will get installed if you build your exe using English version of Fox. You'd have to rebuild it in a specific language version of Fox to have some other language be Fox's language, but I don't think you have to do that. Fox can already display in any language you want (just give it a proper codepage), and you can intercept most of the error messages and other strings it will display, and supply yours. The few strings that you can't avoid (like "Running query", which was the only one I couldn't get rid of in FPD) are simply not worth the trouble, and aren't particularly important.
Besides, recompiling with a different localization of Fox may lead to numerous new gotchas... and an unpredictable length of time. I wander if someone tried it.
