This chapter describes how to configure your environment to enable multi-language operations in WebCenter Sites.
This chapter contains the following sections:
Note:
For setting UTF values, see "Configuring URI Encoding", and "Setting the Classpath and Java Options".Note:
If none of the properties and variables described below are set, the cs.contenttype property defaults to text/html. The character set of the output now defaults to default system encoding.
The cs.contenttype property, in futuretense.ini, is a system-wide (global) property that defines the outgoing character encoding. By default, the property is set to text/html; charset=UTF-8. If you need a specific encoding, change the value. For example, if you want the outgoing encoding to be Shift_JIS, set this property to text/html; charset=Shift_JIS. Sites Explorer depends on this setting to display data correctly.
The cs.contenttype variable enables you to control the outgoing encoding on a page-by-page basis. This variable overrides the value defined in cs.contenttype property. The variable should be set in the same way as the cs.contenttype property, as shown in Section 11.1.1, "cs.contenttype Property."
Note that pages under WebServices are set to cs.contenttype=application/xml;charset=UTF-8.
If you are using an HTML form tag to input international data, make sure to set the _charset_ input type variable at the very beginning, after the form declaration. For example:
<form action='ContentServer' method='get'>
<input type='hidden' name='_charset_'/>
<input type='hidden' name='pagename' value='<%=ics.GetVar("pagename")%>'/>
<input type='text' name='name' value='<%=ics.GetVar("name")%>'/>
<input type='submit'/>
</form>
Without a value, the _charset_ hidden variable works only on the Internet Explorer browser.
When WebCenter Sites needs to consume HTTP requests with certain encodings (Cp943C for example) that are closely related to a more widely used encoding (Shift_JIS), it is not sufficient to rely on the _charset_ hidden variable alone. Internet Explorer, when it encounters a _charset_ value set to Cp943C, changes it to Shift_JIS. This forces WebCenter Sites to read all data in Shift_JIS. To overcome this, a special names property syntax is used:
cs.contenttype.<charset>=<preferred_encoding_for_this_charset>
For example, in relation to the scenario described above, this property would be specified as follows to indicate to WebCenter Sites to use Cp943C:
cs.contenttype.Shift_JIS=Cp943C
Note that this property structure is necessary only in special circumstances such as the one described above, where the behavior of Internet Explorer conflicts with and changes the value of _charset_ value.
The encoding in the <?xml line of an XML element specifies the encoding of the .xml file on disk. The same is true of JSP. The encoding specified in the page directive specifies two things. The first is the encoding of the .jsp file on disk. The second is the outgoing encoding of the evaluated JSP element. This gets converted to the encoding of the enclosing JSP, or in the XML case, the outgoing encoding of the page (content-type). So cs.contenttype can be used to indicate that the outgoing page will have a specific encoding, such as Shift-JIS, but a JSP can output UTF-8, and the UTF-8 will get converted to Shift-JIS into the output stream of the page response. The following example shows how to specify the encoding:
XML: <?xml version="1.0" encoding="UTF-8"?>
JSP: <%@ page contentType="text/html; charset=UTF-8" %>
You can also control the outgoing page encoding by using the SetVar tag in JSP and XMLs. The SetVar tag must be set before anything is streamed out.
In JSPs, you can write:
<cs:ftcs> <ics:setvar name="cs.contenttype" value="text/html; charset=UTF-8" /> ... </cs:ftcs> In XML, you have the following options: <ftcs> <setvar name="cs.contenttype" value="text/html; charset=utf-8"/> ... </ftcs>
The second option is to use the ics.streamheader XML tag, but again this must be done before anything is streamed, and only in XML.
<ftcs> <ics.streamheader name="Content-Type" value="text/html; charset=utf-8"/> ... </ftcs>
Internet Explorer 8 by default has all the languages installed. If you are unable to see text in a particular language, you most probably need to enable it in your browser.
To view content in different languages
Go to Tools > Internet Options > General tab.
Click Languages on the bottom right of the page.
Click Add to add more languages to the list of languages already displayed in the box.
Click OK.
Close and reopen Internet Explorer. You should now see the content in your specified language if the web page so provides.
The following sections list several features in WebCenter Sites and spark with specific internationalization requirements. The features are:
Many indirect files are stored on the file system because of the url column references. The files are identified in this section.
The HTML files are read using the file.encoding Java parameter value. The data in the file also depends on the way it was stored initially.
SystemSQL uses a url column to point to a file on the file system that holds a SQL query. When this file is loaded, it is assumed that the encoding of the file is the Java default encoding (System.getProperty("file.encoding")). There are several possible ways to create the SystemSQL queries (use Sites Explorer, a text editor, or WebCenter Sites). It is probably best to always use ASCII7 when creating queries, since any data is typically merged using variable replacement at run time.
You have two ways to specify the text for an attribute editor:
Type in the text in the text area provided. The form post will determine the encoding.
Use the Browse button to select a text file. The text file encoding should match the encoding specified in xcelerate.charset encoding. (The xcelerate.charset property is located in the futuretense_xcel.ini file.)
When non ASCII files are posted via XML Post, the java file encoding must match the encoding of the file. For example, if you are posting a Japanese file (stored as UTF-8) to a UTF-8 system, then one of the following should be set before the XML Post command is run:
The system locale must be set to UTF-8.
The option of -Dfile.encoding=UTF-8 must be specified in the XML Post command.
Similarly, if the file is stored as Shift_JIS, then the corresponding system locale should be set or the java file.encoding option must be specified.
WebCenter Sites supports the encoding in the <?xml line, as the first line in the posted XML file. This overrides everything else as far as the encoding in which the .xml file is read.
Open the CatalogMover.bat (or .sh on UNIX) file and modify the java command to include the file.encoding parameter with a value that reflects the encoding needed to display the characters stored in the catalogs. This step can be avoided if the default encoding of the file system matches that of the data stored in the catalogs.
Sites Explorer requires that the cs.contenttype property in futuretense.ini be set to the correct value. If you are viewing simple ASCII characters, nothing needs to be done. However, for viewing complex characters, such as Japanese, you need to set cs.contenttype to one of the following:
text/html;charset=SJIS
text/html;charset=UTF-8
Also, users may need to load font support for Japanese and various other character sets in order to have them display correctly. To do this in Windows 2003 for example, go to Settings > Control Panel > Regional Options. In the first tab, General, select the languages you want to support from the list titled "Language settings for the system." Click Apply then OK. At this point you will be required to put in the Windows installation CD.
The Sites Desktop and Sites DocLink clients support the character sets supported by Windows. To enable a specific character set in Sites Desktop or Sites DocLink, first enable it in Windows. For instructions, see the Microsoft Windows documentation.
The user's machine must be able to support the characters that are to be displayed in the WebCenter Sites interfaces. For languages other than English, the user needs to make sure of the following:
The appropriate fonts to display the characters are installed.
On a Windows machine, the locale and language settings must support the characters that will be displayed. For example, if Japanese characters are to be displayed in the interfaces, Windows must first be configured to display Japanese characters. (For instructions on configuring Windows to support the target language, see the Windows documentation.)
For a UNIX machine, the locale (LANG and LC_ALL environment variables) must be appropriately set.
The browser's encoding must be correctly set.
Although you can configure a content management system to be multi-lingual, certain parts of the user interface can be displayed in one language only.
For example, the names of tables and columns in the WebCenter Sites database as well as individual items such as categories and source codes can have only one name. This means that although much of the text on an individual WebCenter Sites form can be displayed in multiple languages, items such as field names and asset type names can be displayed in one language only.
Following is a list of items in WebCenter Sites that can have one name only, which means that they can be displayed in one language only:
Asset type names
Field names
Asset names
Categories
Source codes
Tree tab names
Site names
Names of workflow building blocks (actions, e-mail objects, conditions, states, steps, processes)
Role names
Start menu items—both Search and New
On a system that supports two or more languages, you must determine which language is going to be used by the majority of content providers and then use that language to name your sites, tabs, asset types, and so on.
WebCenter Sites has the following functional restrictions for international use:
The Property Editor supports ASCII only.
Decimal numbers must be entered in US format ("." decimal separator).