Localization to adapt a product on foreign Operating Systems

To create localized shortcuts on Win98 / ME / 2000 / XP by using a VB utility add the ShellLink.CLS and ShellLink.BAS and reference ShellLink.TLB to the VB project.

Then use in your code:

Dim MyObj As New cShellLink
lReturn = MyObj.CreateShellLink(LnkFile, ExeFile, WorkDir, ExeArgs, IconFile, IconIdx, ShowCmd As SHOWCMDFLAGS)

Outlined description of utility:

The shortcut strings come from an INI (localized if desired in Russian, French, Spanish, Italian, German, Japanese, Chinese...).

Use the GetSpecialFolder function to obtain the localized name of Start Menu and Programs.

Compile the VB project into an EXE.

Deliver the EXE and the localized INI.

Note:

If you need to find out if the user has administrator rights, you can use the IsNTAdmin API.

For more information see the Tek-Tips Forums - Visual Basic(Microsoft): Version 5 & 6 - my user name is: dgschnei

Adapting a product

It is a fact that companies should try to do a better job when adapting a product to foreign countries (if they want to keep their place in this competitive world). Up to now, companies could get away (more or less) with a poor localization process. Because most high-tech companies thrive on the democratization of computers and software it is becoming harder and harder to get away with poorly translated interfaces, and companies now have to respond to an increasing demand of localized software.

It is common to see a product that does not contain any code compatible with metric units, foreign format, extended characters, date formats, symbols and punctuation, or offers expensive documentation that refers only to specific subjects. It is time to realize that huge savings can be made if all components of a product are initially designed with the goal of international convention. An in-house technical translator/localisator has to be part of the developing team from the beginning to the end of the complete code/product development, and not three weeks before the delivery date.

When developing a product, consider the following:

1) Every language has its own alphabet, symbols and format.

2) Every country has its own keyboard layouts and drivers.

3) Every country has its own version for the operating system. This has to be taken in consideration when executing shell script or related programs. I personally encountered shell scripts that expected users to answer "Y" or "N" from French users using French DOS.

4) Do not hard-code any messages. It takes a great deal of work to find them and translate them later. Unless you are a small shareware author as I am...

5) Icons and images do not always mean the same thing from one culture to another. Do not use idiomatic expressions as: Always On Top.

6) Allow enough space for more text when designing dialog boxes, menus, and messages. In most cases, a French message will need at least 30% more characters.

7) In any case keep terminology consistent, between the interface, on-line help, documentation, and advertising pamphlets. This is one of the most important reasons why many DSCAN users want to have Project Databases.

8) When writing documentation a company should require its technical writers to not use local idiomatic expressions or local examples, to follow a stable and complete in house glossary, to follow a unique format for the text and graphics, and finally to minimize the size of the documents.

9) Good technical writing should explain carefully what is difficult to understand, and not over explain what every body already knows. Technical writers should do their best to write only what is necessary. If a certain sentence or chapter has to be repeated, the writer should make a note of it. This is very important because in many cases companies pay more than once for the translation of complete chapters that are repeated X number of times. It can be a very costly process if these particular chapters are translated in more than one language.

10) If an automatic translation system is used, it is important for the translator in charge to have a detailed description of what to expect before sending the interface and/or documentation translations in the system queue. The in-house (stable) glossary must be updated for all necessary languages.

11) To out-source without the help of in-house translators is a very bad habit . Most of the translation companies do not follow up on the translator's knowledge concerning particular subjects. It is common practice for translation companies to use the same translator for the translation of the installation steps of a doll house, and for the translation of the latest TCP/IP document. Only a well trained in-house translator can verify the quality of the output.

Return Home - Index