Convert VC++ mfc application multilanguage

what do you mean by 'multilanguage'? just to use another language for the offshore variant of your application? or to have a switchable application which you can run either in native or offshore mode?

if you have the first, you may add rc files where all text was translated to the new language.

then add a further rc file which can switch between the rc files:

// lang.rc
#ifndef OFFSHORE_LANG
#include "lang1.rc"
#else
#include "lang2.rc"
#endif

Select allOpen in new window

in your project you would exclude both lang1.rc and lang2.rc from build and add lang.rc to the resource files.

finally add a new configuration to your project where you define OFFSHORE_LANG in the preprocessor macros.

Sara

if you need an application which either can run the one or the other language, you could use a resource dll which you can exchange at the destination site depending on the language required.

Sara

Currently  I  have  application  with two  rcs   for different screen  resolutions  not for  language.
I  have to develope application  in   which  should  have  option to select  a  language.
Once  language is selected,All  application  labels,buttons,grid  and  messages  should  come in selected language.
Maintaining  differnet rc for  each language  is  not possible.As  application  is  continue  to upgrade,means  as per  clients  requirement  modifications are continuously  done.There  are currently more  than  200  clients.
Please suggest way  other  than maintaining  different  rc  files.

Please suggest way  other  than maintaining  different  rc  files.

you probably have more than one .cpp file. what is the difference to having more than one .rc file? the solution i suggested actually only uses 1 rc file 'lang.rc' for build while the lang1.rc and lang2.rc only were included.

in visual studio you can open thousand rc files for a project. i even have maintained projects which have one dlg (resource) file per dialog.

there are 3 commonly used and proved solutions for your problem:

(1) use different language rc files and do the switch by configuriation (means you have two builds, one for each language)
(2) use a resource dll (project) for each language.
(2a) have two configurations where you link the right resource dll to your project
(2b) deliver both dll's and use the right one at the client site.

all these are clean but were using multiple resource files.

i can think of solutions which uses only 1 rc file:

(a) put any text resource in your rc file into a #ifdef LANG1 #else #endif  sequence
(b) replace any text resource in your rc file programmatically in custom pre build step into the translated text
(c) replace any text programmatically after loading the resource file by using the text, dialog or control id.
(d) replace any text used in any of the resources by "translating" it to the wished language using an own translator
(d) use a cloud translator for the before

(a) prevents you from using the resource editor for your rc file
(b) needs some kind of wizard project where you try to to "translate" the texts in the rc file
(c) needs a database where you maintain all texts of your resource file by id. you can't use IDC_STATIC no more.
(d) ???
(e) probably there are some good translator engines available in the cloud.

you may consider whether the results of those complex solutions could be sufficient for your purposes.
 
Sara

In VC++ 2010  we can  create  multiple  string tables  of  different language,

yes, string tables are a good way to translate multi-language strings.

Now  with  help of SetDlgItemText  we can  put that text.

that isn't a practicable way to translate dialog resources. it is error-prone and you have no visual feedback when creating the resource for the second language. note, some texts will get longer when translated or even have more lines. you would have to add string resources for any control and any language and make a visual test with your application for each little change.

Sara

As a client  based  software,our  main  rc  file is  also  subject  to change  constantly  so we cannot  maintain  so many rc  files maintained constantly. Instead  we have decided  to  put  limit  to text size  when  client  provides  language  script.

As a client  based  software,our  main  rc  file is  also  subject  to change  constantly  so we cannot  maintain  so many rc  files maintained constantly

but you can maintain hundreds of string id's instead and map each of them to a control id and dialog? you may see how much work it makes by creating a sample form.

you should not underestimate the efforts that goes along with that design.

it is 15 years ago when I made a similar approach to put all texts of a huge application (a solution with 50 projects and 10 million lines of code, more than 300 dialog forms and about 10 thousand text strings) to a text file. the reason was not to support a second language but to reduce the amount of stack space needed for the texts and so decrease the load times of the executables.  actually I had to develop a new wizard project in order to support that design. we created id's automatically from the resources and automatically moved the texts from rc file to the text files. nevertheless, the process to maintain the strings was enormous and I doubt that we would go the same way if we had to make the decision again.

but it can be made this way and I wish good luck.

Sara

I  found  string table  approach  quite  better