internationalisation
-
Having finally started migrating from VS6->VS2010, we have our first attempt at internationalisation looming. What is current best practice for foreign language versions of C++ apps? Can anyone speak from experience?
All you need to know is unicode. all the text strings should be converted to unicode format. [1]make a collection\ identify of all the readable text string on your apps gui. [2]convert all the char buffers used to process the text strings to wchar buffers (char : 1 bytes and wchar 2:bytes) [3]MFC CString will automatically behave as unicode when you declare your app as unicode application either by mentioning #define UNICODE #define _UNICODE in stdafx.h or some global file which is accesible to all the other files. You may also use app property dialog to declare your app as unicode. While convering text from ansi to unicode, WideCharToMultiByte and MultiByteToWideChar APIs will be required. this is just some hints to proceed...you may be required to do other tasks as appropriate depending upon your app.
-
All you need to know is unicode. all the text strings should be converted to unicode format. [1]make a collection\ identify of all the readable text string on your apps gui. [2]convert all the char buffers used to process the text strings to wchar buffers (char : 1 bytes and wchar 2:bytes) [3]MFC CString will automatically behave as unicode when you declare your app as unicode application either by mentioning #define UNICODE #define _UNICODE in stdafx.h or some global file which is accesible to all the other files. You may also use app property dialog to declare your app as unicode. While convering text from ansi to unicode, WideCharToMultiByte and MultiByteToWideChar APIs will be required. this is just some hints to proceed...you may be required to do other tasks as appropriate depending upon your app.
Internationalisation is a huge topic, but a few pointers: 1. separate all UI strings from your code (string tables are a must in Windows) 2. do localizing into 1 other language in parallel with development to catch problems early 3. use industry standard tools (SDL, memoQ, Idiom, LocStudio if you can find it) for localizing, avoid developing your own tools 4. use the operating systems services whenever possible (NLS functions in Windows) Good luck!
-
Having finally started migrating from VS6->VS2010, we have our first attempt at internationalisation looming. What is current best practice for foreign language versions of C++ apps? Can anyone speak from experience?
"Internationalization" is not simply a matter of understanding character set representations. Potential issues. 1. Understanding culture differences (do your custom icons represent an obscene gesture?) 2. Correct GUI layout. 3. Grammatically correct dynamic output. 4. Verifying that translated text is actually translated correctly. 5. Laws/legal matters that dictate "correct" representations. An example is that some places dictate the use of specific timezones.
-
Internationalisation is a huge topic, but a few pointers: 1. separate all UI strings from your code (string tables are a must in Windows) 2. do localizing into 1 other language in parallel with development to catch problems early 3. use industry standard tools (SDL, memoQ, Idiom, LocStudio if you can find it) for localizing, avoid developing your own tools 4. use the operating systems services whenever possible (NLS functions in Windows) Good luck!
Thanks for this. We are starting slow, just targeting one other language to start, but obviously we want to set everything up to make adding other languages easier in future. We'll probably try and make a resource DLL per language. Thanks for the pointers to the tools too - I didn't know such things existed, so will have to look into them.
-
Having finally started migrating from VS6->VS2010, we have our first attempt at internationalisation looming. What is current best practice for foreign language versions of C++ apps? Can anyone speak from experience?
few additional points. 1) reading style ( right to left or left to right ) most of the is taken care 2) The language script may be same in two different languages but the way its words are interpreted may be different 3) On Windows dialog specially, you have to use different dialog template since the default fonts may not render character of UI in a given language. We face this problems in past, for Japanese font and we have to create a whole new set of dilaog boxes to maintain same look and feel of application throughout the running lifetime of application. 4) The size of executable.and code base itself, If your code works on special hardware ( like Credit card devices where limited amount of memory is available) This could be a huge problem HTH
-
few additional points. 1) reading style ( right to left or left to right ) most of the is taken care 2) The language script may be same in two different languages but the way its words are interpreted may be different 3) On Windows dialog specially, you have to use different dialog template since the default fonts may not render character of UI in a given language. We face this problems in past, for Japanese font and we have to create a whole new set of dilaog boxes to maintain same look and feel of application throughout the running lifetime of application. 4) The size of executable.and code base itself, If your code works on special hardware ( like Credit card devices where limited amount of memory is available) This could be a huge problem HTH
-
Abhi Lahare wrote:
- reading style ( right to left or left to right ) most of the is taken care
X| Tell me about it - we've already had a load of hassles getting Hebrew and Arabbic to work correctly - never mind Chinese :omg:
as far on windows box, all the arabic strings was acceptable to client. we have other hardware were standard font file did not work as desired and gave us a good amount of trouble. sorry I do not remember the details it was a long back 6 yrs back :) In case of Japanese and Chinese ( in different project ) we build a whole set of dialog boxes with different fonts for once user select the input language. The default (FONT 8, "MS Sans Serif") for us do not rendered the Japanese character. HTH