Developing custom forms for multiple languages (231161)



The information in this article applies to:

  • Microsoft Office Outlook 2003
  • Microsoft Outlook 2002
  • Microsoft Outlook 2000
  • Microsoft Outlook 98
  • Microsoft Outlook 97

This article was previously published under Q231161

SUMMARY

This article provides information about creating a custom Outlook form to use on a different language platform. This article also includes common issues that you may encounter if you try to use a single form or folder-based solution in multiple languages.

MORE INFORMATION

In general, Outlook is designed to work with one language in a custom form. Microsoft recommends that you create separate forms for each localized language that you need to support.

There is no documentation for developers that describes how to create a custom form for use in a global (or multilingual) environment. Because there are so many factors involved in designing a custom form solution in such a scenario, it is difficult to offer general recommendations. Instead, this article provides some general information and also highlights some of the more common issues that customers have encountered.

Creating Separate Forms for Each Language

If your environment is a Microsoft Exchange environment, you can configure the organizational forms library to support separate locales. For additional information about how to configure the organizational forms library to support separate locales, consult your documentation for Exchange. After you configure the organizational forms library for separate languages, you can create localized versions of your form, and then publish each form to the appropriate forms library. Outlook automatically uses the appropriate form based on language.

IMPORTANT: This is the way that Outlook and Exchange were designed to work for localization scenarios; therefore, Microsoft recommends that you use this approach.

Issues to Consider

Consider the following issues if you decide to create separate forms for each language:
  • Multiple forms are generally more difficult to maintain. Depending on the functionality that the form needs to provide, you may encounter obstacles. However, you may find that in the long run, using separate forms is still the best approach.
  • The organizational forms library is the only forms library that supports localized forms. If you cannot publish the form to the organizational forms library, you must either:
    • Install localized forms to individual personal forms libraries so that you can use the same message class for items, even though the users are using different localized forms. -or-

    • In a public folder scenario, you may want to consider publishing multiple localized forms in the folder with unique names (and therefore unique message classes), such as IPM.Contact.Corporate (English), IPM.Contact.Corporate (French), and so on. Because you can only set one form as the default form for a folder, you typically set the predominant language as the default form, and then other users can create new Contacts by opening the appropriate form from the bottom of the Actions menu.

      Or, you may instead want to create an "intermediary" default custom form that users can use to select a language; then the Microsoft Visual Basic Scripting Edition (VBScript) code in the form can programmatically launch the localized form by using the Items.Add method in the Outlook object model. For more information about a related scenario and a description of how to create an intermediary form, click the following article number to view the article in the Microsoft Knowledge Base:

      249199 How to set any form as the default form for a folder in Outlook 2000

Creating a Single Form for Multiple Languages

Although Microsoft does not recommend that you use this method, you may want to consider developing a custom form to be used with multiple languages.

Issues to Consider

Consider the following issues if you decide to create a single form for multiple languages:
  • The Outlook object model does not provide any way to retrieve localized versions of Outlook standard field names; therefore, you must design any VBScript code in the custom form to handle different field names depending on language. The Outlook user-defined field names are not localized and remain constant, regardless of the localized version of Outlook.
  • The Find and Restrict methods in the Outlook object model may require localized standard field names; therefore, you need to special-case the filters for these methods depending on the language.
  • You can create a formula for a Combination or Formula field to set the initial value of a field on a form or to specify a custom filter for a view. However, if the formula includes a reference to a standard field, this formula most likely will not work with another localized version of Outlook because the standard field name is most likely localized in that language.
  • If you want to localize the user interface of the form, you can programmatically change the text that is displayed in controls on the form, but this method creates one-off forms. For more information about one-off forms, click the following article number to view the article in the Microsoft Knowledge Base:

    290657 Description of form definitions and one-off forms in Outlook 2002

REFERENCES

For more information about available resources and answersto commonly asked questions about Microsoft Outlook solutions, click the following article numbers to view the articles in the Microsoft Knowledge Base:

287530 Frequently asked questions about custom forms and Outlook solutions

146636 Frequently asked questions about custom forms and Outlook solutions

182349 Questions about custom forms and Outlook solutions

170783 Questions about customizing or programming Outlook


Modification Type:MinorLast Reviewed:7/31/2006
Keywords:kbinfo KB231161