Is there an easy way to translate code developed with FireFly into different languages and still maintain one source file? How can I use resource files for the string tables?
Regards,
Klaus
The way I've managed this in the past in a way that allows users to update the strings is to use an INI file for each language (English.ini, Spanish.ini, etc). A global variable holds the name of the INI file currently in use.
In the form creation routine I just call strings from the INI file and replace the standard text shown to the user.
Users can edit the INI file with a text editor and replace the standard text with their own choice of text.
One thing I always did when I offered this approach was to offer someone a free license for the software if they provided me with a new language file. Funny thing is that no-one ever took me up on it.
Andrew
I did it in the same way. But the changes are not present inthe FireFly files. If I change a form in FF then all modifications in the form creation routine are lost. The mullti lingual support I am looking for should be present in FireFly.
Klaus
Hi Klaus,
You are using FireFly incorrectly. You should not be editing the FireFly generated source code files because they are regenerated every time that you compile the project. Instead, you should put your code in the FireFly code editor. For example, create a new Module ('Project', 'Add Module') and put your language logic there. In the code editor for the Form, select the Form from the left hand side combo box and the WM_CREATE message from the right hand side combo box. In that function you can place calls to your functions created in the module.
Thank you for the help!
This solves my problem. :lol:
Klaus
I haven't used it, but I know for a fact there are different codes and such
to give to string resources and have them mapped to a certain language.
Plus the string loading routines can load the correct ones according to the users language settings. I don't have a resource open right in front of me, but I think English is like 1033 or something like that. Make all the resources have the same values, each in the language it is supposed to be in, and when loaded everything will map over.
The language codes (LCIDs) you refer to Roger are shown on this page:
http://www.microsoft.com/globaldev/reference/oslocversion.mspx
However you can get into trouble sometimes - it's often said that the UK and the US are divided by a common language.
I gave up trying to use compiled-in string resources to handle localisation, it was just too hard to keep everything up to date. Became so much easier when I did it via INI files.
Andrew
You could also compile a separate DLL for each locale and LoadLibrary as needed. The DLL would contain routines that would retrieve specific language elements for your Forms/Controls.
Quote from: TechSupportYou could also compile a separate DLL for each locale and LoadLibrary as needed. The DLL would contain routines that would retrieve specific language elements for your Forms/Controls.
That means additional work creating, compiling and distributing DLL's.
StrText = GetIniString("FrmMain", 1234, "Tooty Fruity") works for me.
"FrmMain" refers to a section in the INI file by that name.
1234 is a reference to the language string I'm interested in.
"Tooty Fruity" is the default if the language string doesn't exist. And if it doesn't exist "GetIniString()" puts it into the INI file so that the user (or author) can come back later and modify it.
A global string variable holds the name of the INI file which can be switched instantly to a new language.
Andrew