VPRM

Internationalisation
Support
VPRM Release 9.8
Issue 11
Disclaimer

1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from
viruses.

1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss
of anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any
special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be
suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data
created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in
contract, tort (including negligence) or otherwise.

1.3 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the
user's claim is brought.

1.4 Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.

1.5 In the event of any conflict between the above clauses and the analogous clauses in the software licence
under which the AVEVA software was purchased, the clauses in the software licence shall take precedence.

Copyright

Copyright and all other intellectual property rights in this manual and the associated software, and every part of it
(including source code, object code, any data contained in it, the manual and any other documentation supplied
with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.

All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this
document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or
transmitted without the prior written permission of AVEVA Solutions Limited. Where such permission is granted, it
expressly requires that this copyright notice, and the above disclaimer, is prominently displayed at the beginning
of every copy that is made.

The manual and associated documentation may not be adapted, reproduced, or copied, in any material or
electronic form, without the prior written permission of AVEVA Solutions Limited. The user may not reverse
engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this
publication may be incorporated into any third-party software, product, machine, or system without the prior
written permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly
prohibited, and may give rise to civil liabilities and criminal prosecution.

The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms
and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.

Copyright 1994 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall
not be liable for any breach or infringement of a third party's intellectual property rights where such breach results
from a user's modification of the AVEVA software or associated documentation.

AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom.

AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK
Trademarks
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use
of the AVEVA or Tribon trademarks is strictly forbidden.

AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).

The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or
logo belongs to its respective owner.

AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK
VPRM Internationalisation Support Contents

Contents
INTRODUCTION ............................................................................................................................ 3
GLOSSARY ................................................................................................................................... 3
OVERVIEW OF INTERNATIONALISATION .................................................................................. 4
OVERVIEW OF MULTI-BYTE ENVIRONMENT ............................................................................. 5
Environment Restrictions .......................................................................................................... 5
Disclaimer ........................................................................................................................... 5
Restricted Entry Fields ........................................................................................................ 5
Cautionary Usage within VPRM .......................................................................................... 5
VPRM Configuration Restriction .......................................................................................... 6
Anticipated future developments ......................................................................................... 6
Multi-byte Data Entry................................................................................................................. 6
Reduced Multi-byte Character Limit .................................................................................... 6
Hint Text Notation ............................................................................................................... 6
Input Method Editors (IME).................................................................................................. 6
Text IO File Transfer ................................................................................................................. 7
INSTALLATION ............................................................................................................................. 8
TECHNOLOGY & TERMINOLOGY................................................................................................ 9
VPRM ....................................................................................................................................... 9
User Locale ......................................................................................................................... 9
Servlet Configuration ........................................................................................................... 9
VPRM format support for Microsoft Excel ......................................................................... 9
Text IO Interface ................................................................................................................. 9
Oracle ..................................................................................................................................... 10
NLS_LANG ....................................................................................................................... 10
NLS Dates ......................................................................................................................... 10
NLS Linguistic Sort ............................................................................................................ 10
Microsoft ................................................................................................................................. 10
Windows Regional Options ............................................................................................... 10
Microsoft Excel Interface................................................................................................. 10
PROCEDURES ............................................................................................................................ 12
Troubleshooting Multi-byte Data Entry .................................................................................... 12
Input Method Editor (IME) ................................................................................................. 12
Command Edit Menu (via IME).......................................................................................... 12
Toolbar Edit Functions ...................................................................................................... 13
Cut from 3rd Party Applications + Paste ............................................................................. 13
Cut and Paste via Keyboard between VPRM Entry Fields ................................................. 13
Imported Data (Excel & Text Files) .................................................................................... 14
Printing Multi-byte Data ........................................................................................................... 15
Configuring a PC for I18N ....................................................................................................... 16
Your Locale ....................................................................................................................... 16
Language Setting for System ............................................................................................ 16
Native Language Support........................................................................................................ 17
APPENDICES .............................................................................................................................. 18
Troubleshooting a VPRM Multi-lingual Environment................................................................ 18
Objective ........................................................................................................................... 18
Intended Audience ............................................................................................................ 18
Exceptions & Restrictions .................................................................................................. 18
Support Issues .................................................................................................................. 18
I18N Platform Configuration Guide .................................................................................... 19
Issue 10 Page i
VPRM Internationalisation Support Contents

Rules for Multilingual Support ............................................................................................ 22

Issue 10 Page ii
VPRM Internationalisation Support Introduction & Glossary

Introduction
This Guide is a central source of information for those users who wish to activate and utilise the
Internationalisation features that localise VPRM. The user must make constant reference to the
various sections contained here within and make themselves familiar with all the aspects and
implications of Internationalisation before embarking on installation, configuration and maintenance
of VPRM.
The intended audience is IT staff: who install, maintain, support VPRM, e.g. DBA, PC support,
network, server.
Contained in this guide is information relating to:
Installation Notes for Internationalisation
Definitions of the technology and terminology used in VPRM for Internationalisation
Procedures for the support of Internationalisation
Reference guides for trouble-shooting problems associated with Internationalisation support and
configuration.
Please refer to refer to the Release Notes accompanying the specific VPRM release for a list of
what languages and locales AVEVA have tested and support.

Glossary
TERM DESCRIPTION
I18N Internationalisation
NLS National Language Support
UTF-8 Universal Character Set Transformation Format, 8 bit
UCS2 Unicode Character Set, 2 byte
ASCII7 American Standard Code Information Interchange, 7 bit

Issue 10 3
VPRM Internationalisation Support Overview of Internationalisation

Overview of Internationalisation
Multiple environments may exist within a common VPRM system for support of different national
languages. Each of these national environments is called a locale, which considers the language, its
characters, fonts, and the customs used to input and format data. The VPRM Desktop Environment
is fully internationalised such that any application can run using any locale installed in the system.
Within VPRM, use of Servlet technology and Oracle NLS has been employed to achieve
Internationalisation. For each different NLS_LANG variant used to support different locales there
MUST exist a Servlet configured specifically to support that environment, please refer to Installation
Guide on how this is achieved.

Issue 10 4
VPRM Internationalisation Support Overview of Multi-byte Environment - Environment Restrictions

Overview of Multi-byte Environment

A multi-byte environment is one that utilises more than one byte of storage per character to
encompass the entire set of characters required to support a given language or set of languages.
Certain characters that may be single byte in one given character set but may take multi-bytes in
another character set e.g. is a single byte for WE8ISO8859P1 character set but in fact requires 2
bytes for UTF-8 character set.
Note that, for the Oracle 11g database, the AL32UTF8 character set is used instead of the UTF8
character set. For the purposes of this document, references to UTF8 should be taken as applying
also to AL32UTF8.

Environment Restrictions
The intention here is to help users of VPRM understand the restrictions imposed on them with
regards the usage of multi-byte UTF-8 data. The term multi-byte is applied to characters that
require more than one byte of data to represent a given symbol. This document details a list of
known multi-byte usage restrictions for VPRM both from a configuration and operational stance.

Disclaimer
There are some known multi-byte usage restrictions, which are validated at the point of entry and
hence will be rejected. Such multi-byte usage is designated as a high risk status and they will
prevent VPRM from functioning. Other VPRM multi-byte usage restrictions, noted in this
documentation, are only cautionary. They may cause unpredicted results or even minor data
corruption. These problems may be resolved by changes to code or system configuration. Finally,
there are a number of areas where the ability to handle multi-byte data is out of the domain of
VPRM. It is these areas where AVEVA can only advise the user of the possible consequences.

Restricted Entry Fields

A user will be physically prevented and warned about the use of multi-byte characters and other
special character usage. The restricted use of characters on these parameters is primarily because
they appear in the URL, which has restricted character usage.
User Name
User Password
Project Name
Display Project Name
MR Number, PO Number
Template Document Name, MR or PO or Enquiry Attachment Name
Vendor Name, Vendor Location
Spec Name
Document Number or Document Filename (if using DDOC Display Document feature)

The term special character refers to the following list (which is not exclusive);
\ / | back slash, forward slash, vertical line
: * ? colon, asterisk, question mark, double-quote
<> less than, greater than
.% full-stop, single-quote, percent

Cautionary Usage within VPRM

Although no restrictions have been applied to these fields they do cause a potential risk in terms of
possible data corruption of operation

Issue 10 5
VPRM Internationalisation Support Overview of Multi-byte Environment - Multi-byte Data Entry

Shared network folder names

File names
Path names
E-mail fields within VPRM
VPRM Configuration Restriction
The environment from which the user accesses VPRM must abide by the following system
configuration setting restrictions for multi-byte data usage
PC client user name
PC client host name
Servlet name

Anticipated future developments

AVEVA anticipate that future developments will extend VPRMs capabilities for integration and
global access, which will require that Key Fields those that are used to identify data - need to be
standardized for use in URLs, filenames, system-to-system transfer and international project use.
Therefore AVEVA recommends that customers should adopt a robust approach to use of multi-byte
characters in current projects in anticipation of this, in order that standard reference data can be
accumulated and used for both local and international projects. Key Fields are those which
Are normally forced into uppercase on entry
Used as the primary reference when searching for data
For example
Line Number
Area Name
SCN
Delivery Point

Multi-byte Data Entry

This section explains the differences in the operation of VPRM for multi-byte data and how the
system is affected. Also included for information is the change in the hint text notation to assist
users with the entry of multi-byte data and how this is achieved with Windows IME.

Reduced Multi-byte Character Limit

The use of multi-byte characters reduces the users character entry capability on all data entry
fields. The data entry fields were originally designed to expect fixed width single byte characters,
where there was a direct correlation of 1 character = 1 byte. With the introduction of UTF-8 and
multi-byte character support this assumption does NOT hold true as a character can be of varying
byte size, please refer to Troubleshooting a VPRM Multi-lingual Environment for more information.
What still holds true is that the US-ASCII7 character set range in UTF-8 still maps to a single byte.
Beyond the ASCII7 range, a character can take up to 4 bytes. Please refer to www.w3c.org for an
up to date UTF-8 Character Set Definition of the character to byte relationship.

Hint Text Notation

To assist the user there is a change to the hint text notation. When a user moves the cursor into a
data entry field the user is provided with hint text concerning the context of that field and the data
that is expected. At the beginning of the hint text there is a number in square brackets that denotes
the byte limit of that field. Note the reference to byte; this does not now correspond to the number
characters in the case of multi-byte characters, as described above.

Input Method Editors (IME)

To assist users with the ability to enter Ideographs from a standard ANSI keyboard Microsoft have
developed an application referred to as IME. The IME, which is loaded as part of the Configuring a
PC for I18N, uses a phonetic dictionary that corresponds to an ideograph to allow users to generate

Issue 10 6
VPRM Internationalisation Support Overview of Multi-byte Environment - Text IO File Transfer

the script. Microsoft is currently extending the language support for IMEs, which includes Japanese,
Chinese and Korean etc. Please refer to Microsoft for the current list of IMEs. VPRM supports
characters entered into data entry fields via an IME provided that the System Locale supports the
language.

Text IO File Transfer

The transfer of text files, containing multi-byte data, using the Text IO utility necessitates that the
Internet Explorer session is configured as UTF-8 Encoding. The Installation of VPRM now forces the
encoding of the VPRM Internet Explorer to UTF-8. This has the effect that the encoding of any text
files downloaded from VPRM will be saved as UTF-8 encoding, which does not cause a problem if
the content of the text file is in the US-ASCII7 range. The user must be aware that if the text file
does contain multi-byte UTF-8 data then they must use a UTF-8 compliant editor e.g. MS Notepad
and MS Word etc. to modify the data and save the data as UTF-8 encoding.
NOTE that VPRM is able to handle Byte Order Markers (BOM) used by some editors, such as MS
Notepad & Word XP, which indicate Big Endian and Little Endian multi-byte data.

Issue 10 7
VPRM Internationalisation Support Installation - Text IO File Transfer

Installation
Please refer to the Installation Guide and take extra note of the options to support multi-byte
characters, in the Internationalisation (I18N) configuration section. Please note that by selecting the
Multi-byte Character Support option activates Font Aliasing, which will affect the appearance of
the Reports.

Issue 10 8
VPRM Internationalisation Support Technology & Terminology - VPRM

Technology & Terminology

This section describes some of the terms used in this documentation used to describe the
technology applied to VPRM to facilitate Internationalisation. It is IMPORTANT that the reader
familiarises themselves with the technology and terminology to assist with support and maintenance
of VPRM in an Internationalised environment.

VPRM

User Locale
Each VPRM User now has a preferred Locale setting configured as part of their User Profile. This
User Locale determines the NLS_LANG setting to be applied to the VPRM user session and also
determines the Servlet environment used during Module access.

Servlet Configuration
Servlet technology has been adopted on VPRM. Servlets are configured on the AS web server as a
means to support many different NLS Locales on the same hardware. Each configured user Locale
should be supported by a corresponding NLS configured Servlet environment. Please refer to the
Operating Environment Guide and Installation Guide for more details on the AS Servlet set up and
configuration.

VPRM format support for Microsoft Excel

Dates
The ability of VPRM to handle different localised date formats has necessitated the need to transfer
dates in a non-localised format, which is still recognised as a date on the client PC within the MS
Excel application. The non-localised date format employed is the Microsoft serial value. Please refer
to the Microsoft Online Help within Microsoft Excel for a full explanation. The ability to
transparently deal with dates of different localised formats means that VPRM must be aware of the
short date format of the AS Windows environment to enable the correct date formatting within the
spreadsheet, see Web Server VPRM.ini File. Once the date is in the Windows short date format, the
date will automatically adopt the short date format of any localised PC that the spreadsheet is
opened.
Numeric Format
The Windows Regional Options [Numbers] determines the expected numeric format in Microsoft
Excel. The localised client PC running Microsoft Excel will display and expect numbers to be in the
format specified by its own Regional Options setting. The VPRM software on the AS web server,
whose numeric decimal point format is ., must be able to interface with Microsoft Excel in the
required numeric format, refer to Web Server VPRM.ini File for more instructions.

Text IO Interface
Dates
The format of dates in the various VPRM Interfaces that utilises Text IO is in a fixed format as
described in the table below;

Interface Date Format

HPRO DD-MM-YYYY
VPRM@site DD-MM-YYYY
PENTA YYYYMMDD

Issue 10 9
VPRM Internationalisation Support Technology & Terminology - Oracle

Where:
DD Day of Month (1-31)
MM Month of Year (1-12)
YYYY 4 digit Year (i.e. 2002)

Numeric Format
The numeric decimal point format expected for import and export of data via the Text IO Interface is
.. The Windows Regional Options does not affect the expected format.

Oracle

NLS_LANG
NLS_LANG is the environment variable used by Oracle to localise the users environment. It is made
up of 3 components that consequently change the behaviour of the Oracle product and the
operation of VPRM. The NLS_LANG has been extensively used in VPRM to localise the behaviour
of Dates and Linguistic Sorting (as detailed below). See the Troubleshooting a VPRM Multi-lingual
Environment for a more detailed definition of NLS_LANG in context with VPRM or refer to the
Oracle documentation.

NLS Dates
All the date formats that appear in VPRM Screens are sensitive to the Locale setting of the User.
The localised date format for supported Locales is specified in the Oracle NLS Guide. The date
format on VPRM Reports will be generated in the format of DD-MON-YYYY, where MON will be
localised to the Users language (i.e. Jan in English will be Ene in Spanish).

NLS Linguistic Sort

All linguistic sorting within VPRM will now be localised, via the use of the Users NLS setting for
sorting. Certain characters and combinations of characters are sorted differently in different locales.
For a detail explanation on the different localised linguistic sorting please refer to the Oracle NLS
Guide.

Microsoft

Windows Regional Options

The set up of the iAS web server and PC client platform software, Microsoft Windows, affects the
functionality and support of VPRM concerning I18N support. Please refer to Configuring a PC for
I18N on how to set up the Windows Regional Options environment and Troubleshooting a VPRM
Multi-lingual Environment for a detailed explanation on how the Windows environment affects the
operation of VPRM.

Microsoft Excel Interface

Configuration
WEB SERVER LOCALE
The iAS Server default System Locale must be configured in the Regional Options for the given
language character set support required by the Microsoft Excel Import content. Please refer to
Configuring a PC for I18N.
WEB SERVER VPRM.INI FILE
In VPRM.ini, there are two parameters associated with Microsoft Excel configuration;
Issue 10 10
VPRM Internationalisation Support Technology & Terminology - Microsoft

SHORT_DATE_FMT and DECIMAL_POINT, which should correspond to these settings in the

Regional Options for the AS Server.
PC CLIENT
The default Locale setting of the client does NOT affect the ability to import characters of a different
character set. For instance, a Japanese user will be able to import a spreadsheet containing
Spanish characters into the Database.
The date format displayed in the Spreadsheet generated by VPRM will be determined by the Locale
of the client PC and NOT by the Locale setting of the VPRM users profile. This means that an
English VPRM User logged in via a Japanese client PC will operate with English dates in VPRM yet
Japanese dates in MS Excel.
The date formats of Microsoft Excel may differ slightly from the date format displayed within VPRM,
both of the same Locale. This is because the default standard date formats for the given Locale for
Oracle and Microsoft may well be different (i.e. Japanese date for VPRM is 2002-03-25 whilst in
Excel it will be 2002/03/25). The date format adopted is determined by the Application displaying the
date.
Numeric values will be displayed in MS Excel according to the setting of the client PC Windows
Regional Options, which may be different from the numeric representation within VPRM.

Issue 10 11
VPRM Internationalisation Support Procedures - Troubleshooting Multi-byte Data Entry

Procedures
This section contains a number of procedures that the reader will need to be aware of in order to
activate and utilise the Internationalisation features incorporated in VPRM. It also provides useful
information for data entry trouble-shooting. This will also be of particular interest to users who wish
to customise the VPRM system.

Troubleshooting Multi-byte Data Entry

The user should read the Installation Guide and take extra note of the options to support multi-byte
characters, in the Internationalisation (I18N) configuration section for guidance on whether a true
multi-byte character environment is essential.

This section is a guideline for users concerned with the behaviour of entering multi-byte data into an
entry field within VPRM. This should be used as a reference listing of the data entry restriction using
the identified data entry methods including which the user should be aware.

Input Method Editor (IME)

Method
Input Method Editor (IME) is an application that allows a user to enter predominantly Asian
ideographs via a standard ANSI keyboard. The IME application is loaded as part of the Windows
Regional Options Language setting, see Configuring a PC for I18N. The IME is executed when the
user selects an Input Locale that has a supporting IME. The IME will initially work in the passive
mode, whereby the keystrokes entered on the keyboard will appear on the screen. When the IME in
an active mode the keystrokes are intercepted, then via the use of a lookup dictionary the English
phonetics that matches an associated ideograph (i.e. in the Japanese IME ni-hon-go produces
, which are the ideographs for the word Japanese) will appear on the screen. When the IME
recognises a valid phonetic it displays the ideograph in an intermediate IME window. When the
space bar is used, denoting a word or phrase, the ideographs are copied into the data entry field if
the character limit has not been reached. The IME buffers multi-byte data that is potentially too large
for the data entry field, however it truncates the script to the nearest multi-byte character when the
field has reached its maximum limit for the number of bytes. Therefore, it is NOT possible to enter
more multi-byte characters or number of bytes than the maximum limit allowed for the data entry
field.
Conclusion
It is safe to use the IME application to enter data into VPRM. The user must be aware that the data
entered into the IME may be truncated when passed into the form.

Command Edit Menu (via IME)

Method
User selects the Command menu and Edit. The user then has a list of edit options;
Edit provides the user with a pop-up window that allows the user to type into. The Edit
window will only allow the user to enter up to the maximum number of characters for the
entry field. The user then selects Okay to insert the text into the input field. The text will be
truncated to the nearest multi-byte character to the maximum allowed number of bytes at the
point it is inserted into the entry field. The user may Cancel or even Search and Substitute a
string with another. Therefore, the user will NOT be able to enter more byte or characters
into the entry field using this method.

Issue 10 12
VPRM Internationalisation Support Procedures - Troubleshooting Multi-byte Data Entry

Paste allows the user to cut or copy selected data from a field and repeatedly paste the data
into the same field or another. It is possible to enter more than the maximum number of
bytes into a field by entering multi-byte characters up to the maximum number of characters
allowed for the entry field. The Paste button is disabled if the number of characters in the
copy buffer is greater than the maximum number of characters allowed for that entry field.
Conclusion
The user must be aware that such truncation may take place when the data is copied to the data
entry field.

Toolbar Edit Functions

Method
Use the toolbar function icons to perform the edit functions.
Edit has the same behaviour as Command Edit Menu.
Paste is disabled if the paste buffer contains more characters than is allowed for the entry
field. The user is able to paste the contents of the buffer if its character content is less than
the maximum number of characters allowed for the entry field. The user can repeatedly
paste the buffer contents into an entry field up to the maximum number of characters
allowed. If the buffer contains fewer characters than the maximum limit for the intended data
entry field yet the buffer contains more bytes than the maximum limit then the paste button
will be active. However, if the paste button is used the data will be truncated to the nearest
character up to the maximum number of bytes permitted for the data entry field.
Conclusion
Although this method is perfectly safe for entering multi-byte data, the user must be aware that
character truncation may take place when the data is pasted in to the data entry field.

Cut from 3rd Party Applications + Paste

Method
Open an application that supports and contains multi-byte data. Select and copy the data to the
paste buffer. Attempt to paste the contents of the paste buffer into a data entry field.
The paste button is disabled on the Command Edit Menu if the number of characters is
greater than the maximum number of characters allowed for the entry field. f the paste buffer
contains less than the maximum limit of characters allowed, then the paste option from the
Command Menu will allow the user to paste the content. However, the field is immediately
cleared if it contains more bytes than is allowed.
Does not allow user to paste, using Ctrl+V, the buffer into the entry field if there is more
bytes than the maximum permitted number of characters allowed for the entry field.
Subsequent Ctrl+V will attempt to paste the characters from the buffer into the data entry
field.

Cut and Paste via Keyboard between VPRM Entry Fields

Method
Highlight the text in a data entry field that is to be copied. Use Ctrl+C to copy the highlighted text.
Move to the data entry field where the copied text is to be pasted. Use Ctrl+V to paste the text into
the field. Every subsequent Ctrl+V will attempt to paste the buffer content into the selected data
entry field. The user is not allowed to paste the buffer into the data entry field if the buffer content is
more than the maximum number of characters allowed for the entry field. If the paste buffer contains
less than the maximum limit of characters allowed the field is immediately cleared if it contains more
bytes than is allowed.

Issue 10 13
VPRM Internationalisation Support Procedures - Troubleshooting Multi-byte Data Entry

Imported Data (Excel & Text Files)

Update cells within an Exported Microsoft Excel Spreadsheet or a Text file with multi-byte data that
is both greater in bytes but not character length and greater in character length only, then attempt to
import.
General
A failed Excel of Text Import does NOT update the database if the content for a field is greater than
the maximum number permitted for that field in both characters and bytes.

Issue 10 14
VPRM Internationalisation Support Procedures - Printing Multi-byte Data

Printing Multi-byte Data

To configure VPRM to allow users to generate Reports containing multi-byte characters please see
Internationalisation (I18N) configuration section in the AVEVA VPRM Install Guide.

Issue 10 15
VPRM Internationalisation Support Procedures - Configuring a PC for I18N

Configuring a PC for I18N

This section is aimed at providing guidance to users who wish to configure their PC for I18N
support.

Your Locale
This setting determines the I18N support for applications that makes use of the System Locale. This
setting is more akin to the Territory setting for Oracle NLS. In the General tab under Regional
Options the user can select a Windows supported Locale e.g. Spanish (Spain) or Spanish
(Mexico). By default, the following Localisation settings are set to reflect the new Locale:-
Numeric Format
Currencies
Dates
Time
Sort (if an option exists)
These setting are available to applications running on the PC to allow them to reflect the Regional
settings. The user is only able to choose from the installed Locales that are supported by the
Language Setting for the System, see below.
Overriding the Locale Settings
The user may override the Locale Settings of a particular Locale simply by going to the appropriate
tab in Regional Options and setting the parameter manually.

Language Setting for System

Install new Language
If the user wishes to support a different Locale to the available list, under Your Locale, they must
configure the Language Setting for the System. The Language Setting for the System refers to the
actual languages that can be supported by the Code Page mapping installed. The Code Page
mappings determine the character sets that are supported on the system. Therefore, if Your Locale
was set to Spanish (Spain) and Japanese support was also required the user would have to select
Japanese from the Language Setting for System, which would install all the support required for
Japanese (including an Input Method Editor). The user will need to re-boot the PC before the new
Language is supported. The new language will now appear on the Your Locale.
Default Setting
The user is able to set the Default Language Setting for the System. This is the setting used when
an Application is activated. The I18N application support is determined by the default setting of the
Language Setting for System in Regional Options.

Issue 10 16
VPRM Internationalisation Support Procedures - Native Language Support

Native Language Support

It is possible to display data-entry screens in different languages and terminology, to suit a users
native language, based on their VPRM User Locale. Please see the VPRM Operations Guide,
section Customisation, Customisation of Screen Text.

Issue 10 17
VPRM Internationalisation Support Appendices - Troubleshooting a VPRM Multi-lingual Environment

Appendices

Troubleshooting a VPRM Multi-lingual Environment

The user must be aware of the main factors influencing the ability to support a multi-lingual
environment within a VPRM. Please refer to the Installation Guide and take extra note of the options
to support multi-byte characters, in the Internationalisation (I18N) configuration section for
recommendation on which Character Set to use.

Objective
The objective here is to identify all of the components that make up and affect the I18N support for
VPRM from a user perspective. It is hoped that this information will assist the user to make
reasoned decisions about what must be done and what are the overriding factors when trouble-
shooting or configuring a VPRM environment for multilingual support.

Intended Audience
The user must have followed the recommended guidelines for platform support of VPRM. The user
who is performing the configuration of VPRM must be familiar with the set up procedure for
Regional Options within Microsoft Windows.

Exceptions & Restrictions

The Web server must be configured, as default, to support the character set for the given language
to provide unrestricted language support.

Support Issues
Microsoft Windows
Microsoft Windows uses UCS2 for its underlying architecture, which is a Unicode Character Set
consisting of 2 bytes. This has the effect that every character consists of 2 bytes, which means that
the ANSI character subset contains a leading NULL character. Microsoft Windows does NOT
directly support the UTF-8 character set. However, certain applications are capable of supporting
encoded character set documents, even UTF-8.
Oracle
Oracle Database does NOT support UCS2 character set for its database encoding. The preferred
Unicode compliant character set is UTF-8. UTF-8 is a variable multi-byte character set [Universal
Transformation Format 8 bit] that only utilises the required number of bytes necessary to store a
character. It uses the leading bits of the first byte to indicate how many bytes make up the character
code. The transformation converts the byte[s] to USC2. One of the key features is that the ASCII-7
character set maps directly to UTF-8.

Issue 10 18
VPRM Internationalisation Support Appendices - Troubleshooting a VPRM Multi-lingual Environment

I18N Platform Configuration Guide

Below is a list of identified domains that affect the behaviour and the ability to support different
Locales within the VPRM environment. The components denoted with a key indicate the following
affected functionality;
Key Description
[1] Data Import via OOXML (i.e. Excel/Word).
[2] Ability to support the full UNICODE Character set.
[3] Ability to support a given Language Character set.
[4] NLS support features.
[5] UTF-8 character support.

Database Server [3]

Database Character Set [3] determines the encoding of the characters stored in the database and
hence the Languages which can be supported. In order to support a true multi-bytelingual
character environment the UTF-8 (or, for Oracle 11g, AL32UTF8) character set is used.
NLS_LANG
PC Hardware
Database Software
Internet Application Server iAS] [1][4][5]
Definition:
An application server is a server program in a computer in a distributed network
that provides the business logic for an application program. The application server is
frequently viewed as part of a three-tier application, consisting of a graphical user
interface [GUI] server, an application [business logic] server, and a database and
transaction server.

Servlet Configuration [1][4] Servlet technology is used primarily to allow several Oracle
environments to exist on a common AS Server. This allows a user of a particular Locale to
connect via a Servlet of the same Locale.
AS Software
VPRM Application
Text IO [5] the Internet Explorer Encoding influences the character set encoding of the
saved text files. As part of the I18N changes the encoding of the Internet Explorer has been
forced to UTF-8. To ensure no data corruption occurs when dealing with text files, interfacing
with VPRM, it is important that applications used to modify the data have the ability to
support UTF-8.
VPRM User [3][4]
Client [3] the Language support of the client restricts the users ability to enter characters.
The default Locale of the client will not affect the regional behaviour of VPRM beyond this,
however the user must be aware that this setting may affect the behaviour of other
applications that interface with VPRM.
User Profile [4] each valid VPRM user has a preferred Locale that influences the behaviour
of VPRM itself. Once a user has successfully entered a VPRM Module, the behaviour of the
I18N sensitive data is affected, by the users Locale NLS setting.

Issue 10 19
VPRM Internationalisation Support Appendices - Troubleshooting a VPRM Multi-lingual Environment

Client [2]
PC Hardware [2] the I18N support of the hardware is determined by the I18N support
capabilities of the Windows Operating System and the keyboard layout.
Internet Browser deployed on the client is encoded as UTF-8 when connection to VPRM
is established. The encoding is specified in the configuration of VPRM in the middle tier and
is set as UTF-8 in the installation.
PC Hardware [1][2]
Microsoft Windows Operating System [1][2] provides the user with the ability to configure
their PC to support different Locales via the Regional Options.
Keyboard
Microsoft Windows Operating System [1][2][3]
The Mircosoft Windows platform used must support Unicode. For information about Unicode version
2.0, please visit the following Web site http://www.unicode.org/
Code Page [3] determines the keyboard character mappings with the operating system and
the Applications. Keyboard mappings differ to support different languages.
IME[3] - is simply an application that extends the keyboard capability via a phonetic dictionary
to allow support for languages that use ideographs.
Regional Options [1][3][4] determines the regional behaviour of applications that are
sensitive to these settings.
Font Support [2][3] is provided by Microsoft or a third party font provider. There must be,
installed on MS Windows a font type that supports the Language Setting of Regional
Options. Applications make use of these fonts to display the language script correctly within
the applications.
Servlet Configuration [1]
NLS_LANG [1][4] is set up to support the preferred Locale of a VPRM user. There should
exist a Servlet to support each different type of VPRM user Locale, which by default will be
set with a UTF-8 character set. A Servlet will also exist to support the character set content
of a MS Excel interface, which should correspond to the default Language Setting in
Regional Options.
NLS Override Parameters [4] by default a number of NLS features localises data, which
has not been made I18N aware in VPRM. Therefore, these NLS features will be overridden
within the Servlet.
NLS_LANG [1]
[Oracle Extract] The NLS_LANG parameter has three components--language, territory, and charset--
in the form:
NLS_LANG = language_territory.charset
Each component controls the operation of a subset of I18N Support features.
language Specifies conventions such as the language used for Oracle messages, day names, and
month names. Each supported language has a unique name--for example, American
English, French, or German. The language argument specifies default values for the
territory and character set arguments, so either (or both) territory or charset can be omitted.
If language is not specified, the value defaults to American English.
Territory Specifies conventions such as the default calendar, collation, date, monetary, and
numeric formats. Each supported territory has a unique name; for example, America,
France, or Canada.

Issue 10 20
VPRM Internationalisation Support Appendices - Troubleshooting a VPRM Multi-lingual Environment

If territory is not specified, the value defaults to America.

charset Specifies the character set used by the client application (normally that of the user's
terminal). Each supported character set has a unique acronym, for example, US7ASCII,
WE8ISO8859P1, WE8DEC, WE8EBCDIC500, or JA16EUC. Each language has a default
character set associated with it. Default values for the languages available on your system
are listed in your operating system installation guide or administrator's guide.
Oracle Internet Directory requires all data to be stored in UTF-8.

Microsoft Windows Regional Options [1][2]

Configuration of Microsoft Windows Regional Options must be compatible with VPRM
configuration and checked to ensure support for the required Locale. See Microsoft Windows
documentation.
Code Page [3]
Definition:
This is a means of providing support for character sets and keyboard layouts for
different countries. A code page is a table that relates the binary character codes
used by a program to keys on the keyboard or to characters on the display.
Keyboard [3] must correspond to the Code Page mapping used. Microsoft provides a
Visual Keyboard application that will allows users to work from a native keyboard layout for
the Locale. Hence, the user will have virtual keyboard support for the language character
set without the need for additional hardware.
Microsoft Office [2]
Any templates used within Microsoft Office must be Saved As Word document (*.docx) not (*.doc)
and Microsoft Excel Workbook (*.xlsx) not (*.xls) for Word and Excel respectively.
Excel [2][4] the date format used is the Short Date Format specified in Regional Options.
Formatting dates in this way allows them to always use the localised date format of the PC.
Word [2] must be supported by a character set font for the given language. By default,
AVEVA Solutions Ltd recommends the use of Arial Unicode MS.
Internet Browser
Encoding [5] will be set, as default in the installation of the VPRM middle tier configuration,
to UTF-8 on the client browser session.
URL [4][1] - determines which Servlet the user is directed to for a particular Browser Session.

Issue 10 21
VPRM Internationalisation Support Appendices - Troubleshooting a VPRM Multi-lingual Environment

Rules for Multilingual Support

NLS Support [Dates, Sorts, Numeric etc.]
1. The Servlet that the user is redirected to, at the point of entering a Module, MUST support the
User Profile Locale.
2. Within <VPRM Home>\DAT\VPRM.ini file the following parameter must be set to the setting of
the Web Server Windows Regional Options;
a. DECIMAL_SYMBOL
b. SHORT_DATE_FMT
Full Language Character Set Support
1. Database must be created with a Character set that can support the Language[s].
2. Web Server Regional Setting default Locale must support the language character set.
3. There MUST exist a Servlet that supports the Language Character Set of the data content for
Importing Excel spreadsheets into VPRM. The MS Excel NLS configuration parameter is set
during Servlet re-direction on Excel Interface Imports.
Multi-byte Reports
1. Reports must be generated in a UTF-8 Servlet environment.
2. A font aliasing file must exist in :-
<ORACLE Home>\TOOLS\COMMON
that supports the language character set.
3. An Arial MS Unicode font must be installed on the AS Server in order to support the default
character set for reports.
Distributed Computing Environment
It is recommended that computer names in a multilingual environment only use US-ASCII7
character set to allow down-level compatibility and to avoid a computer setting dependency, see
Environment Restrictions.

Issue 10 22