ServiceGrid Article - Multilanguage
Cisco ServiceGrid provides different application languages in the web based user interface. The end user can select their preferred language.
The Language ISO Codes are stored in the SD Database. These codes are used to assign the following to a user:
All languages, which are supported as Application Language by the SD Applications, have a value for the Locale set in the language table.
- English / en
- Deutsch / de
- Czech / cs
- Croatian / hr
- Hungarian / hu
- Polish / pl
- Romanian / ro
- Slovak / sk
These languages can be selected as Application Language by the user and should be implemented by the following:
- language specific property files
- language specific buttons
To translate the SD Application into a new language, a language specific property file has to be created and all buttons should be translated.
Language specific elements Buttons
Buttons used in the SD Application are gif files stored in different directories for each language. The names of similar buttons are the same for each language. The entry in the property file defines the directory path to the language specific button.
Text in the Property Files
For each language, a property file exists, containing all literals (more than 2600) used in the SD application. The property file consists of one line per entry containing the key and the translation.
For example, property file for German.
Users = Benutzer Key=Users Translation=Benutzer
The entries in the property file may have different forms as follows:
Entries for buttons
For example, property file for German.
goButtonBTN = ../images/german/goButton.gif
Entries with space characters in the key
For example, property file for German.
Change\ master\ data = Stammdaten ändern
Entries with parameters
For example, property file for German.
Helpdesk\ was\ changed = Helpdesk wurde geändert auf <>
Translation tables in the database
The Cisco ServiceGrid database contains tables to store and manage the translations using property files. All keys and all translations for each language are stored in these tables.
Following are the programs used for translation:
| Program|| Description|
| Generate Property File ||
This program is used to generate a property file for a language.
To translate into a new language or to add a new key, the data in the translation tables in the SD database should be changed or created.
The new property file will be generated using the Generate Property File program.
The property files should not be changed manually.
| Upload keys || This program is used to upload new or changed keys from the CSV files into the SD database.|
| Upload Translations|| This program is used to upload new or changed translations from the CSV files into the SD database.|
| Download translations|| This program is used to downlaod keys and translations from the SD database into a CSV or XLS file.|
NOTE: All translation work can be done in an Excel sheet, or any other program which can read and write CSV or XLS files format.
Translation process Text
Step 1: Download all Keys including Theme and Usage into a XLS file.
Step 2: Translate in this file using Excel or other tool.
Step 3: Upload the file (as CSV) into the database.
Step 4: Generate a new Property file.
Step 5: Link the Property file into the SD application code.
Step 6: Test the application.
Step 1: Translate the texts on the buttons.
Step 2: Use a graphics program to create the new buttons.
Step 3: Store the new buttons in the language specific buttons directory.
Step 4: Change the directory path for the buttons in the XLS translation file.
To make the translation work smooth, more than 2,600 keys are categorized using Theme and Usage.
- Theme: The area the word or sentence belongs to. For example, Contract, User, and so on.
- Usage: The usage of the word or sentence. For example, service, installation, repair, and so on.
Best order of steps
The best way to translate is to obey this order:
- Usage: Basic, Theme: All, (see Chapter Basic terms)
- Usage: All, Theme: Date
- Usage: Buttons, Theme: All
- Usage: Functions, Theme: All
- Usage: Simple, Theme: All
- Usage: Message, Theme: All
Usage: Error, Theme: All
The following are the basic terms:
| Key|| Theme|| Description|
| Action|| Action|| An action is performed by the editor of a call by clicking on the action list on the right side of the screen. An action is connected to a call detail form. Actions can be customized.|
| Activities|| Activity|| An activity is connected to a call and contains work time, travel time, and description fields.|
| ActivityType|| Activity|| The activity type is used to categorize activities (for example, service, installation, repair, and so on).|
| BPartner|| Company|| A business partner is a company, who is acting as service provider or service customer in a service contract.|
| Calculation|| Logistic|| A calculation is used to calculate expenses and revenue in a call.|
| CallDetail|| Call|| The call detail is the form displaying the call data. Call detail forms can be customized using setups.|
| Caller|| Common|| A caller is the person requesting for a service.|
| CallID|| Call|| The CallID is the unique number of a call in the SD database.|
| CallList|| Call|| The call (tracking) list is the list displaying selected calls. Call lists can be customized using setups.|
| CallOpen|| Call|| The CallOpen time is the date and time when a call was opened.|
| CallState|| Callsystem|| The call state is the state of a call in the workflow. The list of possible call states is defined by the customer and customized in the callsystem.|
| CallSystem|| Callsystem|| A callsystem is the definition of a specific workflow and contains the list of status codes and successors, the list of actions, the call detail and call tracking list setups, the priority codes, failure types, problem types, severities and categories.|
| CallTracking|| Call|| The call tracking (list) is a list displaying selected calls. Call lists can be customized using setups.|
| Categories|| Common|| Categories are used to define a hierarchy (tree) for classification of a call.|
| Communication|| Communication|| A communication specifies the method for sending and receiving messages.For example, mail, SMS, SOAP, and so on.|
| Company|| Company|| A company is mandatory in the SD database. A company may be divided into organizations. Users are members of organizations of a company.|
| Contact|| Connection|| The contact person is the person in a call who should be contacted for questions or information.|
| ContractElement|| Contract|| The contract element within a contract describes the service level.|
| Converter|| Converter|| A converter is a method used by the SD platform to send and receive call transactions.|
| Country|| Common|| A country (for example, Austria, Germany, Poland).|
| Customer|| Common|| The (service) customer is the business partner in a contract requesting services from the service provider.|
| Device|| Device|| A device is a component in the inventory having a unique identification (serial number). A device may be a hardware or software component. (for example, desktop, printer, office software, and so on).|
| DeviceType|| Device|| The device type is the identification or name of the device given by the manufacturer (for example, MS Project XP, T42, C4678A).|
| Dictionary|| CommonContent|| The dictionary is part of the common content module of SD and contains information about fields in the SD application.|
| Dispatching|| Common|| Dispatching is the process of routing a call to a queue or technician.|
| Document|| Logistic|| A document contains the data about receive, return, ship, and transfer of parts.|
| Download|| UploadDownload|| Download functions are used to export data from the SD database into CSV or XLS files.|
| Editor|| Common|| The editor is the user having rights to change a call, device or location.|
| EMail|| Common|| Email is one of many communication methods to send or receive data from or to the Cisco ServiceGrid platform.|
| FailureType|| Callsystem|| Failure types may be used to categorize a call.|
| Filename|| Common|| A filename is required when uploading data from CSV files to the SD database.|
| Helpdesk|| Call|| The hepldesk (person) is the user creating a new call.|
| History|| Common|| History records are used to store the history of calls and devices in the SD database. Logistic Inventory is the method of counting and updating parts stock numbers.|
| Location|| Location|| Locations are used to group devices. Each device has to be referenced to a location. Locations belong to organizations of a company.|
| Login|| Common|| Login (into the SD platform) requires username and password.|
| Logout|| Common|| Logout (from the SD platform).|
| Manufacturer|| Common|| The manufacturer of a device.|
| Mapping|| Callsystem|| Mappings are used to map status codes of the different call systems of service provider and service customer side. It is a method to store company specific data which has to be mapped to certain values in the SD.bridge process.|
| Menu|| Common|| Menus contain the SD modules in the first level and menu entries (for example, Locations, Devices, and so on) in the second level.|
| Message|| Message|| A message may be sent through a communication from the SD platform to a receiver.|
| MyAccount|| Common|| MyAccount is the menu entry to enable the user to change their own data.|
| MyArchive|| Common|| MyArchive is the menu entry granting access to the users’ archived reports.|
| MyCompany|| Company|| My company is the menu entry granting access to all data of its own company.|
| MyCustomers|| Common || My customer is the menu entry showing a list of all customers in the user's contracts.|
| MyProviders|| Common || My provider is the menu entry showing a list of all providers in the user's contracts.|
| MyReports|| Report|| My report is the menu entry giving access to the user’s collection of report groups.|
| Organizations|| Organization|| An organization is part of a company. Users are members of organizations and organizations have service contracts with other organizations.|
| Owner|| Device|| The owner of a device is the person who is responsible for the device (for example, the notebook).|
| Parent|| Call|| A parent call is connected to one or more child calls.|
| Part|| Logistic|| A (spare) part is an item which hold on stock and does not have a serial number.|
| Password|| Common|| The password is required for login into the SD platform.|
| Portal|| Common|| A portal is an application providing login and access for users of other applications. Using the SD SOAP Web services, functions and data from the SD platform can be integrated and used by a portal.|
| Priority|| Callsystem|| Priorities are used to categorize the call.|
| ProblemType|| Callsystem|| Problem types are used to categorize a call.|
| Provider|| Common|| The (service) provider is the business partner in a contract providing services to the service customer.|
| Queue|| Queue|| Queues are used to dispatch calls to a group (queue) of technicians.|
| Receiver|| Message|| The receiver is the person or system receiving messages from the SD platform.|
| Recovery|| Call|| The Recovery (time) is the time when the incident or service request is solved. The recovery time is part of the Service Level Agreement (SLA).|
| Response|| Contract|| The response (time) is the time when the incident or service request is responded by the service provider. The response time is part of the Service Level Agreement (SLA).|
| Rootdevices|| Device|| A root device is a device having other devices as sub devices, thus building a hierarchy (tree) of devices.|
| Scheduler|| Scheduler|| Schedulers are used to send data to a receiver automatically at certain dates and times (for example, reports every Friday at 22:00).|
| Sender|| Message|| The sender of a message is the person or system sending a message to the Cisco ServiceGrid platform.|
| ServiceLevel|| Common|| The service level contains the service time (for example, Mon to Fri 8:00-17:00), the agreed response time and recovery time.|
| Setup|| Setup|| Setups are used to customize call lists, call detail forms and location lists.|
| Severity|| Callsystem|| The severity may be used as additional categorization criteria in the call.|
| Shipment|| Logistic|| Parts are shipped to the customer within a repair action.|
| Skill|| Skill|| Skills are attributes of a technician.|
| SLA|| Contract|| The SLA is the service level agreement between provider and customer.|
| Solution|| Solution|| Solutions are records in the SD.solution database and may be searched by the editor of a call.|
| Status|| Common|| Status are used as call states and may be used as location states and device states.|
| Store|| Logistic|| A store is a location used as store in parts logistic.|
| Subdevices|| Device|| A sub device is a device having other devices as root devices, thus building a hierarchy (tree) of devices.|
| Successor|| Callsystem|| A successor is the status which may follow another status. The list of status and successors form the workflow within a call system.|
| Summary|| Common|| The summary function is used to group and summarize devices in SD.inventory.|
| Technician|| Technician|| A technician is a person who is a member in a queue. Calls may be routed to queues and technicians.|
| Template|| Template|| Templates are used to define the content of a message. Within a template all fields of a call can be used. Templates are written as XSL Transformations.|
| Timeline|| Report|| The timeline is one parameter of reports. For example, Year, Month, Week, and Day.|
| Tree|| Common|| Trees are used to display data on the screen in hierarchical order. For example, device tree, location tree, and so on.|
| Trigger|| Trigger|| A trigger is a rule, defining when a message should be sent.|
| Upload|| Common|| Upload functions are used to import data from CSV files into the SD database.|
| User|| User|| A user is a person having login rights into the SD platform or a person which is referenced in a call.|
| View|| Common|| A view displays the content of a call in a window using a template.|
Customer specific Texts
Beside the translation of texts and buttons in the application user interface, there are a number odd customer specific texts in different tables which are as follows:
Basic Data - MyCompany
- Templates (Template texts)
- ActivityTypes (Shortname, Name)
- DeviceStatusTypes (Shortname, Name)
- Queues (Shortname, Name)
CallAction (Shortname, Name)
CallStates (Shortname, Name)
Priorities (Shortname, Name)
Severities (Shortname, Name)
Failuretypes (Shortname, Name)
Problemtypes (Shortname, Name)
Categories (Shortname, Name)
Organisations (Shortname, Name, Address)
Basic Data - Contracts
- Contracts (Shortname, Name)
- Contractelements (Shortname, Name, Categories)
Basic Data – Users
Users (Firstname. Lastname, Address)
Common Content Text-Values
Therer are number of text entries which are not translated because these terms are international valid terms:
- IMAC Types. For example, Install, Move, Add, and Change.
- Reques Types. For example, Incident, Problem, Change, and Service.
- Names of Countries. For example, Germany, Austria, Poland, and so on.
- Names of Languages. For example, Deutsch, English, Polish, and so on.
- Names of Time zones. For example, Europe/Vienna, Europe/Berlin, Europe/Warsaw, and so on.
- Names of UNSPSC-Classes. For example, Hardware, Software, Computer, Desktop, and so on.
- Communication types. For example, SMTP, FTP, SOAP, and so on.
For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.