 |
     |
      |
 |
| Localization Guru |
 FAQ's
A: 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. Go to the FAQ List
A: The Pro version can use either Microsoft Access or a text file for the language database and includes the source code for the localization engine (LocGuru.cls). If your application does not already use the Jet database engine (Jet is used in Visual Basic® to talk to Microsoft Access databases) then you might not want to add the overhead of using Jet to your application. With the Pro version you can use the Language Editor to create a text version of the language database that can be read by the Pro version of the localization engine. Since the localization engine is available as a class module it can be compiled directly into your application thus saving you the frustration of distributing yet one more OCX file with your application. And, of course with the source code you can tweak the localization engine yourself if you so desire. Go to the FAQ List
A: 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. Go to the FAQ List A: Yes. As far as Localization Guru is concerned you can add additional languages after your application EXE 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. Go to the FAQ List 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. A: 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. Go to the FAQ List A: 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 current 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. Go to the FAQ List A: The second parameter in the call to gLG.GetS is a ParamArray so you can pass as many substitution strings as you like. Go to the FAQ List A: 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 string. 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 strings. Go to the FAQ List A: 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. Go to the FAQ List
A: 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. Go to the FAQ List
A: 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. Go to the FAQ List
A: 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 permits 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). Go to the FAQ List
A: In theory, yes. Since Visual Basic 4 and above and Microsoft Access 7.0 and above internally store strings in Unicode I am tempted to say that Localization Guru will support Unicode character sets without a problem. But, I have not personally tested localizing a Visual Basic application in a language whose representation requires a Unicode character set so I cannot say definitely. Go to the FAQ List A: 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). Go to the FAQ List
A: 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 constituent 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.
Go to the FAQ List A: 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. Go to the FAQ List A: 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.
Go to the FAQ List
A: 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.
Go to the FAQ List
A: Localization Guru is licensed on a per-workstation basis. Therefore you must purchase a license for
each software developer's computer. If you have a properly licensed copy of Localization Guru then 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.
Go to the FAQ List
This product is delivered by eletronic download.
Download Localization Guru Pro 5.9MB
After you place your order, the source code for
Localization Guru Pro (i.e. the source code for the
localization engine and the Language Editor) will be sent to you by E-Mail.
The Serial Number unlocks the Trial
version of the product so that you have a fully licensed
version of the product. The Serial Number is the ONLY thing that you will receive when you purchase your
license for the product. Search HALLoGRAM || Request More Information CALL TOLL FREE 1-866-340-3404 |
| ©Copyright 1999
HALLoGRAM Publishing, Aurora CO. All Rights Reserved. All products mentioned in this site are trademarks of their respective owners. |