home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / mswindo / programm / misc / 4199 < prev    next >
Encoding:
Text File  |  1992-12-14  |  3.3 KB  |  83 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!ugle.unit.no!torstein
  3. From: torstein@itekiris.kjemi.unit.no (torstein hansen)
  4. Subject: Re: Programming for foreign languages
  5. In-Reply-To: rnelson@wsuaix.csc.wsu.edu's message of 12 Dec 92 18:56:58 GMT
  6. Message-ID: <TORSTEIN.92Dec14181739@itekiris.kjemi.unit.no>
  7. Sender: news@ugle.unit.no (NetNews Administrator)
  8. Organization: Dept. of Chem.Eng, Norwegian Inst. of Tech
  9. References: <1992Dec12.185658.13375@serval.net.wsu.edu>
  10. Date: 14 Dec 92 18:17:39
  11. Lines: 70
  12.  
  13. In article <1992Dec12.185658.13375@serval.net.wsu.edu> rnelson@wsuaix.csc.wsu.edu (roger nelson;S23487) writes:
  14.    I have written several DOS apps I can compile versions for English, Spanish,
  15.    French and Italian (someday also Castilan, Swedish, Danish and German)
  16.    I am porting these to ms-windows and would like no know
  17.    what is the best way to support foreign languages under windows.
  18.  
  19.    I am using both Borland C++ w/AF and Borland Pascal for windows, and
  20.    am new to windows programming.
  21.  
  22.    Presently I keep a file of constant declarations (Pascal) or #defines (C)
  23.    and include the file for the respective language at compile time.
  24.    I would prefer to sort out the language stuff at runtime because most
  25.    of my users want to be able to switch to another language but not have
  26.    to install a different version. 
  27.    But I don't want to take up space to read in the language strings.
  28.    The list of language strings must be easy to maintain and reorganize
  29.    since I have several hundred phrases for each language and I often add
  30.    new phrases.
  31.  
  32.    Does windows provide a facility for loading the strings for the language.
  33.    So far, all I have found in the Borland documentation is the function
  34.    which gets the language version of MS-Windows.
  35.  
  36.    Also is there a way to access strings used by windows so I don't have to
  37.    duplicate translations for things like: ('file not found', 'unable to
  38.    open file', 'file','close','save', etc...
  39.  
  40.    What I was planning on doing was the following:
  41.    Keep a language file for each language.
  42.    The file will have a number and a string for each phrases, ie:
  43.    1  "File not found"
  44.    2  "Save simulation file"
  45.       :
  46.  
  47.    A language definition file will keep a list of program defines:
  48.    #define L_File_not_found 1
  49.    #define L_Save_simulation_file 2
  50.      :
  51.  
  52.  
  53.    When the program starts or when a different language is selected, the respective
  54.    file is loaded in a linked list (search tree) indexed by phrase number.
  55.  
  56.    When I want to use the string I would use the following function:
  57.  
  58.       translate(language,L_File_not_found)
  59.  
  60.    Where language is the current language number returned by windows.
  61.    Translate would then lookup the phrase number in the search tree and
  62.    return the phrase string.
  63.  
  64.    Does anyone have a better way to do this in Windows?
  65.  
  66.    Thanks,  Roger
  67.  
  68. You could make a resource-only DLL with the translated strings for
  69. each of the languages you wish to support. You could then let the user
  70. choose wich language to use at install time. See the documentation for
  71. Borland Resource Workshop on how to make string resources.
  72.  
  73. I would recommend that you should have translations of all your
  74. strings, as a user may run the italian version of your program on an
  75. english version of Windows.
  76.  
  77. Good luck!
  78.  
  79. Torstein
  80. --
  81. Torstein Hansen
  82. torstein@itekiris.kjemi.unit.no
  83.