Multilingual suggestions
-
Hi My current project involves upgrading an application from VB6 to VB.Net and make it multilingual. The upgrade part I can handle. Do you people here have any suggestions/gotchas/pitfalls etc. related to the multilingual part. I am already reading the Globalisation articles on MSDN. I need some real world issues faced etc. Any help will be appreciated. Shreekar
-
Hi My current project involves upgrading an application from VB6 to VB.Net and make it multilingual. The upgrade part I can handle. Do you people here have any suggestions/gotchas/pitfalls etc. related to the multilingual part. I am already reading the Globalisation articles on MSDN. I need some real world issues faced etc. Any help will be appreciated. Shreekar
Hi Shreekar, One very simple, yet significant problem that I have come across a few times in the past, is the way users change the language in an application. In the beginning I never even considered it, but a user who (really) does not speak the language the application starts up in, will not be able to find the bit of the GUI where to change the language to his/her own. As system admin I was forced to run around a lot, changing the language to whatever was preferred (= a hassle). Tip 1: symbols and colours are easier to use than words, and will greatly reduce the amount of time coding in different languages. Tip 2: keep language choices at the top of the GUI. Tip 3: use a database for the different languages (Name: Button1, Lng1: Button, Lng2: Knop, Lng3: Knöpfe, Lng4: Näppäin, etc.), and rather build in a tool that allows (certain) users to add and/or correct languages, than hard coding each single language. This will also make it much easier to add new functionality and/or controls to your app in the future. Tip 4: national (culture specific) holidays are a -beep- to consider in coding. I found that it is easier to build in options for users to take them into account themselves. If you must however, I also recommend the use of a database. For what it is worth. Johan
-
Hi Shreekar, One very simple, yet significant problem that I have come across a few times in the past, is the way users change the language in an application. In the beginning I never even considered it, but a user who (really) does not speak the language the application starts up in, will not be able to find the bit of the GUI where to change the language to his/her own. As system admin I was forced to run around a lot, changing the language to whatever was preferred (= a hassle). Tip 1: symbols and colours are easier to use than words, and will greatly reduce the amount of time coding in different languages. Tip 2: keep language choices at the top of the GUI. Tip 3: use a database for the different languages (Name: Button1, Lng1: Button, Lng2: Knop, Lng3: Knöpfe, Lng4: Näppäin, etc.), and rather build in a tool that allows (certain) users to add and/or correct languages, than hard coding each single language. This will also make it much easier to add new functionality and/or controls to your app in the future. Tip 4: national (culture specific) holidays are a -beep- to consider in coding. I found that it is easier to build in options for users to take them into account themselves. If you must however, I also recommend the use of a database. For what it is worth. Johan
Johan, thanks a lot for the tips. Will keep those in mind. I am thinking of using satellite assemblies for storing the labels and messages text instead of a database. After your thoughts, I will do a rethink. Another challenge for me is to modify the installation process so that the user can choose the language during install. I am not sure whether the Setup/Deploy architecture in .Net allows for this kind of customisation. Any suggestions on how I should determine the width of the labels to accomodate differing length strings? Shreekar
-
Johan, thanks a lot for the tips. Will keep those in mind. I am thinking of using satellite assemblies for storing the labels and messages text instead of a database. After your thoughts, I will do a rethink. Another challenge for me is to modify the installation process so that the user can choose the language during install. I am not sure whether the Setup/Deploy architecture in .Net allows for this kind of customisation. Any suggestions on how I should determine the width of the labels to accomodate differing length strings? Shreekar
Hi Shreekar, I definitely recommend the database approach over all others, if future development/extension/maintenance of your app is a consideration, you could even use an xml-file for this purpose, if the app does not use a database to begin with, or if you can't afford it to use too much of the client PC's resources. If it isn't, and you don't have too many languages to worry about, than you should probably stick with your original idea (I wrote one app myself that uses a similar approach, because it only has two languages, and not all forms needed to be translated). I am sorry to say that I have limited experience only with adapting the installation process, but I do know that pretty much anything is possible with the VB.NET installation project, and I am sure there are some walkthroughs available, or someone else may well have built something similar already. On the other hand, you could save yourself a little trouble, by installing/starting the app in a default language (say yours), and offering the user a choice on startup, which will then be saved somewhere For buttons, again I recommend symbols/pictures over text, and the use of tool tips (stretch automatically). Label / field width is something I have struggled with myself, and there are four approaches that I know of: 1. Make sure the label is a little bigger than the longest possible string that will be fed to it. You could make some function that will determine the size of a label based on the string length, but you would still need to keep the space on the form open for the label to grow (= same difference). The good news is, that labels can be set to wrap text, so you can size them vertically if you have to. 2. Dialog boxes/temporary forms. With a function to determine the size, you don't have to worry about a label not fitting the form. 3. Use symbols on the labels, and feed the text to a tool tip per label. 4. Use text (Multiline: true) or list boxes, instead of labels and format them to look like labels (BackColor: Control, BorderStyle: None). These can use scrollbars. Johan
My advice is free, and you may get what you paid for.
-
Hi Shreekar, I definitely recommend the database approach over all others, if future development/extension/maintenance of your app is a consideration, you could even use an xml-file for this purpose, if the app does not use a database to begin with, or if you can't afford it to use too much of the client PC's resources. If it isn't, and you don't have too many languages to worry about, than you should probably stick with your original idea (I wrote one app myself that uses a similar approach, because it only has two languages, and not all forms needed to be translated). I am sorry to say that I have limited experience only with adapting the installation process, but I do know that pretty much anything is possible with the VB.NET installation project, and I am sure there are some walkthroughs available, or someone else may well have built something similar already. On the other hand, you could save yourself a little trouble, by installing/starting the app in a default language (say yours), and offering the user a choice on startup, which will then be saved somewhere For buttons, again I recommend symbols/pictures over text, and the use of tool tips (stretch automatically). Label / field width is something I have struggled with myself, and there are four approaches that I know of: 1. Make sure the label is a little bigger than the longest possible string that will be fed to it. You could make some function that will determine the size of a label based on the string length, but you would still need to keep the space on the form open for the label to grow (= same difference). The good news is, that labels can be set to wrap text, so you can size them vertically if you have to. 2. Dialog boxes/temporary forms. With a function to determine the size, you don't have to worry about a label not fitting the form. 3. Use symbols on the labels, and feed the text to a tool tip per label. 4. Use text (Multiline: true) or list boxes, instead of labels and format them to look like labels (BackColor: Control, BorderStyle: None). These can use scrollbars. Johan
My advice is free, and you may get what you paid for.
-
Thanks a lot again, Johan. Will keep these things in mind and will update you on how I finally manage this (if at all!) Shreekar
You're welcome, and I would like to hear how you did.
My advice is free, and you may get what you paid for.