Susan,
The AR System supports the localization of applications (whether BMC supplied
or custom) and all aspects
of the application.
First, you need to understand that there are two different languages in an
application:
DISPLAY language
This is the language that the display uses. It controls the labels,
selection values, error messages,
menus, date/time format, and all other aspects of the display of the
system OTHER THAN the data
content of fields. This is controlled by user preference settings of the
locale and number separator
and date/time format. Some of this is automatic. Some relies on the user
entering various localized
versions of messages in a catalog. Some relies on application VUIs being
constructed correctly.
DATA language
This is the language that the data CONTENT of the records are in. This is
what is IN the various
character fields on the system. This is really controlled by what the user
types in.
The system will try to show all the DISPLAY components to each user in their
local language.
The system just shows the DATA as it was entered without translation.
There is a chapter on Localization in the manuals that describes all the
details of how to localize all aspects
of the DISPLAY portion of the product.
Labels - create alternate VUIs with the same name but different locale and
change the label property of
fields to the new language
Selection fields - on the alternate VUI, open up the selection field and you
will find that you can supply
alternate words for each of the selection values
Error messages - there is a catalog form where you enter alternate text for any
system or any active link,
filter, or escalation message so you can translate it to another language
FB strings, and about 15 other things - the message catalog form is used for 15
to 20 categories of
strings in various areas of the product where you can supply alternate
versions of the strings for
different languages
Menus - static menus - use the message catalog
Menus - dynamic menus (query menus) - Use the LOCALE field (not field 112 which
is the row level
security field but field (sorry, cannot come up with the field ID right
now, but it is in the documentation,
it is a field in the 100s range). You can then enter into your source of
the query data records for each
item in each language and the system will pull the right version. You can
also use this for Set Fields
operations and select the "locale aware" option to pull data for a given
locale. I believe the same option
is available for table fields in the current releases. From an API
program, it is an option you can specify
on a GetListEntry or GetListEntryWithFields call to have the system use this
locale field to return only
data from the specified locale.
So, all of these things can be localized. All of these options and operations
are documented in the
Localization chapter.
So, you can completely localize all aspects of the Display.
Take a look at that chapter - probably in the Configuration Guide or
Administrators Guide.
NOTE: If you are going to mix data languages, make sure you configure your AR
System server as a
UNICODE server (and the DB too) to make sure that it cleanly stores all the
characters of all different
languages. Otherwise, you may have characters get stepped on when using a
character set that does
not have proper representation for characters of other languages than the
character set was
intended.
I hope this helps,
Doug Mueller
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Susan Palmer
Sent: Tuesday, April 24, 2012 2:03 PM
To: [email protected]
Subject: Remedy in Chinese
**
Hi Everyone,
We have an office in Shenzhen, China that began 3 years ago and at that time
the staff was small and we were able to hire English speaking/writing staff.
No problem.
Now that our business is growing there we need to accommodate non-English
speaking staff. Also basic things like installations and invoicing require
exact Chinese spelling and some of that is getting lost in the Chinese to
English to Chinese translations causing issues.
I know that the 'Simplified Chinese' language set is supported but I interpret
that to mean in field labels.
Does anyone have experience with adding a second language to an existing Remedy
application? This would include menus and selection field values. Did you
have to run two sets of menu and somehow activate the one you want dependent on
say your locale? What did you do for selection field values.
That leads to database issues and how that is all stored too.
The idea is a flavor of follow the sun for support. If you're in Europe or US
you see English, if you're in China you see Chinese. How does that happen? I
figure the locale takes care of the labels although I'm not really sure how
that happens but what about field contents?
Any experiences you've had would be helpful to know.
I appreciate your feedback.
Susan
ARS v7.5p3
Oracle 10g
Sun Solaris UNIX
Users on Windows XP and 7 64bit
Susan Palmer
Enterprise Remedy Developer and Administrator
ShopperTrak Chicago USA
O: 312.529.5325 | M: 312.502.7687
[email protected]<mailto:[email protected]>
www.shoppertrak.com<http://www.shoppertrak.com/>
ARS v7.5p3
Oracle 10g
Sun Solaris UNIX
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
