1. Global Deployment Guide
  2. What's New in This Release

6Localizing Global Deployments

About the Localization Process

Localizing a Siebel application includes translating the user interface and modifying other attributes to meet locale-specific requirements.

Note: It is recommended that you complete as much configuration as possible before you begin localizing the application. One reason for doing so is that configuration potentially alters what needs to be translated, so it is better to have a stable application. Also, the check-in and check-out mechanism in Siebel Tools or Siebel Web Tools is meant to be performed in only one language; if you perform localization tasks on the client during configuration, then there is a potential for data loss.

For detailed information about working with user interface strings (including symbolic strings) and other locale-specific data, see Using Siebel Tools. You can use the Locale Management Utility (LMU) in Siebel Tools to manage strings and other data. More information about the LMU is provided later in this topic.

For information about localizing strings for Lists of Values (LOVs) and multilingual lists of values (MLOVs), see Localizing Lists of Values and Multilingual Lists of Values.

Note: See also Localizing an Unshipped Language. In general, you perform the tasks in that topic, where applicable, before you perform the other localization tasks described in this chapter.

Localization Process

The localization process typically includes the following steps:

  1. Identify the applications or projects that you want to localize.

  2. Develop a localization glossary.

  3. Export strings and other localizable attributes using the Locale Management Utility.

    This utility exports the objects to a flat file.

    When exporting symbolic strings, export the projects containing the symbolic strings, such as the Symbolic Strings project or a project that you created that contains symbolic strings. For guidelines, see Using Siebel Tools.

    Note: If you are localizing strings for an unshipped language (such as ENG, for British English), then you might export strings from a source language that was shipped for Siebel CRM (such as ENU, for U.S. English), and specify your unshipped language as the target language (such as ENG). In the export file, copy the text from the source language to the target language. (Where many strings are similar or identical between the source and target languages, as with ENG and ENU, copying strings will speed up the translation process.) See also Localizing an Unshipped Language.

  4. Translate strings by modifying the flat file directly or by importing the file into a separate localization development environment, modifying the locale-specific attributes, and then exporting the localization result to another flat file.

  5. Import modified string and modified object definitions into the repository using the Locale Management Utility.

  6. If necessary, then search for strings or locale-specific attributes that have been modified since the last export, and update the string translation or attributes localization for these changed objects.

  7. With the correct language mode specified in Siebel Tools or Siebel Web Tools, publish the updated Siebel runtime repository.

  8. Distribute the Siebel runtime repository to the appropriate Siebel Servers and clients.

Defining the Scope of the Localization

Define what it is that you need to have localized. The content to be localized could include any or all of the following items, or could include other items that are not listed:

  • Software

  • Strings in the user interface

  • Lists of values

  • Seed data

  • Bitmaps

  • iHelp

  • Training materials

  • Documentation

  • Templates and correspondence

Nonlocalizable Elements

The following are nonlocalizable elements:

  • Resource libraries such as DLL files

  • Message files

  • Log files

  • Splash screens

  • The following are selected applets for the Siebel client:

    • Change Records Popup Applet (SWE)

    • Parametric Search Form Applet

Developing a Glossary for Translatable Terminology

It is strongly recommended that you develop a localization glossary. Developing a glossary of your translatable terminology offers the following advantages:

  • It maintains a consistent translation of terms over the lifetime of your localization.

  • It shortens the time that it takes for successive translators to do their work, because the bulk of the terminology has already been translated and they can then spend their time deliberating on how to translate terms that are new in the current release.

    Note: Update the glossary with each release to reflect new translated terms.

  • You can identify terms that you do not want translated, for example, legal names of marketable products or other terms.

The following table provides a sample of a localization glossary.

Siebel ENU Term Siebel DEU Term Customer-Specific Term

Account Affiliation

Firmenniederlassung

Beziehungen - Firma

Affiliations

Zugehörigkeiten

Beziehungen

Best/Visit Times

Best Times:günstigste Zeit

Besuchs- und Öffnungszeiten

Brick Subtype

Sektor Subtyp

Brick-Subtyp

Contact Affiliation

Kontaktaufnahme mit Zweigniederlassungen

Beziehungen - Person

Precall

Voranmeldung

Besuchsvorbereitung

Begin your localization effort by having your marketing department work with the translators to create this glossary. The marketing department can help the translators determine which terms should not be translated, while the translators can offer the marketing department suggestions on terminology in the target language from a localization standpoint.

About Working with Translators

This topic discusses issues in choosing and training translators, and managing localization schedules in coordination with your translators.

Choosing Translators

Consider the following questions when choosing translators to work with:

Will you use in-house translators or translation vendors?

Although in-house translators might seem cheaper in the short-term, bilingual workers often have other responsibilities and perform translations in addition to their main functions. Consequently, the results that you get might not be as good or as sustained as those you would get from hiring an outside translation vendor.

Another factor to consider is that, just because an employee is from the country that you are localizing for, it does not necessarily mean that they have the knowledge to translate your terminology correctly into the current professional vocabulary for your industry in the target locale.

If you do choose in-house translators, then make sure that they read the trade publications in your field published in their native country, at minimum.

There are many translation vendors to choose from, many of whom specialize in software internationalization, localization, or globalization, depending on your needs. For a selection of specialists, see the Web site of the Localization Industry Standards Association:

http://www.lisa.org

How do you choose the right vendor?

While cost is one factor to consider, to judge whether the cost quoted is good value or not depends on the services that you think you need and on what other vendors offer for a similar cost. Find out from each vendor what their charges entail and compare each vendor’s offering based on the value of the service to you as well as on its cost.

For example, some vendors bundle the cost of project management into a quote, while others break out this cost. Some will charge extra for defect fixes, while others will not.

Do you require that your translators work on site or can they work remotely?

Most translation vendors use skilled specialists expert in translation for particular industries, who might be located in other U.S. states or even other countries, as opposed to in-house translators. Be prepared, whenever possible, to ship your translators flat files containing the localizable text strings and to clearly identify which strings should be translated.

Sometimes it might be most effective to work closely with qualified translators at your site. Doing so might be appropriate when the product is being localized very rapidly. Having translators on site allows defect-fixing to occur quickly. It might also be appropriate when the product requires engineers to input localized text, as when there is no separate localization utility. Having translators on site to work together with the engineers will be highly advantageous, but is generally more expensive.

Training Translators

Even the most experienced translators need training from you to learn about the products they are going to be localizing. Such training can include:

  • Preparing a translator information kit that includes marketing brochures, marketing requirements documents, design documents, statements of direction, white papers, or other information that explains the nature of your company’s business. Provide the translators with a context for their translation work.

  • How to use the application for which they are translating text strings or documentation, and the purposes the application serves.

  • How to report product defects during localization testing: for example, truncated, localized labels in the user interface.

  • How to safely enter translation strings in files that your engineers send to the translators, such as by using email or FTP, and that the translators send back in a similar manner.

Localization Schedules

Agree to a Statement of Work or timeline (schedule) for the translation project early on. Understand what is involved on the translator’s part, such as time needed for translation review either by vendor reviewers or by subject matter and language experts within your field offices. Developing a timeline helps all of the parties ensure that the timeline is realistic.

Consider whether your reviewers in the field consider their review of the translation a high priority when scheduling the timeline for their participation. Make sure that you have their manager’s commitment for participating in the review.

If your software development project incurs delays, then do not expect the translators to shorten the time that you have agreed to for their efforts unless you are willing to accept lower quality. Good translations take time and no machine can take the place of a human being in this regard.

Localizing Lists of Values and Multilingual Lists of Values

Lists of values (LOVs), which are used in static picklists in the Siebel application user interface, are also localized for many multilingual deployments. LOVs can also be converted into multilingual lists of values (MLOVs).

MLOVs and multilingual picklists allow values to be selected by a user in one language and retrieved by users working in other languages. The value that is stored in the database for the record is the Language Independent Code (LIC) from the LOV record, rather than the Display Value, as is true for monolingual picklists.

For MLOVs to work correctly, Language Independent Code (LIC) and Display Value must always be consistent within the same LOV type and language, as follows. For records with the same LOV type and language, but different Parent LIC or organization:

  • Multiple records with the same LIC value must have the same display value.

  • Multiple records with the same display value must have the same LIC value.

Note: Where the LOV type is not organization-specific and not hierarchical, user keys normally prevent the creation of different LIC and display value combinations for the same LOV type and language on the server database. It is recommended to create LOVs on the server database whenever possible, because NULL value handling on the local database allows creating LOV records that do not meet the described requirements. (NULL handling is similar on Microsoft SQL Server.) Offending records violating user keys will not successfully replicate to the server database on synchronization.

As noted in About Parameters for Language and Locale, the Language Code parameter controls the language for MLOV display. If a Preferred Language is specified for a user, then this setting overrides the parameter value to determine the MLOV language.

In some localization efforts, you might choose to display LOVs or MLOVs in a common language rather than to use the same language as the application user interface. For example, for users working with a user interface in Czech (a language shipped for Siebel CRM) or Norwegian (an unshipped language), it might be appropriate for LOV or MLOV values to display in English, German, or some other language, depending on the business needs of your deployment.

Note: If you want LOV or MLOV values to display in an unshipped language, then you can copy values from one of the languages shipped for Siebel CRM and translate them into your unshipped language. In general, it is recommended to copy values from a language other than ENU, because many LOV values are provided for ENU that are not translated into any other language. For more information about localizing an unshipped language, see Localizing an Unshipped Language.

LOVs, including MLOVs, can also be organization-enabled, and some LOVs can also be hierarchical. For more information about configuring these types of LOVs, see 473813.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 632.

You must engage Oracle’s Application Expert Services both for the initial configuration and for the upgrade of these items at the next Siebel version upgrade. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.

Note: In general, LOVs for newly deployed languages are inactive by default. You must enable the LOVs that you require by using Siebel EIM or the List of Values view in the Administration - Data screen. Alternatively, you can engage Oracle’s Application Expert Services for this purpose.

For detailed information about creating and administering LOVs and MLOVs, and about converting LOVs to MLOVs, see Configuring Siebel Business Applications and Siebel Applications Administration Guide. Review all of the applicable guidelines and requirements.

Localizing an Unshipped Language

This topic describes how to localize an unshipped language.

In general, you perform the localization tasks described here before you perform other localization tasks described in this chapter. After performing the tasks described here, review your remaining localization needs for all of the files or data associated with an unshipped language.

An example of an unshipped language, Norwegian (NOR), is used throughout this topic.

Note: The tasks described here apply to the current release, Siebel 2018. In general, tasks are performed after, or in conjunction with, the installation or migration tasks described in Siebel Installation Guide for the operating system you are using, and other tasks for preparing to use Siebel CRM applications. Although some localized elements for an unshipped language migrate as part of a migration installation from a previous release, the customer must verify the migration of all localized elements for unshipped languages, and might need to migrate certain elements manually. Note that some of the directories and files mentioned in this chapter have been reorganized relative to prior releases.
Caution: The process of localizing an unshipped language is considered to be customer configuration. Such configuration changes are not upgraded as part of the upgrade process described in Siebel Database Upgrade Guide.

See also About the Localization Process and Localizing Lists of Values and Multilingual Lists of Values.

Creating Language and Locale Records

This topic is part of Localizing an Unshipped Language.

Localizing an unshipped language requires that appropriate Siebel language and locale records exist in the Siebel database. If these records do not already exist, then you must create them in the Siebel application. You do this in the Administration - Data screen, in the Languages and Locale views.

Each language code used by Siebel applications uses a three-letter code, such as ENU for U.S. English, FRA for French, THA for Thai, and so on. Using language codes with only two characters does not work and is not supported. For more information about the language codes used by Siebel CRM, see Language.

These codes follow conventions used by Microsoft, where the first two letters represent a two-letter language code from ISO Standard 639, and the third letter can be used to differentiate the countries where this language is used. Multiple entries can represent different countries that use variants of the same language (for example, PTG for Portuguese - Portugal, and PTB for Portuguese - Brazil).

When you create language records for an unshipped language, use the language code names published by Microsoft. For example, the language code defined for Norwegian, a language that is not shipped for Siebel CRM, is NOR.

When creating language records, observe the following guidelines:

  • Language codes must use three letters and must be defined using all capital letters (such as NOR rather than nor, for Norwegian).

  • Your language code must use the same first two letters as the Microsoft code for the language, in order to ensure that the correct internal libraries will be used. For example, if you want to create a language code for Austrian German, then name it DEA, so it will use the same code page as German (DEU). Similarly, use ENG for British English. For more information about the Microsoft codes, see Microsoft documentation.

  • Where possible, use one of the existing language records that are listed in the Languages view in the Data - Administration screen. The Siebel language records are stored in the S_LANG table.

Two parameters, Language Code and (optionally) OM - Resource Language Code, are used to specify how an application uses languages. For more information, see About Parameters for Language and Locale.

To create a Siebel language record for an unshipped language

  1. In the Siebel application, navigate to the Administration - Data screen, then the Languages view.

  2. Verify that a record exists for the unshipped languages you are localizing. If necessary, then create a new record for the unshipped language.

    For example, for Norwegian, specify Norwegian as the Name value and specify NOR as the Code value.

  3. Start Siebel Tools or Siebel Web Tools with a connection to the server database, and verify that the language record displays correctly. Also verify in the List of Values Administration screen that you can enter LOV records for the new language.

Note: If necessary, then, after you create the language record, also create a record for any new locale that you require. More information about locales is provided, as follows.

About Creating a Locale

If an existing Siebel locale does not cover the users of the unshipped language that you are implementing, then you must also create a locale record for the location for these users.

Locales correspond to user-specific or computer-specific settings such as Regional and Language Options in the Control Panel on Microsoft Windows.

For example, if you create a Norwegian (NOR) language record, then Norwegian-speaking users might use an existing locale, such as for Sweden, or might require using a locale for Norway in order to specify settings such as dialing code, date formatting, and so on. In some cases, time zones will differ between locales.

When creating a locale, copying an existing locale for which some of the same settings apply will make data entry easier. After you create a new locale, create translation records to provide the name for the locale for all of the languages that you are using.

Siebel locale records are stored in the S_LOCALE table.

See also Additional Information About Setting Up and Administering Locales.

For detailed information about creating locales, see Siebel Applications Administration Guide.

Creating List of Values Records for an Unshipped Language

This topic is part of Localizing an Unshipped Language.

You must create List of Values records for an unshipped language that you are implementing. You do this by copying certain existing List of Values records for the primary language and then modifying the copies.

To create List of Values records for an unshipped language

  1. In the Siebel application, navigate to the Administration - Data screen, then the List Of Values view.

  2. Query for records where Type equals ACCESS_RESOURCE_TYPE. This query should return at least four records.

  3. Make a copy of each record returned by the query.

  4. For each record copy, set values for the Language Independent Code (LIC) and Display Value fields the same as the corresponding record for the primary language (such as ENU). Set the language to the unshipped language, such as NOR, for Norwegian.

  5. Set all of the other properties the same as the corresponding record for the primary language (for example: Active Flg, MultiLingual Flag, Order).

Creating New Language Subdirectories and Copying Language-Specific Files

This topic is part of Localizing an Unshipped Language.

When you are localizing an unshipped language, you create new language subdirectories to use for the unshipped language. You also copy language-specific files so you can use the copied files with the unshipped language.

If you localize the user interface and optionally MLOV values or other seed data into Norwegian (NOR), then you would set the Language Code parameter to NOR. However, resource library files located in language-specific subdirectories are not provided in Norwegian for Siebel CRM and cannot be localized into Norwegian. For this reason, you would set the OM - Resource Language Code parameter to DEU or ENU in order to use resource libraries from subdirectories for DEU or ENU. For more information, see About Parameters for Language and Locale.

You create language subdirectories on the Siebel Server, on the Siebel Application Interface, and on the Siebel Mobile Web Client, as described in the following tasks. The directory names that you use must correspond to the language code that you specified in Creating Language and Locale Records.

The following table explains the language placeholders that are referred to in the procedures in this task and in the remaining tasks listed in Process of Localizing an Unshipped Language.

Placeholder Definition

XXX

The unshipped language that you are localizing, for example, NOR (Norwegian).

YYY

The base language of the application: for example, DEU (German) or ENU (U.S. English). In some cases, you copy files from language directories for the shipped language YYY into new directories for the unshipped language XXX. Sometimes you update the names of copied files to include XXX instead of YYY.

Note: Alternatively, you can copy files from some other shipped language to the unshipped language that you are localizing, instead of copying them from the base language. For example, perhaps ENU (U.S. English) is the base language, but you choose to copy DEU files instead of ENU files.

Related Book

Siebel Installation Guide for the operating system you are using

Creating Language Subdirectories and Copying Language-Specific Files for an Unshipped Language on the Siebel Server

Use the following procedure to create language subdirectories and copy language-specific files for an unshipped language on the Siebel Server.

To create language subdirectories and copy language-specific files for an unshipped language on the Siebel Server

  1. On the Siebel Server computer or operating system instance, create a new language subdirectory XXX under SIEBSRVR_ROOT\bin. Copy the configuration files from SIEBSRVR_ROOT\bin\YYY into SIEBSRVR_ROOT\bin\XXX. The configuration files (that is, the CFG files such as uagent.cfg for Siebel Call Center) will be used by the Application Object Managers that you will create for new language XXX.

    Also copy all of the binary files (that is, the library files in the bin\YYY directory) to the target directory, along with the configuration files.

    Note: After completing the localization tasks, you must recopy the files from bin\YYY to bin\XXX after each time that you install a new Siebel CRM release for the Siebel Server, to keep your localized product up to date. For more information about installing Siebel CRM releases, see the Siebel Installation Guide for the operating system you are using.

  2. Create a new language subdirectory XXXSIA (such as NORSIA, for the example unshipped language, Norwegian) under SIEBSRVR_ROOT\bin. Copy the contents of YYYSIA (such as DEUSIA or ENUSIA) into directory XXX.

    Note: After completing the localization tasks, you must recopy the files from YYYSIA to XXXSIA after each time that you install a new Siebel CRM release for the Siebel Server, to keep your localized product up to date.

  3. Create a new language subdirectory XXX under SIEBSRVR_ROOT\msgtmpl. Copy the contents of SIEBSRVR_ROOT\msgtmpl\YYY into directory XXX.

Related Books

Siebel Installation Guide for the operating system you are using

Configuring Siebel Business Applications

Creating Language Subdirectories and Copying Language-Specific Files for an Unshipped Language on the Siebel Application Interface

Use the following procedure to create language subdirectories and copy language-specific files for an unshipped language on the Siebel Application Interface.

To create language subdirectories and copy language-specific files for an unshipped language on the Siebel Application Interface

  1. On the Siebel Application Interface computer or operating system instance, create a new language subdirectory XXX under SIEBEL_AI_ROOT\applicationcontainer\webapps\siebel, where XXX is the unshipped language that you are localizing, such as NOR for Norwegian. Then copy the directory SIEBEL_AI_ROOT\applicationcontainer\webapps\siebel\YYY\help into directory SIEBEL_AI_ROOT\applicationcontainer\webapps\siebel\XXX. Update these files for language XXX, as appropriate for your deployment.

  2. In SIEBEL_AI_ROOT\applicationcontainer\webapps\siebel\scripts, copy the file swemessages_yyy.js (in the same directory) and rename the copy swemessages_xxx.js, such as swemessages_nor.js for Norwegian.

    Note: After completing the localization tasks, you must recopy the file swemessages_ yyy.js after each time that you install a new Siebel CRM release for the Siebel Application Interface, and then rename the file again, as described, to keep your localized product up to date. For more information about installing Siebel CRM releases, see the Siebel Installation Guide for the operating system you are using.

  3. Similar to what you did in the second step of this procedure, identify any other language-specific files, then copy the files and rename the copies to refer to new language XXX instead of existing language YYY.

Related Books

Siebel Installation Guide for the operating system you are using

Siebel Security Guide

Creating Language Subdirectories and Copying Language-Specific Files for an Unshipped Language on the Siebel Mobile Web Client

Use the following procedure to create language subdirectories and copy language-specific files for an unshipped language on the Siebel Mobile Web Client.

To create language subdirectories and copy language-specific files for an unshipped language on a Siebel Mobile Web Client

  1. Create a new language subdirectory XXX under SIEBEL_CLIENT_ROOT\bin. Copy the configuration files from SIEBEL_CLIENT_ROOT\bin\YYY into directory XXX. The configuration files (CFG files such as uagent.cfg for Siebel Call Center) will be used by the application for language XXX.

    Also copy all of the binary files (that is, the library files in the bin\YYY directory) to the target directory, along with the configuration files.

    Note: After completing the localization tasks, you must recopy the files from the bin\YYY directory after each time that you install a new Siebel CRM release for the Siebel client, to keep your localized product up to date. For more information about installing Siebel CRM releases, see the Siebel Installation Guide for the operating system you are using.

  2. Create a new language subdirectory XXXSIA (such as NORSIA) under SIEBEL_CLIENT_ROOT\bin. Copy the contents of YYYSIA (such as DEUSIA or ENUSIA) into directory XXX.

    Note: After completing the localization tasks, you must recopy the files from YYYSIA to XXXSIA after each time that you install a new Siebel CRM release for the Siebel client, to keep your localized product up to date.

  3. Create a new language subdirectory XXX under SIEBEL_CLIENT_ROOT\msgtmpl. Copy the contents of SIEBEL_CLIENT_ROOT\msgtmpl\YYY into directory XXX.

  4. Create a new language subdirectory XXX under SIEBEL_CLIENT_ROOT\public, where XXX is the unshipped language that you are localizing, such as NOR for Norwegian. Then copy the contents of SIEBEL_CLIENT_ROOT\public\YYY\help into directory SIEBEL_CLIENT_ROOT\public\XXX\help. Update these files for language XXX, as appropriate for your deployment.

  5. In SIEBEL_CLIENT_ROOT\public\scripts, copy the file swemessages_yyy.js (in the same directory) and rename the copy swemessages_xxx.js, such as swemessages_nor.js for Norwegian.

    Note: After completing the localization tasks, you must recopy the file swemessages_ yyy.js and then rename the file again, as described, after each time that you install a new Siebel CRM release for the Siebel client, to keep your localized product up to date.

  6. Similar to what you did in the previous step, identify any other language-specific files, then copy the files and rename the copies to refer to new language XXX instead of existing language YYY.

Related Book

Siebel Installation Guide for the operating system you are using

Creating Application Object Manager Components

This topic is part of Localizing an Unshipped Language.

Next, you must create and configure Application Object Manager components that you are going to use for the unshipped language.

This task applies to Siebel Web Client users. It does not apply to Siebel Mobile Web Client or Developer Web Client users.

Tip: Follow this procedure for a single component for testing purposes, before you create all of the other components that you require.

For detailed information about creating and configuring server components, see Siebel System Administration Guide.

To configure an Application Object Manager for an unshipped language

  1. Start an employee application such as Siebel Call Center in the base language, such as DEU or ENU. Navigate to the Administration - Server Configuration screen, then the Enterprise Explorer view.

  2. In the explorer tree, expand the enterprise, then click Component Definitions.

  3. In the Component Definitions list, select an Application Object Manager component on which you will base your new component. For example, select Call Center Object Manager (ENU) then choose Copy Record from the menu.

  4. Provide values like the following for the server component that you created:

    • Component. Call Center Object Manager (NOR)

    • Alias. SCCObjMgr_nor

    • Component Type. Application Object Manager (the value is copied automatically from the source record that you selected in the previous step)

    • Component Group. Siebel Call Center

    • Description. Call Center Object Manager (NOR) for Norway (the value is copied automatically from the source record that you selected in the previous step)

  5. Provide parameter values for this Application Object Manager component. In particular, specify the Language Code and OM - Resource Language Code parameters. Depending on the requirements for your deployment, you might set the language parameters in different ways.

    1. With the new component selected in the Component Definitions list, expand Component Definitions in the explorer tree, expand the selected Application Object Manager element, then click Parameters.

    2. In the Component Parameters list, query for the Language Code parameter. Set the Value field to the three-letter code for the language XXX that you are localizing, such as NOR for Norwegian.

    3. Query for the OM - Resource Language Code parameter. Set the Value field to the three-letter code for the shipped language YYY (such as DEU or ENU).

    4. With the new component selected in the Component Definitions list, expand Component Definitions in the explorer tree, expand the selected Application Object Manager element, then click Parameters.

    For more information about the language parameters, see About Parameters for Language and Locale.

  6. For Application Object Manager components used for Siebel Mobile disconnected application synchronization, also verify relevant documented settings, such as those in the Application Administration view in the Administration - Siebel Mobile screen.

Related Books

Siebel System Administration Guide

Siebel Mobile Guide: Disconnected

Creating Application Configurations on the Siebel Application Interface

This topic is part of Localizing an Unshipped Language.

For each new Application Object Manager component that you create for an unshipped language that you are localizing, as described in Creating Application Object Manager Components, you must create and configure an application configuration for the Siebel Application Interface, using Siebel Management Console.

You can copy existing application configuration settings and adapt them for the new language (for example, changing enu to nor), including selecting different options.

For more information about creating application configurations as part of configuring the Siebel Application Interface, see the Siebel Installation Guide for the operating system you are using.

Related Book

Siebel Installation Guide for the operating system you are using

Configuring Siebel Mobile Web Clients

This topic is part of Localizing an Unshipped Language.

For a Siebel Mobile Web Client or Developer Web Client, in addition to the applicable steps described in Creating New Language Subdirectories and Copying Language-Specific Files, you must perform the steps described here for your unshipped language.

Note: The Siebel Developer Web Client is not supported for user deployments. For more information, see the Siebel Installation Guide for the operating system you are using.

Related Books

Siebel Installation Guide for the operating system you are using

Siebel System Administration Guide

Modifying Application Configuration Files

For any applications that you will support for Siebel Mobile Web Client or Developer Web Client users, you modify the configuration files located in the new language subdirectory XXX under SIEBEL_CLIENT_ROOT\bin, which you created by following the steps in Creating New Language Subdirectories and Copying Language-Specific Files.

For example, for Siebel Call Center for Norwegian (NOR), edit SIEBEL_CLIENT_ROOT\bin\NOR\uagent.cfg to include parameter values similar to the following:

[Siebel]
Language = NOR
ResourceLanguage = DEU
...
[InfraUIFramework]
MsgTemplateDir = C:\Siebel\Client\msgtempl\NOR

This example, where you set the Language parameter to NOR and set the ResourceLanguage parameter to DEU, ENU, or another value, supports one localization scenario. For more information, see About Parameters for Language and Locale and Creating Application Object Manager Components.

The Language parameter is equivalent to the server parameter Language Code. The ResourceLanguage parameter is equivalent to the server parameter OM - Resource Language Code.

In the configuration file, replace other language references, such as enu or ENU (for U.S. English), with nor or NOR (for Norwegian), where appropriate, to support your unshipped language.

Modifying Application Shortcuts for Siebel Mobile Web Clients

For a Siebel Mobile Web Client or Developer Web Client, create application shortcuts for your unshipped language XXX by copying existing shortcuts for the base language YYY.

For example, you might copy the shortcut for Siebel Call Center - ENU and rename it Siebel Call Center - NOR. Modify the properties of this shortcut so the shortcut target is similar to the following:

"C:\Siebel\Client\BIN\siebel.exe" /c "C:\Siebel\Client\bin\NOR\uagent.cfg"

Testing an Unshipped Language

This topic is part of Localizing an Unshipped Language.

You must test the Siebel application that uses the unshipped language. To some extent, interim testing can verify the tasks previously performed, prior to completing all of your localization tasks, as described in Completing Localization for an Unshipped Language. Retest again at appropriate points to verify all of the remaining localization steps.

To test the Siebel applications for the unshipped language

  1. Restart the Siebel Server to have the new settings take effect.

  2. Start the Application Object Manager for your unshipped language XXX (such as NOR for Norwegian) and test the application.

    If you copied elements from the base language YYY to use for the unshipped language XXX, then the application user interface still appears in language YYY, because you haven’t yet performed the localization steps in Completing Localization for an Unshipped Language. The application splash screen, which is not localizable, always appears in the base language YYY. (For more information about nonlocalizable elements, see Defining the Scope of the Localization.)

    Note: If you are using multilingual list of values (MLOV) columns, then make sure they are available in the appropriate values for language XXX.

  3. Navigate to the Administration - Data screen, then the List of Values view. Select an LOV that is based on a column that can be MLOV-enabled.

Related Books

Configuring Siebel Business Applications

Using Siebel Tools

Configuring Siebel Open UI

Siebel Installation Guide for the operating system you are using

Completing Localization for an Unshipped Language

This topic is part of Localizing an Unshipped Language.

To complete the localization process for the unshipped language XXX, you must translate all of the appropriate content that is associated with this language. When you have translated repository elements, you must distribute the Siebel runtime repository for this language to Siebel Servers and Siebel Mobile Web Clients.

Language-specific content that you can translate or create includes the following items. See also the list of nonlocalizable elements in Defining the Scope of the Localization.

  • (In Siebel Tools or Siebel Web Tools) Localizable Siebel Repository strings in the Siebel database. Add translations for symbolic string references, object locales, message categories, and so on.

  • (In the Siebel application) Translatable language-specific values (Display Value field) for lists of values (LOVs) and multilingual lists of values (MLOVs).

    Add all of the values that you need for your new XXX language. For example, LOVs used by workflow processes must be localized into the new language.

    Note: If an existing LOV record for your base language or another language does not have the Translate flag checked, then do not copy and translate this record. Copy only those records that are flagged as translatable.

    For detailed information about configuring LOVs and MLOVs, including the use of flags such as Translate and Multilingual, see Configuring Siebel Business Applications.

  • (In Siebel application) Other seed data such as time zone translations, iHelp files, SmartScripts, correspondence templates, email templates, Siebel Anywhere administration data, and so on.

  • Text that appears in image files or Web templates.

Test all of the changes before you complete the project and roll out the localized application.

For more information about tasks such as these that you perform in a Siebel Tools or Siebel Web Tools development environment, see books such as Configuring Siebel Business Applications and Using Siebel Tools.

Related Books

Configuring Siebel Business Applications

Using Siebel Tools

Configuring Siebel Open UI

Siebel Installation Guide for the operating system you are using

About Testing Globalized Software

This topic can help you to test the efforts of your software internationalization and localization teams.

System Configuration

To test the configuration, you first need to establish what your key platforms are for your database servers, your Siebel Servers, your clients, and your operating systems, for each language that you intend to deploy within your network.

You must test each supported platform, keeping in mind that there might be subtle differences or additional third-party software required in some cases.

Testing for Internationalization

Test your globally deployed applications to verify that all of the internationalization-related features function correctly.

For example, to test for character integrity during saving and retrieving data, you might create test cases that use a wide range of characters from your target languages. For a particular target language or set of languages, enter such data into fields and save the record. Check that you can search for the records and find them. Select the records and view them, checking that all of the data values that you input are unchanged. After entering, saving, and retrieving the data records in the target language, no square boxes or question marks should appear in the data.

Some of the issues to consider when creating test cases include:

  • Test for character integrity during saving and retrieving data

  • Test for user interface character integrity

  • Verify interaction with native language operating systems and application response to locale settings

  • Verify functionality with date format (including date-time fields) and time format

  • Verify functionality with time zone support

  • Verify functionality with number format

  • Verify functionality with buffer sizes, check for overflow

  • Test file names with international characters

  • Verify accelerator keys

  • Verify support for the euro currency and its symbol (€)

  • Verify decimal symbol calculations and arithmetic operations

  • Verify calendar functionality

  • Verify list separator

  • Verify reporting and printing operations

  • Verify sorting

  • Verify query or find operations

  • Verify phone number formats

  • Verify layout for name fields, for example support for middle initial

  • Verify layout for address fields, for example support for state or province

  • Verify that postal code is not a required field for a country with no postal codes

  • Verify measurement units, metric or imperial

  • Verify interaction with third-party software

  • Verify import or export operations

  • Verify taxation system support

  • Verify that translations are not truncated or otherwise corrupt

  • Verify that only translatable items are translated

Testing for Linguistic Quality

Use people in your field offices whenever possible to help you check the localization for linguistic accuracy and consistency. Test any custom terms with the field users, and pick terms that will be used often. For example, if you use a term like currency rollup, then make sure that it is correctly translated for your field users.

Using Automated Test Software

Third-party software is available to automate some test functions, although it does not replace the need for human testing.

Automated test software is very useful to test a wide range of characters, because an automated test can check all of the possible characters in Unicode, for instance. If an automated test is combined with a random test-data generator, then it is also likely to vary the data values much more widely than a human tester will.

On the other hand, an automated test cannot easily detect characters that have been clipped or otherwise hidden on the user interface, or other anomalies that the human eye can detect quickly.

Of course, it is important to use automated test software that supports Unicode data values and error messages containing failing data values. If several languages are being tested, then it will be most convenient if the test software can switch between each language automatically.

Defect Reporting

Build an efficient process for defect fixing between reviewers, translators, and the development team.

Make sure that your defect tracking system also supports Unicode data. It is very hard to explain a problem with data values in another language if the defect system does not allow you to put the failing characters into the title or the record of the defect report.

An example of such an application is Siebel Approval Manager. For more information, see Siebel Approval Manager Guide.