Manager
Learn some tips and tricks for bilingual support when configuring Incident Management and Change Request Management applications with Solution Manager 7.1.
Key Concept
Most SAP implementations use one language, but the SAP system supports many languages. Naturally the language of choice for most organizations is its country’s official language or, in large international organizations, English. In some cases, an organization may be required to support two or more languages in the same system – for example, a public-service organization in a country with two official languages (i.e., Canada) or an organization with offices in different countries that shares the same applications and data, but wants to provide end users with a choice of language.
The bilingual support of three important text features in Incident Management and Change Request Management in Solution Manager 7.1 do not follow the standard configuration for bilingual support of text elements and require additional work. The three features are:
- Bilingual multilevel categorization schema
- Bilingual text templates
- System-wide saved searches
Fine-tuning these elements results in a same-look-and-feel application, regardless of the user’s language.
This article provides more details about these features for users who need to deliver the bilingual application. Configuring bilingual SAP applications has its challenges and surprises. SAP has provided automatic translating features, but some manual activities and fine-tuning are still required. Naturally, these activities need to be done by an analyst who is conversant with both languages. At the same time, the help of a professional translator is essential, especially when dealing with the translation of customized fields, labels, actions, and statuses.
The upside of how the SAP system is set up is that the integrity of the master data and transaction data is maintained because the system uses technical names and transaction IDs, not text elements. Therefore, the language being used has no effect when filtering data.
Nevertheless, a single transaction may still have a mix of two languages because the bilingual support applies to all the elements the system offers (e.g., flags, drop-downs selections, and text templates). Keep in mind, however, that this does not apply to free text entered by users (e.g., short and detailed description of an incident) or attached documents.
Most configuration items in the SAP system are translated automatically via transaction SPRO or provide a typical SAP translation path. Usually this is via menu item Go to > Translation. Once the supported second language is defined (in this case, French), using this path you see a dialog in which either the translation is provided by the SAP system or you can use your own for custom-defined items. In the example (Figure 1), use Goto > Translation and go to the action SMIN_STD_MAIL in Incident Action SMIN_STD to show the translation (Figure 2).

Figure 1
A typical translation using transaction code SPRO

Figure 2
Maintain second language text
This example is easy, but not all text elements are translated in this way. I share some tips on how to configure bilingual support for some features in Application Incident Management (AIM) and Change Request Management (ChaRM) with SAP Solution Manager 7.1 that do not use the same access to translation via transaction code SPRO.
The concept of categorization via MLC schema on all transactions was introduced with Solution Manager 7.1. This functionality allowed for the optional use of secondary MLC. For more information on this topic read my case study, “How a Governmental Organization Built a Second Multilevel Categorization Schema.”
In this example I assume you have built your main MLC in English and now need to make it bilingual. Use transaction code SM_CRM (CRM_UI) to access the service operation to create your schema (Figure 3).

Figure 3
Schema is in draft
The status of the schema is in the draft stage before being activated. After you activate it (which is done after the translation is complete), you can use it in your transactions. As often happens, when it is time to test the application with the second language, you may find that instead of categories in French you see only the technical names. This is because you did not provide any description in French and the application used the technical name instead.
To translate your schema, you need to log in with the second language, access the schema while still in Status Draft, and edit each node with the French description.
While in transaction code SM_CRM, simply log off and log in again, but when you log back in, change the Language setting (Figure 4).

Figure 4
Change the language setting
After your application displays in French go to Fonction de base (Service Operations) and find your schema with only the technical name (Figure 5).

Figure 5
Find the same schema
Access your schema by double-clicking it. In the details of the schema you see all the categories created in English that do not have names (Figure 6). Click each category that doesn’t have a name, edit it, and enter a name in the corresponding field (e.g., Nom de la categorie) as shown in Figure 7.

Figure 6
Details of the schema

Figure 7
Edit the names in the second language
The last step is to activate your schema. (For more information on how to activate schemas, refer to my 2012 case study article, “How a Governmental Organization Built a Second Multilevel Categorization Schema.” The categories display in English for users with an English login and in French for users with a French login (Figure 8). As mentioned before, reports use the technical names of the categories. The language used for categorization does not affect reporting.

Figure 8
The result after the schema is activated
Bilingual Text Templates
Text templates in Incident and Change Request Management are optional functionality. They are easy to create and provide better user experience by eliminating the need to type the same text over and over for many transactions. If an organization identifies a text form as part of the Incident and Change Request process, it can be easily created as a text template. Text templates come in two types: User templates and system templates. User templates can be created by an individual user and are visible only to that user. System templates are visible and available for use by all users. My article focuses on system templates as they are subject to delivery of new configuration.
If you configured system text templates, they also need to be bilingual. A simple approach is to have the same text repeated in the second language under the first, a common practice for bilingual documents, but which makes the document very long.
Another natural choice is to have two versions of the template, by language, but this method creates a cluttered drop-down menu, and makes it difficult if your organization has more than two or three templates, as it doubles the support of a second language.
For language support for text templates, the templates need to be created independent of each other. The goal is to create a template that is visible in only one language, which is the user language. In other words, you do not see two language versions of the same template in the same drop-down menu.
To illustrate, I use a simple text template, such as informing the user of a password change. (I assume you know how to create text templates via transaction code SE61.) The template name (the one that shows in your drop-down list) is defined in transaction code DNO_CUST04. When logged in to the SAP system in the same language, you need to create each template separately in transaction code SE61. You also need to provide the title in transaction code DNO_CUST04.
Execute transaction code SE61 in English, choose General text from the Document Class field drop-down options, and click the Create button (Figure 9). This results in the screen in Figure 10. Repeat the same steps in transaction code SE61 in French, making sure you change the language from English to French and use a different template name (Figures 11 and 12).

Figure 9
Create a template in English

Figure 10
English template example

Figure 11
Create a template in French

Figure 12
French template example
Note that with the last two steps you create two separate templates and the content of the templates (but not the titles). This is done with transaction code DNO_CUST04, and again, the process is done separately for each language. Use a field name SDK_MSG_PROC_AUTO_TEXT for each template for as many templates as necessary for each language. Use the technical name used in transaction code SE61 under the Field value in transaction code DNO_CUST04 (Table 1).

Table 1
English descriptions in DNO_CUST04

Table 2
French descriptions in transaction code DNO_CUST04
The result is that when users log in using their language of choice, they see only templates in that language (Figures 13 and 14).

Figure 13
Template options in English

Figure 14
Template options in French
System-Wide Saved Searches
System-wide saved searches are preset filters in the CRM WebClient that can be delivered to all users and are available in their Home section under My Saved Searches. Anyone can create My Saved Searches, but for all users to be able to view or use those searches, they need to be published. Figure 15 shows the search section of Incident Management.

Figure 15
Save a new search (this can be done at any of the CRM WebClient search screens)
After the search is defined, the Solution Manager administrator can modify it to make it public. This activity is system independent and does not use a transport. Use transaction code SE16 and go to table CRMD_SHORTCUT. Find the newly created search and open it to see the details (Figure 16).

Figure 16
Details of the new private search; note the missing description
For this search to become system-wide, maintain the following fields with the entries below (Figure 17):
- Audience Type: ROLE
- Audience Key: ZSOLMANPRO (assuming for your implementation you use a Z-copy of business role SOLMANPRO)

Figure 17
Modified search details
You can maintain the Description field in the same table or in table CRMD_SHORTCUT_T. In the CRMD_SHORTCUT_T table, you need to create a second entry for French, the second language.
Use the GUID 16 value (Figure 17) to find the new search in table CRMD_SHORTCUT_T. Create a new entry for French with the same GIUD 16 ID (Figure 18).

Figure 18
Two descriptions for the same item
Alternatively, you can create the French description in table CRMD_SHORTCUT while logged in to the system in French. If the French description is not maintained, the search still displays and works for the French login, but it does not look good because the French application displays it with the original language description. With the correct maintenance of the two languages, the results look much better (Figures 19 and 20).

Figure 19
Saved Searches in English

Figure 20
Saved Searches in French
Vessy Panayotova
Vessy Panayotova is an experienced certified SAP Solution Manager professional working for the government of Canada, focusing on ITSM, ChaRM, and Solman project administration. She has more than 15 years of SAP experience in configuring, testing, and support of various SAP modules, and has experience in ABAP, Basis, and Portals. For the last five years she has concentrated on SAP Solution Manager 7.0 and 7.1. Vessy holds an engineering degree in electronics from Technical University in Sofia, Bulgaria.
You may contact the author at panayotova.vessy@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.