Using Siebel Tools > Working With Strings and Other Locale-Specific Data >

About the Symbolic String Conversion Process

The String Conversion process does the following:

• Generates new symbolic string records and their corresponding symbolic string locale records using string values found in target objects.

  NOTE:  The conversion process runs on an object type by object type basis. Because of this, there are likely to be duplicate symbolic strings for a given display value. Duplicates are "de-duped" during the consolidation process.

• Sets the String Reference fields of the target object records to the names of the new symbolic strings.
• Nullifies the string fields in the locale records of the target objects and, where appropriate, deletes the locale records.

The conversion process occurs in two phases: the conversion export phase, in which data is prepared for conversion, followed by the conversion import phase, in which data changes actually occur.

NOTE:  An SRF file compiled before the conversion process will be the same as an SRF file compiled after the conversion process. For example, suppose a given applet gets its Title property from a child Applet Locale record. When the conversion process is run, it creates a symbolic string, places the reference for that symbolic string in the applet's Title - String Reference field, and then removes the Applet's locale record(s). Now, after the conversion, the applet's title is derived from the symbolic string. However, the Title itself, the display value that is complied to the SRF, is the same as it was before the conversion. The reason is that the strings are complied into object definitions and read from the SRF file, not referenced from the Symbolic String table during runtime.

Conversion Export

The Conversion Export process identifies records that are candidates for Conversion, and then writes all the relevant information to a file. This process is run on an object type by object type basis, and can be run against any object type that has translatable strings (for example, controls, list columns, and applets).

NOTE:  The Conversion process has to be executed once for each Object Type (both Top-Level and Sub-Level Object Types) in the repository that has properties that reference Symbolic Strings. In order to determine what Object Types refer to Symbolic Strings, click the Flat Tab in the Object Explorer, navigate to Attribute, and search for the string "*String Reference*" in the Name property. The Parent Type of the results set is the complete set of object types for which the conversion has to be run. Some object types have more than one attribute that refers to Symbolic Strings; for such object types, it is necessary to run the conversion process only once.

The conversion process begins by creating a sorted list of English (ENU) child records for each translatable string within a given object type. For those object types with multiple translatable strings (such as list columns that have a Display Name and Prompt Text), each is processed sequentially. This list is used to generate information about the new symbolic strings. Among sets of records with identical ENU translations, the non-ENU records are compared and, where possible, the same symbolic string is reused for subsequent records. The output file produced contains information about the new symbolic strings, including all the language translations for each, as well as which strings will be used as replacements.

NOTE:  The Conversion Export file is not a log file so there is no need to review its contents.

Conversion Import

Based on the file produced by the conversion export process, the conversion import process performs the changes to the database (inserts, updates, and deletes) that convert the object records to use the new symbolic strings. Logically, the process consists of three operations, the end result of which is the production of symbolic string and symbolic string locale records, and the deletion of other types of locale records. The three operations are:

• New symbolic string records are created in the database. The export file contains all the information about the string, including a unique name and information about each of its locale children.
• References to the new symbolic string records are placed into the relevant fields of the original objects. For example, suppose you have 10 applets whose title is My Service Requests. Assuming the non-ENU values for all the titles are the same, then the export file contains information about one new symbolic string, and instructions for each of the 10 applets to use this new symbolic string as its title. After creating the symbolic string record for a string whose ENU value is My Service Requests, the Title - String Reference property for each of the 10 applets is set to the name of the new symbolic string. At this point, each of the Applets has a String Reference in addition to the String Override. The String Override is now superfluous and can be removed. This is done by clearing that value from the object Locale children.
• Records are deleted for which there is no longer any information in the object locale records.