A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
We added Unicode & regionalization to our VB6 app at a previous job.
My advice to you would be to switch to VB.NET.
It'll be easier. Trust me.
Wednesday, October 24, 2007
Yes, VB.NET would be easier but for the existing VB6...
 Make sure you have Unicode support and develop on a machine and OS that supports multilanguage (Win2000, XP, Vista)
 Better than just going totally international, it'd be better to know which specific countries you first want to target.
 Install the desired languages from Regional Options in Control Panel. Know that the languages can be divided into several "groups" according to similarity so :- English, French, German, Dutch would belong to the same group - Japanese, Korean, Chinese belongs to another group requireing 32-bit Kanji character unicode support, Arabic is another group and Thai (Sanskrit) belongs to its own separate group altogether/
 MAKE SURE you have the keyboards that support the different languages you want to use (and the translators!)
 Try using the resource file (.res) in VB to make sure the menu strings are being displayed properly. Make sure you have a menu choice to switch to anoter language.
 If you are accessing a database, make sure your database supports the languages you desire and is able to store it.
 Use the MS-Arial Unicode font in all your forms - it is able to display in the different languages.
 When you select from the Font property for each control there is a dropdown called Script. Make sure you use the right script set.
 You may need to cut-and-paste language translations. I find MS-Word useful.
I did a multilingual program in English, Japanese/Chinese and German some time ago in VB6 and Access 97. Works fine. I translated my accounting software (some portions anyway) into Arabic before that...works fine. No problems. YOu may need to do some trade-off. For example, since in Arabic everything is left to right and we had already done everything right to left, we left it as is..the consultant told us it wouldn't matter to the Arabs.
Sorry, I left out an important method I used. The english version and their other language equivalents I stored in a table which I linked to the various Label controls (for headers) I had on my VB6 forms. During Form_Load(), I checked the language being used and accessed the Access database table to find the right translation.
Sorry, another point. You'll be testing the language display a lot on the VB forms when you run the program. Before you do this, you must switch to the relevant language set IN THE WINDOWS O/S FIRST and check that the languages are first being displayed properly in Windows.
Thanks for your insight.
A question about Unicode. Our initial translations will be US English, German, Spanish and French. We have no plans to translate our VB6 suite into Arabic, Hindi, Chinese or Japanese. We will plan for that when we refactor into .Net in 2009. Given this, is Unicode support a must to support those European languages?
Second issue: you touched on "... make sure your database supports the languages you desire and is able to store it."
I've been concerned about this. We have a lot of tables in our system that have "Code" and "Description" fields. For example, inventory part IDs and their descriptions. We use SQL Server. Is there any mechanism in SQL Server to add a "third dimension" to a field to allow storage of a language-specific value? Or do companies as a rule limit their translations to form elements only?
No, Unicode is not a must for these languages, you can use code pages for them.
As for the database, best way is to have a separate database for a culture. Of course, if you plan to use more then one language in the same environment than it would be a problem.
Saturday, October 27, 2007
Goran is right - you don't need Unicode for the Romanized based languages because as I have pointed earlier, they belong to the same group as English.
SQL Server supports multilanguage so you don't have to worry. I'm assuming you have to switch language in one app so you will need separate database columns to store the terms in the individual languages besides English, than read off the correct column with an SQL WHERE clause.
If you are commercializing separate full versions of the app in individual languages, than you can make multiple structure copies of the same database but store the data in the languages concerned.
You can start off with reading Localization and International Coding in the Microsoft Knowledge Base.
Monday, October 29, 2007
I have a copy of this book you can have for the shipping cost. Still have the CD too. I'm in the Washington DC area. Email me if you're interested.
Have you considered http://www.whippleware.com/vblm.htm yet?
Sunday, November 04, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz