Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

A little bit of history... SAP MDM 5.5 started its life as a single-language catalog management system. You could create a repository in any language you liked, but if you needed to have the content in multiple languages the only option was to create a new repository for each language.

When it became apparent that customers had a real need for data in different languages simultaneously, this capability was added to the MDM product.  Now, using the MDM Console, you can add support in a repository for as many languages as you need.  Once you define support for another language, you have the optional ability to give the tables and fields names in that language (via the Console), as well as to enter data in that language (via the MDM Data Manager). The Win32 MDM Data Manager application allows you to see on one screen all the data in the different languages.

Example of a repository which supports English and German (note that the field name "Category" is also defined in German):



Example of multilingual data in the Data Manager:

The COM and Java API's give access to the MDM multilingual capabilities, but with the restriction of one language at a time. This means that if you want to, for example, display both the English and German data on the same screen / web page, you need to hold two instances of the Catalog object (COM) or the CatalogData object (Java) - one for each language.


Using the Java API
As I stated previously, both the data and the repository schema can be multilingual. Normally, a repository schema (table and field names) is built in one language, and then some or all of the tables and fields are translated to the other languages.

The Java API allows for working with data in one language, while using a schema in a different language. This is useful because if you try to use a schema which has not been fully translated, the API will throw an exception when you try to use the Login() method.
Use the function SetCodeRegion() to define the schema language to work with.
Use the attribute RegionTag of function Login() to define the data language.

Example: Use the English schema and work with German data


CatalogData myCatalogData = new CatalogData();
myCatalogData.SetCodeRegion("English [US]");
myCatalogData.Login("localhost", 1234, "User", "Pwd", "German [DE]", ...);

Note:
(i) You must call the function SetCodeRegion() before logging in.  Attempting to call it after you are logged in will result in an exception being thrown.
(ii) If you do not set the code region, it defaults to the language parameter in the Login() function.

Once you have logged in with specific schema and data code regions, continue using the API according to the following:

1)       The function GetName() of CMFieldInfo and CMTableInfo returns the data language name.
2)       The function GetCode() of CMFieldInfo and CMTableInfo returns the schema language name.
3)       When referring to fields or tables by name, you must use the schema language name. For example, when adding field names to a ResultSetDefintion.


Using the COM API
The COM API's multilingual capabilities are not as fully flexible as the Java API's. There is no SetCodeRegion() function, and the Field and Table classes only have a Name property, and not a Code property. However.....! When using the COM API you can access tables and fields which are not translated, by using the primary inheritance language names. For example, if we have logged into a catalog in French which has English as its primary language then if the "category" field has been translated then we must access it using the name "Categorie".  However if it has not been translated, then we must access it with its English name, "Category".


4 Comments