>Hi, Bhavbhuti.
>
>>I have this proposal to develop an app which works both as English and French.
>>
>>I do not mind having 2 compilations of the same app, but would like to avoid 2 sources at all costs.
>>
>>I have heard of localization .h files which contains all the strings in it. So whenever I want to print a string I use the STRINGCONST_LOC kind of line to substitute the string for the given .h file. Am I correct in understanding this?
>>
>>If the above is the way then how can I tackle menus prompts for this? I use class based menus and the prompt is stored in the class property, how can I assign the constant in a property?
>>
>>What happens to the framework based messages, if the above is followed?
>>
>>Can I get the app to switch languages on the fly so the person starting the app can switch between languages as required.
>
>Indeed, the best approach would be to have a table to store the translations. Universal Thread works this way all the time. We support English, French, Portuguese and Spanish.
>
>In the case of Menu pads, if you're using class-based-menus, it wouldn't be a big problem. For generated menus, you can enter expressions for that.
>
>You should also use a translation function or method in every place you have a framework message that should be translated. The same applies to reports, etc. All in all, it is a lot of work if you have the framework and the application already built.
>
>There are several commercial frameworks you can use which have multi-language capabilities built in. You may take a look at them. I think Mere Mortals have it, and also VPM, Codemine, and others.
>
>Best luck!

Yes CodeMine has it but if you have to include header (.h) files then CodeMine won't be of much help. If it's the case then INTL would be necessary.