|
|
|
|
|
- Home - Products - Tech Support - Downloads - Order - Contact Us -
Frequently Asked Questions (FAQ)
In this FAQ you will see references to a global Visual Basic® variable named gLG. This variable refers to the single instance of the Localization Guru localization engine that has been instantiated in your application. If you have the Lite version, then gLG points to an instance of LocGuruCtl on a form. In the Pro version, gLG is an instance of the LocGuru class. |
What are the differences between the Lite and Pro versions?
How many languages can be stored in a single language database?
How does Localization Guru translate my form using only one line of code?
Can I allow the user of my application to pick the desired language when the application is run?
Can I predetermine which language will be used by the application?
Can I automatically choose the proper language based upon the current locale?
How can I control which strings in my application get translated and which strings do not?
How is Localization Guru licensed?
What versions of Visual Basic® does Localization Guru support?
Is Localization Guru Year 2000 compliant?
Where can I find out more about localizing my application?
Question: What are the differences between the Lite and Pro versions?
Localization Guru Lite features:
Localization Guru Pro features:
- Uses Microsoft Access 97 / 2000 / 2002 for the language database, in which case your program must include DAO 3.60 in order to support the Microsoft Access language database.
- As an alternative to using a Microsoft Access language database with your program, you can use a text file version of the language database and thus you are not required to support DAO 3.60 or distribute the Jet 4.0 database engine with your program.
- The source code for the localization engine (LocGuru.cls) and for the Language Editor is included. If you want to make your own modifications to the Language Editor you will need to have a license for Sheridan Data Widgets 3.1. Since you get the source code you can add your own features to the localization engine. For example, you could change the localization engine so that it used SQL Server to store the language database for your program if you wanted to do that.
- Since the localization engine is available as a class module it can be compiled directly into your application thus saving you from distributing yet another OCX file with your application.
- The length restriction of 255 characters in a phrase that is present in the Lite version doesn't exist in the Pro version since native and foreign text in the Microsoft Access language database are stored in Memo columns.
- The localization engine can distinguish between phrases that differ only in case, so that you can have a separate translation for the native phrases "cancel" and "Cancel".
- An untranslated phrase in the language database (i.e. a zero-length phrase in the foreign language column) does not appear as a zero-length string in the localized product. This makes it easier to work with a language database that has been incompletely translated.
Question: How many languages can be stored in a single language database?
Answer: A lot! In the Microsoft Access version of the language database you are limited only by the number of columns that a table can contain. Access 97 / 2000 / 2002 permit 255 columns per table. There are four columns that are always present so that leaves you 251 columns that you can use to store 251 different languages in a single language database. Actually, you would probably want to use multiple language databases long before you reached this limit simply because of the size of the language database. In theory there is no limit (other than disk space) to the number of languages that can be stored in the text version of a language database (Pro version only).
Question: What languages are supported by Localization Guru? How about Chinese and other east Asian languages that use Unicode character sets?
Answer: Localization Guru supports all languages that use a single byte encoding, such as western languages like English, German and French.
Some languages, like Chinese and Korean, require multiple byte encoding which typically means using Unicode. Localization Guru has been used successfully by customers to localize their application into Chinese. Click here for more information about supporting Chinese and other east Asian languages.
Question: When I localize my application for some Foreign languages I also want to be able to change the Font property of my controls so that a different font is used. Can Localization Guru help me out?
Answer: Yes. You can tell Localization Guru that the Font property is one of the properties that is to be exported to the language database and also to be translated at run-time. You do this via the gLG.sProperties property. Thus, you can have your application use a different font for each foreign language that you support (if you so desire).
Question: How does Localization Guru translate my form using only one line of code?
Answer: You typically add the following line of code near the bottom of the Form_Load event of your form:
Call gLG.TranslateForm(Me)
The gLG.TranslateForm method is passed a reference to the Form to be translated. If a language database is currently open then the localization engine fetches the Native text from the Form and any Controls it contains and translates it to the current Foreign language. When the form becomes visible it appears in the Foreign language. If the application is being used in a locale where the Native language is used then you simply do not open a language database and no translation takes place. See the sample code for more details.
Question: Can I add additional foreign languages to my application after it has been built without having to rebuild the application?
Answer: Yes. As far as Localization Guru is concerned you can add additional languages after your application is built without having to make any changes to your application. Simply add additional languages to your language database or create addition language databases containing the new languages. However, you might need to change your application to handle the following cases:
When you arranged the controls (such as TextBox, Label, etc.) on your forms you may not have allowed sufficient width and spacing to accommodate a language that results in longer text than you anticipated. Localization Guru has a property named sStrWidthFactors that allows you to test your application for proper layout in a language that results in longer text than your native language.
If you are storing resources such as icons, pictures, sounds, etc. in a resource file then you may need to add additional items to your resource file to accommodate a new language. In this case, you might have to rebuild your application in order to take advantage of these new resource items.
Question: Many applications have lots of text strings that are displayed in message boxes, error messages, etc. These strings are not stored in the properties of a Form or its constituent Controls but rather as string constants that typically are scattered throughout the application code. How does Localization Guru handle text that is stored as string constants within my application?
Answer: You simply place all of your string constants inside of the LocGuruGets() function which is provided for you in the LocGuru.bas module that you add to your project. Then throughout the application code where you normally would have used code like,
MsgBox "That is not an allowed operation!
In its place you use code like,
MsgBox gLG.GetS(NotAnAllowedOperation_str)
The gLG.GetS method receives an application defined enum NotAnAllowedOperation_str that uniquely identifies the Native string constant "That is not an allowed operation!". The gLG.GetS method returns the translated version of the string constant (or the Native version if no language database is open). See the sample code for more details.
Some competing localization tools handle string constants by doing a scan of your source code and writing the string constants that are found into a language database. With these products you have to take care to ensure that only those string constants that you desire to be translated are actually written to the language database and those that should not be translated are skipped over.
The approach taken by Localization Guru with regard to string constants is more like the method that is used when localizing with only a resource file. You put those string constants that you desire to be translated into a special place in the project (i.e. inside the LocGuruGetS function) and then you fetch them from that special place via gLG.GetS. With the Pro version you get an added bonus while coding with a version of Visual Basic® that support autocomplete. When you have typed "gLG.GetS(" then autocomplete automatically shows you the available enum values that identify your string constants.
Question: Sometimes I combine strings together to form a larger or more complex message that is displayed to the user. I know that in other languages the order in which these strings must be combined together can be different from that of my Native language. Can Localization Guru help me out?
Answer: Yes. The gLG.GetS method allows strings to be substituted within other strings in a language sensitive manner. For example, suppose you wanted to display the following message to the user when a customer cannot be found in the database,
MsgBox "The customer named " & sCustomerName & "was not found"
Using Localization Guru you would do it this way,
MsgBox gLG.GetS(CustomerNotFound_str, sCustomerName)
In this example the enum CustomerNotFound_str identifies the string constant "The customer named %s was not found". When gLG.GetS returns the translated (or untranslated) version of the string it substitutes the sCustomerName string argument into the returned string at the point where the %s is located (this is similar to the operation of the printf function in the C programming language). Here is an example assuming the foreign language is Spanish. The language database could contain "El cliente nombrado que %s no fue encontrado" as the translation of the Native string. Thus, assuming that the customer name is "Fred Flintstone", the resulting Spanish version of the string returned by gLG.GetS would be "El cliente nombrado que Fred Flintstone no fue encontrado". The Linguist who does the translation to the foreign text is the one who determines where to place the %s in the foreign version of the string.
Question: The string substitution abilities of the gLG.GetS method look pretty nice. How many substitution strings can be handled?
Answer: The second parameter in the call to gLG.GetS is a ParamArray so you can pass as many substitution strings as you like.
Question: Are there any other special things I can embed in the strings that are handled by the gLG.GetS method?
Answer: Yes. You can embed {\r} and {\n} in the string to cause a Carriage-Return [Chr(13)] or Line-Feed [Chr(10)] character to result at that place in the text. This allows the linguist to decide where to separate lines of text for each foreign language rather than the programmer making the decision at compile-time. The sample program that comes with Localization Guru has some examples of using {\r} embedded in text.
Question: Can I allow the user of my application to pick the desired language when the application is run?
Answer: Yes. The sample project that comes with Localization Guru includes code that presents the user with a choice list of available languages. This language choice list can be displayed every time the application runs or it can be activated via a command line option. The choices that are displayed to the user come from a simple INI style file that you can easily customize to handle multiple languages and/or language databases. You can easily include this code in your own applications.
Question: Can I predetermine which language will be used by the application?
Answer: Yes. The sample project that comes with Localization Guru includes code to read an INI style file that you can easily customize so that the application always starts using a specified language. You can easily include this code in your own applications.
Question: Can I automatically choose the proper language based upon the current locale?
Answer: Yes. You can use Localization Guru to determine the current locale ID number and then choose the proper language. The sample application that comes with Localization Guru demonstrates how to specify which language in which language database should be used for any given locale ID.
Question: How can I control which strings in my application get translated and which strings do not?
Answer: The strings that Localization Guru translate are stored in two different locations within your application:
Location 1) Your string constants are stored in the application supplied LocGuruGets() function and are fetched from the localization engine via the gLG.GetS method (as discussed here). Each string constant is identified by an enum value of type eLocGuruStringID. When you define your enum values those that are placed before eLastTranslatedString will be translated and those that are placed after eLastTranslatedString will not be translated. See the sample code for more details.
Location 2) Most of the strings that appear in your user interface are usually stored in properties, such as Caption and ToolTipText, of your Forms and the child controls that have been placed on those Forms. Localization Guru uses the following three methods to determine which of these strings are translated and which are not.
|
Method 1: The localization engine (i.e. the gLG object) has a property named sProperties that contains a comma separated list of the properties of Forms and their child Controls that are to be considered for exporting to a language database and for translation. If a string is stored in a property that is not in the gLG.sProperties list then it will not be exported to a language database or translated. The gLG.sProperties list can be changed by your code at run-time so you have quite a lot of control over what gets translated. |
|
Method 2: Form objects and most standard Controls have a Tag property that can be used to store application specific data. If the first character of a control's Tag property is an exclamation "!" character then all of the properties of that control are excluded for export or translation by Localization Guru. If you don't like using "!" as your exclusion string then you can define your own via the gLG.sTagExclude property. |
|
Method 3: The language database has a boolean Skip field that if True will cause the Native string to be skipped for translation. The Language Editor allows you to toggle the state of the Skip field for each Native text string (see example). |
Question: I understand that Localization Guru will only export and translate those properties of Forms and Controls that appear in the gLG.sProperties list and that the only properties supported are Caption, Font, Text, and ToolTipText. How can I export and translate text in Controls with properties that don't appear in this list? For example, the SSTab control stores text for each tab in the TabCaption() property?
Answer: The localization engine (i.e. the gLG object) has two events that the application code can use to override the default behavior of exporting text from a control and translating the text in a control. The ExportControlStrings event is raised by the localization engine prior to exporting the text stored in a control to a language database. The application can choose to handle exporting the text from any specific type of control with code that is placed in this event. Likewise, the TranslateControlStrings event is raised by the localization engine prior to translating the text in a control. The application can choose to handle translating the text contained in any specific type of control with code that is placed in this event. See these two events in the sample code for more details.
Question: Can Localization Guru help me determine whether I am going to have a problem with the width of controls when my application is translated into a language that results in longer text strings than those of my Native language?
Answer: Yes. The localization engine (i.e. the gLG object) has a property named 'sStrWidthFactors' that contains a comma separated list of StringLength:PercentIncrease pairs. The default value for gLG.sStrWidthFactors is "4:100, 10:80, 20:60, 30:40, 50:20, 9999:10" which represents the typical amount of increase in string length that may be encountered when going from English to some other language (these values were taken from the Visual Basic® 6 documentation). For example, strings of length from 1 - 4 typically experience a 100% increase in length, strings of length 5 - 10 typically experience an 80% increase in length, etc. You can change the value of gLG.sStrWidthFactors to reflect your own experience. When you set gLG.bTestStrWidth = True then the localization engine pads your Native strings on the right with the gLG.sPadChar character (which defaults to a nice wide "W") so that you can examine your running application to find those controls that may have a width problem.
Question: Can I export the text of a language from the language database into a text file, translate the file using a software translation program or give it to a linguist for translation, and then import the translated text back into the language database?
Answer: Yes. The Language Editor allows you to export the text from any language column in a language database into a text file. Each text string is identified by a unique ID number. The format of the file allows it to be processed by a software translation program. Or, you can give the text file to a linguist who translates it into the target language. After the translation is completed you then import the translated file back into the language database using the Language Editor. Click here to see an example.
Question: How is Localization Guru licensed?
Answer: Localization Guru Lite is licensed to developers at no cost. Localization Guru Pro is licensed on a per-workstation basis, therefore you must purchase a Pro license for each software developer's computer. In either case (Lite or Pro) you may distribute the Language Editor freely to whomever you wish. This permits you to distribute the Language Editor along with your application (if you so desire) or to send the Language Editor to a linguist who is assisting in translating your application.
Question: What versions of Visual Basic® does Localization Guru support?
Answer: Localization Guru has been tested with Visual Basic® versions 5 and 6. Localization Guru has not been tested with Visual Basic® 4; if you need to use Localization Guru with VB 4 then contact sales@beta-sigma.com. Localization Guru is not supported in Visual Basic® 3 since that version of Visual Basic® does not support classes and ActiveX components (however you might be able to make it work by modifying the source code for LocGuru.cls [in the Pro version] such that the class properties become global variables and the class methods become publicly available functions and subroutines).
Question: Is Localization Guru Year 2000 compliant?
Answer: Yes. There are no dates stored in the language database and no date specific code in the language engine. Thus, since Localization Guru is "date neutral", it is therefore Year 2000 compliant.
Question: Where can I find out more about localizing my application?
Answer: You can look at the Localization Links page which contains some helpful links to other sites.
Question: What if I find a bug (otherwise known as an unexpected feature) in Localization Guru? Will you fix it?
Answer: We will definitely try to fix it! Just send email to support@beta-sigma.com and explain exactly what the bug is and how to duplicate it (sample code would be nice) and if we can duplicate the bug we will do our best to fix it and send you the fix.
Visual Basic is a registered trademark of Microsoft Corporation.
Copyright © 1998-2005 Beta-Sigma Data Systems LLC