4.10 Enabling Language Detection

Oracle Forms architecture supports deployment in multiple languages. The purpose of this feature is to automatically select the appropriate configuration to match a user's preferred language. In this way, all users can run Oracle Forms applications using the same URL, yet have the application run in their preferred language. As Oracle Forms Services do not provide an integrated translation tool, you must have translated application source files.

4.10.1 Specifying Language Detection

For each configuration section in the Forms Web Configuration page, you can create language-specific sections with names like <config_name>.<language-code>. For example, if you created a configuration section "hr", and wanted to create French and Chinese languages, your configuration section might look like the following:

[hr] 
lookAndFeel=oracle 
width=600 
height=500 
envFile=default.env 
workingDirectory=/private/apps/hr 
[hr.fr] 

envFile=french.env 
workingDirectory=/private/apps/hr/french 

[hr.zh] 
envFile=chinese.env 
workingDirectory=/private/apps/hr/chinese

4.10.2 Inline IME Support

Inline IME support enables Forms Web applications to properly display the composing text in which each character may not be directly represented by a single keystroke (e.g. Asian characters) near the insertion cursor (so called inline, or on-the-spot). It is enabled by default. To disable, set the applet parameter "inlineIME" to "false" in the baseHTML file:

<HTML>
<!-- FILE: basejini.htm (Oracle Forms) -->
 <BODY>
 ...
 <OBJECT classid=...
>
<PARAM NAME="inlineIME" VALUE="false">
<EMBED SRC="" ...
inlineIME="false"
>
...
.
</BODY>
</HTML>
.
To have inline IME support, forms client needs to be Jinitator 1.3.1 or Plug-in 1.4.1+.

For more information about using baseHTML, see Appendix C, "base.htm, basejini.htm, and basejpi.htm Files".

4.10.3 How Language Detection Works

When the Forms Servlet receives a request for a particular configuration (for example, http://myserv/servlet/frmservlet?config=hr) it gets the client language setting from the request header "accept-language". This gives a list of languages in order of preference. For example, accept-language: de, fr, en_us means the order of preference is German, French, then US English. The servlet will look for a language-specific configuration section matching the first language. If one is not found, it will look for the next and so on. If no language-specific configuration is found, it will use the base configuration.

When the Forms Servlet receives a request with no particular configuration specified (with no "config=" URL parameter, for example, http://myserv/servlet/frmservlet), it will look for a language-specific section in the default section matching the first language (for example, [.fr]).

4.10.3.1 Multi-Level Inheritance

For ease of use, to avoid duplication of common values across all language-specific variants of a given base configuration, only parameters which are language-specific to be defined in the language-specific sections are allowed. Four levels of inheritance are now supported:

If a particular configuration is requested, using a URL query parameter like config=myconfig, the value for each parameter is looked for in the langage-specific configuration section which best matches the user's browser language settings (for example in section [myconfig.fr]),
Then, if not found, the value is looked for in the base configuration section ([myconfig],
Then, failing that, in the language-specific default section (for example, [.fr]),
And finally in the default section.

Typically, the parameters which are most likely to vary from one language to another are "workingDirectory" and "envFile". Using a different envFile setting for each language lets you have different values of NLS_LANG (to allow for different character sets, date and number formats) and FORMS_PATH (to pick up language-specific fmx files). Using different workingDirectory settings provides another way to pick up language-specific.fmx files.