Displaying a foreign character set in Service Desk r11.
Article ID: 54286
Updated On:
Products
Issue/Introduction
Description
Foreign characters, for example Japanese, may appear garbled when entered in the Description, Summary or Resolution fields of a English Service Desk installation.
These can be displayed correctly by applying a character set.
Solution
Configuring a character set allows this functionality with Service Desk, with limitations.
Configure the character set in the Service Desk Options Manager option: charset.
By default this option is windows-1252.
In order to allow foreign characters, such as Japanese, the correct character set must be used.
Character sets for different languages are available through a search of the internet.
For example, to use Japanese characters, use the following values in Service Desk NX.ENV and NX.ENV.tpl files:
@[email protected][email protected]_MAIL_SMTP_BODY_CHARSET=iso-8859-1
The change to the NX.ENV.tpl file is required so that running pdm_configure does not reverse the change.
WARNINGS AND COMMENTS
Take a full file system backup and data backup of your Service Desk installation before making the above changes.
It is strongly recommended that these changes be trialed on a test system.
Note: To display the whole Service Desk installation in a foreign language, such as Japanese, you must install the localized version of Service Desk. The above workaround only allows the display of foreign characters within the fields. It does not change field labels, help screens, documentation or other product areas.
Please also see Service Desk r12 for its language capabilities, which extend beyond those of Service Desk r11.
Also note the following statement on Service Desk's support for multiple-languages within the one implementation is commented on in Multi-Language_Issues_with_Service_Desk_r11.txt, which is supplied with the r11.2 Cumulative 1 patch QO91538.
Start of extract from Multi-Language_Issues_with_Service_Desk_r11.txt:
Statement on Service Desk multi-language support
Summary Unicenter Service Desk is not currently designed to mingle text from multiple languages within a single application instance. Multiple-language capabilities are planned in the Service Desk roadmap. R11 has incorporated some of the changes necessary to provide this, and additional changes are planned for the next major release, code named "Sigma" However, full simultaneous multiple-language capabilities are not anticipated within the Service Desk products until the next full release following Sigma.
Some Service Desk 6.0 implementers previously had some success in creating specific multi-language capabilities through artful arrangement of code-page settings. Ironically, changes in the Service Desk r11 release on the Windows platform, required to further our multiple language capabilities in later releases, eliminated the previous "undocumented capability. In an effort to restore much of the lost capability, the Service Desk development team has created a patch, for Service Desk on the Windows platform that enables use of UTF-8 encoding. Linux and UNIX versions of Service Desk do not need the patch.
Use of UTF-8 encoding provides for some capability to mingle multiple languages, but there are numerous situations where certain textual data values will result in improper operation and/or application errors. CA has created a patch to Service Desk r11.2 that enables use of the UTF-8; however, there are a number of issues that cannot be resolved without the architectural changes planned for later releases.
Service Desk customers who have an immediate need for limited multiple-language capabilities may consider use of this patch; however, customers must be aware of the shortcomings of this approach and validate for themselves that the operation of the system with the patch will meet their needs "as-is".
This document is intended to outline the known issues that may be encountered by customers. These issues exist in Service Desk 6.0 versions as well as r11. These known issues will not be addressed in the r11 release time-frame and may not be resolved in the Sigma release time-frame.
Known Issues
- Sort order returned does not incorporate proper ordering for accented/extended characters. Typically, all accented characters will appear later in the sort order than all unaccented characters.
- Searching returns no results when provided with search values that have accent/extended characters included.
- Using the Mail Eater service to receive email-based inbound issue with accented/extended characters. Mail Eater fails to properly create the issue and does not send notifications to the originator. Attempts to access the resulting issue from the application results in runtime errors displayed to the end-user.
- LDAP integration is intolerant of accented/extended characters. LDAP records with extended characters are not merged properly and resulting searches for these contacts will result in either no rows found or runtime errors.
- LDAP integration is intolerant of accented/extended characters. LDAP records with extended characters are not merged properly and resulting searches for these contacts will result in either no rows found or runtime errors.
- Preview capability within the Web Screen Painter does not display accented/extended characters properly.
- Attachments with accented or extended characters in the file path or file name will not properly upload and cannot be properly downloaded.
- Scoreboard queries given a name with accented/extended characters will create a runtime error when being displayed.
- The scoreboard graphing capability does not properly display accented/extended characters.
- Searching knowledge documents for search strings with some accented/extended characters will fail with runtime errors.
- The NSM integration that creates an issue in Service Desk fails if the issue contains accented/extended characters.
- The Asset Viewer does not display accented/extended characters properly.
As you can see, the resulting operation of the Service Desk application does not meet our standards for quality and capability in this configuration. However, we know that some of our customers are looking for a mechanism that allows them to leverage some multiple-language capabilities, even though they must avoid certain elements. For the most part, these systems are set up to operate as primarily English-language systems that allow capture of additional language text into descriptions, event logs, and other text fields that are not key elements of searching or sorting. With the exception of the aforementioned issues, systems set up in this manner should be able to operate normally.
End of extract.
Environment
Component: ARGIS
Feedback
