|Oracle® Fusion Middleware WebCenter Sites Installation Guide
11g Release 1 (220.127.116.11.0)
Part Number E29632-03
|PDF · Mobi · ePub|
This chapter describes how to configure your environment to enable multi-language operations in WebCenter Sites.
This chapter contains the following sections:
The settings that you choose for a given WebCenter Sites instance must be reproduced on all cluster members (if any) and across all environments (development, content management, delivery, and so on).
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.
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
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
charset=Shift_JIS. Sites Explorer depends on this setting to display data correctly.
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
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:
For example, in relation to the scenario described above, this property would be specified as follows to indicate to WebCenter Sites to use
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
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.
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 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
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.
.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:
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 (
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
Tree tab names
Names of workflow building blocks (actions, e-mail objects, conditions, states, steps, processes)
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).