Internationalization of the WebLIS system

Abstract

WebLIS is a CDS/ISIS based Library Integrated System for WWW environment that is distributed free-of-charge by UNESCO since mid of the year 2004. The original language version of the WebLIS system is English and therefore its users from not English speaking countries will need to prepare own language versions of the system. This process is not as easy as preparing a new language versions of CDS/ISIS itself, because WebLIS does not use separate system databases with language dependant texts.

The paper describes various categories of user interface files of the WebLIS system (static HTML files, system definition files, HTML output templates, formats generating output data from various databases as well as formats and tables used for input data validation) and modification of these files required for WebLIS internationalization. Detailed instructions were provided on preparation of a single language version of the WebLIS system where another language replaces English as well as on preparation of a multilingual version of WebLIS.

1. Introduction

WebLIS is a CDS/ISIS based Library Integrated System for WWW environment that is distributed free-of-charge by UNESCO since mid of the year 2004. These are main modules of the WebLIS system:

• the data entry module which allows to maintain a library catalogue comprising records that describe various types of bibliographical materials – monographs (2 levels), articles (3 levels), serials as well as miscellaneous materials;
• the search module which is an OPAC (on-line public access catalogue) module that provides three modes of searching the catalogue – simple retrieval, advanced retrieval and thesaurus based retrieval;
• the loan module that comprises basic procedures dealing with loan system management and that is fully integrated with the library catalogue.

All data of the WebLIS system are stored in CDS/ISIS databases and all these modules are accessed from an Internet browser (fourth module of WebLIS is called ISIS-Statistica and it is a stand-alone Windows application for statistical analysis of WebLIS data). WebLIS has been developed by the software house ICIE and it uses as a server the WWW-ISIS program prepared by this company (this CGI program uses ISIS-DLL to process CDS/ISIS databases). In order to avoid confusion with the WWWISIS program developed by BIREME in this paper we will call the WWW-ISIS program ISIS3W (this is a name of executable file of the WWW-ISIS program).

In contrast to other members of the CDS/ISIS software family, WebLIS has not been designed as a multilingual system and therefore language dependant elements of its user interface have not been stored in separate databases. Original WebLIS user interface is in English and it has been split among numerous files residing in several directories. These files contain data in various formats – some of them are text files, others are HTML files or templates and majority of them are print formats that output CDS/ISIS data with appropriate HTML tags. All these factors make internationalization of the WebLIS system a much more complicated task than in case of other programs belonging to CDS/ISIS family. Translation of the WebLIS system interface requires not only good knowledge of the CDS/ISIS system and HTML format, but also basic knowledge on functionality and organization of the WebLIS system.

The aim of this paper is to facilitate work of these system administrators who will translate the user interface of WebLIS into their national languages and of these who will prepare multilingual versions of the WebLIS system. Because many administrators may already have experience in applying the WWWISIS program of BIREME for designing CDS/ISIS applications for Internet users, when discussing ISIS3W applications we will sometimes refer in this paper to similar design rules used in WWWISIS applications.

2. User interface files of the WebLIS system

Each of main WebLIS modules is a ISIS3W application that process one or several CDS/ISIS databases. As in WWWISIS applications the main user interface file is a HTML file that contains some active elements (coded either as links or as forms) that call the server program – in our case the ISIS3W program. Each of these server calls contains several parameters. Some parameters are obligatory and one of these parameters is the LANG parameter that specifies a language code. ISIS3W uses this code to return data in the specified language, but unfortunately it applies this solution in a very selective way.

Like in case of WWWISIS applications the server program itself and main files that control its behavior reside in the cgi-bin directory on the server computer and the interface files reside in the WWW root directory of this machine. The WebLIS system installation program creates two subdirectories in this root directory:
db - this subdirectory stories WebLISdatabases,
libcat - this subdirectory stories various definition files of the WebLIS system.
The cgi-bin directory contains a special file that controls behavior of the ISIS3W program and this configuration file is called isis3w.exe.cfg.

Below we will describe these files that contain language dependant information and should be modified in order to translate the user interface of WebLIS into another language.

2.1. Static HTML files

Screens of all main modules of the WebLIS system are divided into two vertical frames. The left frame is a table of contents (TOC) frame that enables execution of various actions available in a given module and the right frame is a destination frame where action results are displayed. Files defining these screens (main user interface files) and TOC's are static HTML files that are stored in the libcat directory and have the following names:

Main user interface files contain English texts in NOFRAME sections and these texts are displayed only by browsers which do not support frames (all modern browsers have this capability). Another static HTML file that contains language dependant texts in the NOFRAME section only is called kwocinlib.html. This file defines the main screen used for thesaurus supported retrieval that is available in the search module.

2.2. System definition files

The ISIS3W program employs three types of the system definition files:

• browse definition files that specify first parts of pages containing records output sequentially (results of browsing),
• search definition files that define contents of forms used for retrieval,
• data entry definition files that define worksheets used for data entry.

All these definition files reside in the libcat directory and names of definition files used for a given purpose are specified in the configuration file isis3w.exe.cfg. However, these names are not treated by the ISIS3W program in the same way. Only the name of a data entry definition file is treated as a full name, while names of browse and search definition files are suffixed with an extension equal to the language code provided as a parameter of the ISIS3W program call. This causes that an ISIS3W application may use several language dependant versions of browse and search definition files and only one data entry definition file.

For a reason explained in the next section the WebLIS system uses two language codes for English – ENG and ELN. This is why it employs two browse definition files and two search definition files which contain English texts. These are the names of system definition files used in the English version of WebLIS:

2.3. HTML output templates

HTML output templates are text files used by ISIS3W as templates when this program generates HTML documents in response to particular requests. An HTML template is a text file that contains numbered lines and each of them is an output line template in which the %s strings mark places where output data will be inserted. The ISIS3W program uses the HTML output templates that have the following names:

All these files are language dependant – ISIS3W employs the language code provided as one of obligatory parameters in each call of this program and it uses an appropriate template that resides in the libcat\htp\LNG directory, where LNG is a language code. For instance, in an ISIS3W application that uses ENG as the code of English the libcat\htp\eng\result.htp file will be used a template to output search results (provided that a search request contained the parameter lang=eng).

This solution enables that an ISIS3W application can use separate HTML templates to output data in different languages. However, an application cannot use different templates to output data of the same type in the various parts of this application, for instance it cannot use more than one search template in a given language. Designers of the WebLIS system wanted to apply other HTML templates in the loan module than in two other main modules of this system, in spite that English is the only language used in all these modules. To overcome the specified limitation of the ISIS3W program they had employed a trick. This is why two different language codes are used for English within WebLIS:
ENG is the code of English applied in the data entry and search modules,
ELN is the code of English applied in the loan module.
In consequence English version of WebLIS employs two browse definition files and two search definition files. This also causes that the English HTML templates reside in two subdirectories of the libcat directory: htp\eng and htp\eln.

Some of the HTML templates use JavaScript functions containing language dependant texts. These functions are stored in the following files:

2.4. CDS/ISIS formats and field validation tables

These are four main databases of the WebLIS system:

The library catalogue database LIBCAT is used in all modules and the three latter databases are used only in the loan module. WebLIS allows lending only catalogue items that have been registered in the ITEM database. Each WebLIS patron belong to a privilege class that defines his/hers/its (both individuals and institutions can be patrons) rights in such terms as types of materials that can be lent and default loan periods for given materials, maximum number of loans etc. All information on patrons is stored in the PATRON database together with material type and privilege class definitions. LOAN is the main database of the loan module. This database stores information on various transactions and each transaction includes data of both item and patron.

Apart of these main databases the WebLIS system uses the following auxiliary databases:

Both main and auxiliary databases of the WebLIS system are CDS/ISIS databases. All these databases reside in separate subdirectories of the db\libcat directory. The only exception is the CODES database that resides in the VALID database subdirectory (db\libcat\valid). Paths to particular databases used by WebLIS are stored in the dbn.def file that is located the libcat directory (this file plays in ISIS3W applications a similar role as CIP files used in WWWISIS applications).

ISIS3W applications define many texts output by the server as literals in CDS/ISIS print formats, exactly in the same way as is done in WWWISIS applications. However, not all these formats are used for data presentation. In ISIS3W applications special formats may be applied during data entry. These are:

• browse formats that output lists of already registered values during data entry (result of using the Browse buttons defined in data entry worksheets); examples of such lists are both authority files and validation tables mentioned above,
• validation formats that play a similar role as record validation formats used in WinISIS, but in ISIS3W these format define both errors and warnings (WinISIS validation formats define just errors),
• formats used to copy data from an existing record to a new one (so called copy formats),
• formats executed before records are created (so called insert formats),
• formats executed before records are modified (so called update formats),
• formats executed before records are deleted (so called delete formats).

Field validation table is another tool used for data validation in ISIS3W applications. This tool plays a similar role as field validation formats used in WinISIS. Such a table validates specified fields of the current record against the inverted file contents and outputs either errors or warnings, such as Field XXX contains value YYY that already exists in the database. Field validation tables are text files that are stored in the subdirectories containing database files.

Table 1

Database	Data presentation formats	Browse formats	Validation formats and tables	Copy, insert, update and delete formats
AUTH	11	12	6
ITEM	8	3	2	2
LIBCAT	15	11	10
LOAN	14		7	8
PATRON	9	8	8	1
THES	5
VALID	7	6	6
Totally	69	40	39	11
Grand total				159

Many formats and field validation tables used in the WebLIS system contain English texts output by the server or other language dependant data. Detailed lists of these files are provided in Annex 1. Table 1 gives total number of such files that reside in the subdirectories of particular databases.

3. Preparation of new language versions of the WebLIS system

System administrators preparing new language versions of the WebLIS system may want to develop:

• either a single language version where another language replaces English as the only language of conversation
• or a multilingual version which enables switching among various languages of conversation (one of them can be English).

3.1. Replacing English version with a new language version

Although many files that define user interface of WebLIS have names mnemonic in English, there is no need to change these names in order to make them mnemonic in a new language. The work of a system administrator who will translate the user interface of WebLIS into his/hers national language can be further simplified if he/she decides not to change language codes employed in the original version of the WebLIS system. It uses ENG and ELN as two codes of English, but these codes can be used for another language that will replace English as the only language of conversation.

Below we assume that:

• all user interface files retain their names,
• ENG and ELN are retained as codes of the new language of conversation.

3.1.1. Static HTML files

Four static HTML files, called de.html, index.html, kwocinlib.html and loan.html, define main screens of WebLIS modules that are divided into two vertical frames. These files contain in NOFRAME sections English texts that are displayed only by browsers which do not support frames. As all modern browsers have this capability, these English texts do not need translation. However, this not necessarily means that then these files can be not taken into account during the WebLIS system internationalization. As HTML files generated by WebLIS static HTML files contain character set specifications in the HEAD section of these documents. The original specification is:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
If the new language requires application of another character set, in all static HTML files iso-8859-2 should be replaced by an appropriate character set specification.

Three other static HTML files are called detoc.html, toc.html and loantoc.html. These files output tables of contents in the data entry, search and loan modules respectively. All English texts output by these files should be translated into a new language. Note that in the detoc.html and loantoc.html files some English texts are captions of buttons as Add new in the case of line:
<input TYPE="Submit"VALUE="Add new">
or form options in drop down list as Journal title in the case of line:
<option VALUE="JOU">Journal title
Translate only these English texts that are issued by the server. Do not change English text and abbreviations that are not output, such as Submit or JOU in these two lines.

3.1.2. System definition files

Because ENG and ELN have been retained as two codes of a new language replacing English, the extensions of system definition files do not change. Therefore the definition files will have exactly the same names in a new language version as in English version, i.e. browse.def.eng and browse.def.eln are browse definition files, database.def.eng and database.def.eln are search definition files and entry.def is the data entry definition file.

All these files contain texts that should be translated into a new language. Structure of the browse and search definition files is similar. In both files each definition starts from a title line followed by lines defining options of some drop down lists. In a search form definition, further lines define retrieval criteria. Figure 1 shows exemplary browse and search definitions where English texts to be translated are distinguished in red.

a)	b)
[elibx; LIBX; Select material from LibCat] [prefix; IX=*@ESALLE; Rec.Id] [prefix; T:*@ESALLE; Title] [prefix; S:*@ESALLE; Serial Title] [prefix; AX:*@ESALLE; Author] [prefix; CN=*@ESALLE; Call No] [prefix; MX:*@ESALLE; MFN] [format; @ESALLE; Select current] "x", "x", "x", "1"	[libs; LIB; Library Catalogue] [sort; @SCHR; chronologically] [sort; @SAUT; by Author] [sort; @STIT; by Title] [format; @ESALL; selection list] [format; @EMALL; short format] [format; @EFALL; full format] "Keywords from record","keywords_record","K=","1"; "restricted_terms", "keywords_record"

Fig.1. Exemplary browse (a) and search (b) definitions.

Figure 1.a shows definition of the ELIBX header used for browsing the LIBCAT database during data entry (this definition is stored in the browse.def.eng file). The text Select material from LibCat is displayed as a header of this page. The drop down list called prefix has 6 positions: Rec. id, Title, Serial title, Author, Call no and MFN. This list enables selection of a record element used as navigation criterion in the list of library catalogue records. The next drop down list is called format, but this list is not displayed because it contains just a single option (this is why the text Select current does not need translation). WebLIS uses the ESALLE format for showing library records in this page, because this is the only format defined in the format list. The way how all these elements appear on HTML pages is defined in two browse.htp templates (see the next section) stored in the libcat\htp\eng and libcat\htp\eln directory (the loan module uses the libcat\htp\eln\browse.htp template and two others modules the libcat\htp\eng\browse.htp template).

Figure 1.b shows definition of the LIBS form used by the search module for simple retrieval (this definition is stored in the database.def.eng file). The text Library catalogue is displayed in the very beginning of this page. The drop down list called sort enables selection of a record element used for sorting the retrieved records. This list has 3 positions: chronologically, by Author and by Title. The drop down list of presentation formats is called format and it has 3 positions. The ESALL format is used to show records on a selection list, EMALL serves as a short presentation format and EFALL is a full presentation format. The only retrieval criterion is called Keywords from record. The way how all these elements appear on the HTML pages containing retrieval forms is defined in two search.htp templates that are stored in the libcat\htp\eng and libcat\htp\eln directory (the loan module uses the libcat\htp\eln\search.htp template and two others modules the libcat\htp\eng\search.htp template).

A retrieval criteria definition stored in search definition files specify also the prefix preceding data in the inverted file and a numeric code that informs which HTML elements are used to present this criterion on a search form. Keywords used as the only retrieval criterion in the simple search form shown on Fig. 1.b are preceded with the K= prefix in the inverted file of the LIBCAT database and an input field followed by a List button is used for entering the keywords on this search form (this type of input is coded as 1). Other search forms present some retrieval criteria as lists of checkboxes (this input is coded as 11). For instance, the LIBA form used for advanced retrieval contains the line:
"Collection", "rtype", "T=", "11", "5", "0", "8", "MON","Books", "ANA","Papers", "SER","Serials", "MIS","Miscellaneous"
(again English texts to be translated are distinguished in red). This line defines the Collection criterion in which the user can check 4 boxes: Books, Papers, Serials and Miscellaneous. Checking these boxes causes that phrases T=MON, T=ANA, T=SER and T=MIS are respectively included into a search expression.

Structure of data entry definition file is more complex than that of two other types of system definition files. This file defines data entry worksheets using a notation that resembles the XML format, e.g.:

<isis_worksheet>
name = PRV;
title = Privilege class
dbn = PATRON
. . .
<isis_page>
. . .
<isis_field>
. . . description = Class name; tag = 210; . . .
</isis_field>
. . .
</isis_page>
. . .
</isis_worksheet>

The way how all these elements appear on the HTML pages containing data entry worksheets is defined in two e_forms.htp templates that are stored in the libcat\htp\eng and libcat\htp\eln directory (the loan module uses the libcat\htp\eln\e_forms.htp template and two others modules the libcat\htp\eng\e_forms.htp template).

In ISIS3W - as in CDS/ISIS for DOS - data entry worksheets are divided into pages. Each page contains several field definitions and a field definition can contain definitions of several subfields. In each worksheet definition the only language dependant elements are:

• the worksheet title (defined together with the worksheet name in the header that precedes definition of the first field),
• values of the description parameters belonging to field / subfield definitions.

Translation of the entry.def file used by WebLIS is a time consuming job, because this system uses 26 data entry worksheets and some of them consist of several pages (the list of all worksheets to be translated is provided in Annex 2). This work must be done in a precise way, because any unintentional modification of other parameters in field definitions may change worksheet appearance or even may cause that WebLIS will not able to use the data entry definition file any more.

As it was explained in the subchapter 2.3, HTML output templates are text files used by ISIS3W as templates when this program generates HTML files in response to particular requests. These templates are language dependant files – ISIS3W employs the language code provided as one of obligatory parameters in each call of this program and uses an appropriate template that resides in the libcat\htp\LNG directory, where LNG is a language code.

These are the names of HTML templates containing English texts that should be translated into a new language of conversation:

libcat\htp\eng\browse.htp	libcat\htp\eln\browse.htp
libcat\htp\eng\e_forms.htp	libcat\htp\eln\e_forms.htp
libcat\htp\eng\e_browse.htp	libcat\htp\eln\e_browse.htp
libcat\htp\eng\error.htp	libcat\htp\eln\error.htp
libcat\htp\eng\result.htp	libcat\htp\eln\result.htp
libcat\htp\eng\search.htp	libcat\htp\eln\search.htp
libcat\htp\eng\thes.htp	libcat\htp\eln\thes.htp
libcat\htp\eng\view.htp	libcat\htp\eln\view.htp

As it was mentioned before, each HTML template is a text file and each of line of this file is an output line template in which the %s strings mark places where output data will be inserted. The line templates start from the # sign followed by a line number. It is crucial that these numbers remain intact during translation, because ISIS3W uses them to identify places where it will insert particular output data.

As a rule each line template is stored as a single line, but a special notation allows for continuation lines. A backslash sign ending a line shows that the next line is a continuation line. This convention enables splitting a single line template into several lines. For example, the 10th line template in the file libcat\htp\eng\browse.htp has been split into 3 lines:
#10 <H2><CENTER> %s %s </CENTER></H2><FONT SIZE=2> <OL COMPACT TYPE=i>Instructions:\
<LI>To move to a specific position in the list enter the appropriate root of the term in the box.\
<LI>Click on the <U>underlined text</U> to view the record.</OL>

Because HTML templates are used to generate HTML documents, many of templates contain a character set specification that will be output in the HEAD section of these documents. The original specification is:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
If the new language requires application of another character set, in all HTML templates iso-8859-2 should be replaced by an appropriate character set specification.

Some of the HTML templates use JavaScript functions that output English texts. These functions are stored in the files libcat\htp\eng\func_browse.js, libcat\htp\eng\func_result.js, libcat\htp\eng\functions.js and libcat\htp\eln\calendar.js. The only English text output by the three first files is the question "Are you sure you want to delete the record ?". The last file stores specification of a JavaScript calendar component. This component contains among others the following data in English, French, German and Spanish:
names of months (stored as monthArray),
names of weekdays (stored as weekdayList)
abbreviated names of weekdays (stored as weekdayArray)
and it uses the language that has been chosen as the current language in the default Internet browser. As we have assumed that a new language replaces English we have to translate into this language all English names and abbreviations. Moreover, we have to force application of English as the current language of this component, because Internet browsers will use another language. In order to achieve this the line
selectedLanguage = navigator.language;
should be replaced by the line
selectedLanguage = 'English';

3.1.4. CDS/ISIS formats and field validation tables

The WebLIS system uses 159 CDS/ISIS formats and special validation tables that contain English texts output by the server or other language dependant data (see Annex 1 for detailed lists of these files). The most important of language dependant data is a language code. This code is an obligatory parameter in each ISIS3W call and many formats employed in the WebLIS system contain literals that output HTML elements used to call the ISIS3W server.

Some of formats listed in Annex 1 do not output any English text, but they merely specify either ENG or ELN as a language code used as one of parameters in ISIS3W calls. As these language codes remain unchanged, in our case these formats do not need any modification and the total number of formats and tables to be changed decreases to 126. Table 2 shows total numbers of such files that reside in the subdirectories of particular databases.

Table 2

Database	Data presentation formats	Browse formats	Validation formats and tables	Copy, insert, update and delete formats
AUTH	11	4	6
ITEM	8	3	2	2
LIBCAT	15	3	10
LOAN	14		7	7
PATRON	9	1	8	1
THES	2
VALID	7		6
Totally	66	11	39	10
Grand total				126

The names of CDS/ISIS formats and validation tables that require translation in this case are distinguished in the Annex 1 in bold. The most tedious work is translation of data presentation formats, because many of these formats contain numerous English texts output as headings, links and captions. As an example we show below the EFJOUE format stored in the AUTH database directory that is used for presenting journal titles for data entry (in all examples below texts to be translated are distinguished in red).

'<CENTER><H3>AUTHORITY FILE - journal title </H3></CENTER>',
'<HR>',
'<TABLE COLS=5 class="maincolor" ALIGN="CENTER" WIDTH=98%>',
'<TR><TD WIDTH=60%><TD WIDTH=10%><TD WIDTH=10%><TD WIDTH=10%><TD WIDTH=10%>',
'<TR><TD><TD>',
'<TD><A href="/cgi-bin/isis3w.exe?rec_id=',mfn,
'&de_worksheet=JOU&database=AUTH&search_type=ef_modify&lang=eng">Update</A>',
'<TD><A href="/cgi-bin/isis3w.exe?rec_id=',mfn,
'&de_worksheet=JOU&de_copy_init=ECJOU&database=AUTH&search_type=ef_copy&lang=eng"> Copy</A>',
'<TD><A href="/cgi-bin/isis3w.exe?rec_id=',mfn,
'&de_worksheet=JOU&database=AUTH&search_type=ef_delete&lang=eng" OnClick="return confirm_delete();">Delete</A>',
'</TABLE>'/
'<TABLE CELLPADDING=0>',
'<TR><TD VALIGN=TOP class="maincolor"><B><I>English title:</I></B></TD><TD>'v421'</TD></TR>',
'<TR><TD VALIGN=TOP class="maincolor"><B><I>French title:</I></B></TD><TD>'v422'</TD></TR>',
'<TR><TD VALIGN=TOP class="maincolor"><B><I>Spanish title:</I></B></TD><TD>'v423'</TD></TR>',
'<TR><TD VALIGN=TOP class="maincolor"><B><I>Other title:</I></B></TD><TD>'v424'</TD></TR>',
"<TR><TD VALIGN=TOP class='maincolor'><B><I>Call No: </I></B></TD><TD>"v22"</TD></TR>",
"<TR><TD VALIGN=TOP class='maincolor'><B><I>Hold.Lib.: </I></B></TD><TD>"v14"</TD></TR>",
'</TABLE>'

Translation of browse formats is not so difficult because these formats do not output so many English texts. As an example we show below the EB41E format stored in the AUTH database directory that shows original journal names during data entry.

'<TR><TD VALIGN=TOP><INPUT TYPE="RADIO" NAME="de_browse_name" VALUE="'v421,
"###413######"v424,'###417######'v27,'###27######'v27,'">',
'<TD>','<A href="/cgi-bin/isis3w.exe?rec_id=',mfn,
'&database=AUTH&search_type=link&lang=eng&format_name=EFJOU">',mhl,v421'</A>',
"ISSN "v27, ", Call No: "V22, ", Hold.Lib.: "D14,(V14+|; |),if p(v420) then '; Closed entry!' fi,
'</TR>'

Validation and delete formats output only errors and warnings that are texts marked with the ERR and WARN tags respectively. It is important that each error or warning is followed by the new line command. As an example we show below the EVITM format stored in the ITEM database directory that serves as validation format for items.

IF a(V861) THEN '<ERR>Please fill in Barcode<BR></ERR>'/ FI,
IF a(V866) THEN '<ERR>Please fill in Call number<BR></ERR>'/ FI,
IF a(V869) THEN '<ERR>Please fill in Title<BR></ERR>'/ FI,
IF a(V868) THEN '<ERR>Please fill in Type of material<BR></ERR>'/ FI,
IF v860:'SER' and a(V876) THEN '<ERR>Please fill in collation of the serial (vol., No.)<BR></ERR>'/ FI,

Field validation tables output only errors and warnings too, but these files are built in a special way. These tables play in ISIS3W a similar role as field validation formats used in WinISIS, because they validate specified fields of the current record against the inverted file contents.  Below is shown as an example the EVITM table stored in the ITEM database directory that serves as validation table for items.

tag=(if (not V860.1:'D') or V860*2.1<>'' then V860/ fi); select=0; vmode=AF; term=exist; dbn=libcat; pfx=IX=; msgpft=(|<ERR>Accession number: value <B><FONT COLOR="red">|V9999|</font></B> should exist in the catalogue or should start with "D"<BR></ERR>|/);

tag=(if (not V861.1:'D') or V861*2.1<>'' then V861/ fi); select=0; vmode=AF; term=missing; dbn=item; pfx=IC:; msgpft=(|<ERR>Barcode:value <B><FONT COLOR="red">|V9999|</font></B> already exists in the database<BR></ERR>|/);

tag=(V866/); select=0; vmode=AF; term=missing; dbn=item; pfx=CN:; msgpft=(|<WARN>Call number: value <B><FONT COLOR="red">|V9999|</font></B> already exists in the database<BR></WARN>|/);

tag=(V868/); select=0; vmode=AF; term=exist; dbn=patron; pfx=MT:; msgpft=(|<ERR>Type of material: value <B><FONT COLOR="red">|V9999|</font></B> is not defined as Type of material<BR></ERR>|/);

This table consists of four lines and each line specifies a particular condition. For instance, the 3rd line looks in the inverted file of database ITEM (dbn=ITEM) for values of the field 866 (tag=(v866/)) taken with the CN: prefixes (pfx=CN:) and if a such value exists the server outputs the warning (msgpft): Call number: value XXX already exists in the database. Note that an error or a warning is output if a given condition is not satisfied and therefore this line specifies the condition term=missing. For example, the condition specified in the 4th line requires that a given value exists in the inverted file (term=exist) – server outputs an error message if this condition is not satisfied and therefore this message says a particular value has not been defined.

Insert and update formats that need translation have been defined for the LOAN database only. These formats play in ISIS3W a similar role as begin and end codes used in date entry worksheets of WinISIS, because they are executed before records are created or modified and they define such actions as adding a new field, deleting exiting field or replacing its contents with new one. The only insert format that output English texts is the IALL format defined for the LOAN database. The first line of this format contains the following ADD directive:

'ADD <90>^d',V9950*6.4,V9950*3.2,V9950.2,'^a',if v820='L' then 'loan' else if v820='H' then 'hold' else 'starts waiting' fi fi,"^u"V9960,'</90>'#

(ADD directive is an equivalent of A command in the CISIS update language that is used in begin and end codes of WinISIS). This directive adds to the current record a new occurrence of the field 90 that stores history of loan transactions. This field has the general format:
^ddate^aaction^uuser
and therefore the system date (stored in the virtual field 9950 – ISIS2W provides as WWWISIS some important data in virtual fields) is stored as subfield D, the text loan, hold or starts waiting  - as subfield A and the user name (provided during login and stored in the virtual field 9960) – as subfield U. A new occurrence of the field 90 is added as well when the current record is modified and therefore all update formats that need translation contain a similar ADD directive.

3.2. Creating a multilingual version of the WebLIS system

Creating a multilingual version of the WebLIS system is a more complicated task than replacing its English version with a new language version. To simplify the discussion we will describe below creation of a bilingual version of WebLIS where the user can choose as a language of conversation either English or Spanish. Our task will be therefore creation of a new Spanish version and modification of the existing English version in such a way that it enables choosing Spanish as a language of conversation.

These are the language codes used in this bilingual version of WebLIS:

• ENG and ELN are retained as two codes of English,
• ESP (used in search and data entry modules) and EPR (used in the loan module) are two codes of Spanish.

3.2.1. Static HTML files

In order to create static HTML files in Spanish we will first copy static files in English, giving them names mnemonic in Spanish. Let us assume that we will create the following static HTML files:

Copy from	to	Contents
index.html	busca.html	main file of the search module
toc.html	buscind.html	table of contents (TOC) for the search module
kwocinlib.html	tesauro.html	main file for the thesaurus supported search
de.html	edit.html	main file of the data entry module
detoc.html	editind.html	table of contents (TOC) for the data entry module
loan.html	prest.html	main file of the loan module
loantoc.html	presind.html	table of contents (TOC) for the loan module

Then we will have to translate into Spanish all English texts output by the newly created HTML files. Some original files contain in the HEAD section of these HTML documents the following character set specification:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
This specification forces use of the Latin 2 set that contains Central European characters. In Spanish HTML files the Latin 1 character set should be used and therefore this specification should be replaced by
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

The original static HTML files contain numerous ISIS3W calls where either ENG or ELN are used as language codes (the LANG parameter). These codes of English have to be replced by appropriate codes of Spanish, i.e ENG should to be replaced by ESP and ELN by EPR. Many of these calls contain also the name of a data presentation format to be applied, such as ESALLE or ESCONE:
<input TYPE="HIDDEN" NAME="format_name" VALUE="@ESALLE">
<option VALUE="EO:*@ESCONE">Conference
These formats output English texts and therefore they should be replaced by formats outputting Spanish texts (see section 3.2.4 for the details).

Finally, we have to add in the Spanish files containing TOCs the links that will enable switching to an appropriate TOC file in English.

In the file	insert the link
buscind.html	<a href="toc.html"><i>English</i></a>
editind.html	<a href="detoc.html"><i>English</i></a>
presind.html	<a href="loantoc.html"><i>English</i></a>

The editind.html and presind.html files will require additionally modification of the data entry worksheet names (see the next section).

The only modification to be done in English interface files consists in adding to static HTML files the links that will enable switching to appropriate Spanish files.

In the file	insert the link
toc.html	<a href="buscind.html"><i>Español</i></a>
detoc.html	<a href="editind.html"><i>Español</i></a>
loantoc.html	<a href="presind.html"><i>Español</i></a>

3.2.2. System definition files

In order to create Spanish browse and search definition files we will first copy English browse and search definition files, giving them appropriate file extensions. We will create the following definition files:

Copy from	to	Contents
browse.def.eng	browse.def.esp	browse definitions for the search and data entry module
browse.def.eln	browse.def.epr	browse definitions for the loan module
database.def.eng	database.def.esp	search definitions for the search and data entry module
database def.eln	database.def.epr	search definitions for the loan module

Then we will have to translate into Spanish all English texts specified in the newly created definition files. These definition files contain also names of data presentation formats to be applied, such as ESALLE, ESALL, EMALL or EFAL. All these files are formats that output English texts which should be replaced by formats outputting Spanish texts (see section 3.2.4 for the details). Figure 2 shows exemplary browse and search definitions where all elements to be changed are distinguished in red and green.

a)	b)
[elibx; LIBX; Select material from LibCat] [prefix; IX=*@ESALLE; Rec.Id] [prefix; T:*@ESALLE; Title] [prefix; S:*@ESALLE; Serial Title] [prefix; AX:*@ESALLE; Author] [prefix; CN=*@ESALLE; Call No] [prefix; MX:*@ESALLE; MFN] [format; @ESALLE; Select current] "x", "x", "x", "1"	[libs; LIB; Library Catalogue] [sort; @SCHR; chronologically] [sort; @SAUT; by Author] [sort; @STIT; by Title] [format; @ESALL; selection list] [format; @EMALL; short format] [format; @EFALL; full format] "Keywords from record","keywords_record","K=","1"; "restricted_terms", "keywords_record"

Fig.2. Exemplary browse (a) and search (b) definitions.

As was explained in the subchapter 2.2, WebLIS as other ISIS3W applications may use several language dependant versions of browse and search definition files and only one data entry definition file. Therefore in a multilingual version of this system the data entry definition file entry.def will store definitions of data entry worksheets in all languages (in our case in both English and Spanish).

The original WebaLIS system uses 26 data entry worksheets and all these worksheets have unique names (these names – to some extend mnemonic in English – are listed in Annex 2). We have to prepare Spanish equivalents of these worksheets and to ensure that Spanish worksheets will be applied when the user selects Spanish as the current language of conversation. These new worksheets must have unique names too and in order to facilitate use of these worksheets they should be named in a systematic way. The most convenient would be a naming convention in which name of an original English worksheet will be a part of the translated worksheet name.

We will adapt the following naming convention for Spanish worksheets:
Spanish_name = SEnglish_name
According to this convention Spanish version of the original MON worksheet will be named SMON, the original ANAM worksheet will named SANAM etc. The most important advantage of such a naming convention is that it enables easy replacing names of English worksheets by names of their Spanish equivalents. The name of a worksheet is provided by the DE_WORKSHEET parameter that is obligatory in each ISIS3W call requesting a data entry operation. Note that while in CDS/ISIS formats these calls have usually forms of HTML links, such as:
'<A href="/cgi-bin/isis3w.exe?rec_id=',mfn,
'&database=',db,'&de_worksheet=JOU&search_type=ef_modify&lang=eng&de_back='v9940,'">Update</A>',
in the static HTML files ISIS3W is frequently called from a HTML form and then the name a data entry worksheet may be selected by the user from a drop down list, e.g.
<select NAME="de_worksheet"SIZE=1>
<option SELECTED VALUE="PAT">Individual
<option VALUE="PAC">Corporate
<option VALUE="PSE">Pseudo
</select>

Spanish equivalents of English data entry worksheets should not only output Spanish texts, but they also should apply Spanish formats for data validation and other purposes. Therefore we will discuss creation of Spanish data entry worksheets in detail in the section 3.2.4.

3.2.3. HTML output templates

In the WebLIS system HTML templates outputting English texts reside in the ENG and ELN subdirectories of the libcat\htp directory. As ESP and EPR are two language codes of Spanish, we should create the ESP and EPR subdirectories in this directory and copy there all the files residing in the appropriate subdirectories containing HTML templates in English:

Copy all the files from	to
libcat\htp\eng	libcat\htp\esp
libcat\htp\eln	libcat\htp\epr

Some problems cause in multilingual versions of WebLIS JavaScript functions used by the browse.htp, result.htp and e_browse.htp templates. These functions are stored in separate JS files residing in the HTML template subdirectories. However, while providing the LANG parameter in each ISIS3W ensures that this server applies a HTML output template stored in an appropriate subdirectory, this does not cause that these templates use JavaScript functions residing in the subdirectories shown by the LANG parameter.

The ISIS3W program recognizes a special htp_include directive used to include static files into HTML documents generated by this server and it applies the IncludeFilesPath parameter defined in the parameter file isis3w.exe.cfg as a path where it looks for the included files. In the WebLIS system majority of files containing Java scripts is inserted into HTML templates by the htp_include directives. This solution is correct in a single language version of the system, but in a multilingual version it causes that Java scripts in a wrong language will be applied. For instance, if the IncludeFilesPath parameter has its default value c:\xitami\webpages\Libcat\htp\eng, English scripts will be always used in our bilingual version of WebLIS, even in the Spanish HTML templates. Assigning c:\xitami\webpages\Libcat\htp\esp as value of the IncludeFilesPath parameter does not solve our problem, because then Spanish scripts will be used in English templates.

This problem can be solved only by applying another method of including JavaScript files into HTML templates. Such a template generates a HTML document and such a document can contain a SCRIPT tag specifying the name of a file storing JavaScript functions applied in it. This way we can apply JavaScript functions in a correct language in a multilingual version of WebLIS. In our bilingual version we have to replace in Spanish versions of the browse.htp, result.htp and e_browse.htp templates all the htp_include directives by appropriate SCRIPT tags that will refer to Spanish versions of JavaScript functions. For instance, the 5th line of the libcat\htp\esp\browse.htp file should be changed from
#5 <!-- htp_include: func_browse.js -->
to
#5 <SCRIPT LANGUAGE="JavaScript" SRC="../libcat/htp/esp/func_browse.js"></SCRIPT>
The file libcat\htp\esp\func_browse.js requires some additional changes apart from translation of the question Are you sure you want to delete the record ? Originally, this file was directly inserted into a HTML document and therefore it starts from the line <SCRIPT Language="JavaScript"> and ends with the line </SCRIPT>. These two lines have to be deleted now, because this declaration has been inserted directly into the HTML template.

The following files should be modified in this way: browse.htp, result.htp and e_browse.htp templates residing in both ESP and EPR subdirectories of the libcat\htp directory as well as the func_browse.js, func_result.js and functions.js files residing in the libcat\htp\esp directory. Note that the libcat\htp\spr\calendar.js file does not need such modification, because this file is not applied using a htp_include directive.

3.2.4. CDS/ISIS formats and field validation tables

While only 126 CDS/ISIS formats and special validation tables need to be translated into a new language replacing English, all 159 formats and tables listed in the Annex 1 require modification in our bilingual version of the WebLIS system. Because the system needs both English and Spanish formats and tables, we have to - as in case of data entry worksheets (see section 3.2.2) - prepare Spanish equivalents of original English files and to ensure that Spanish files will be applied when the user selects Spanish as the current language of conversation.

The Spanish formats and tables will reside in the same subdirectories as the English formats and tables and therefore their names must differ from the names of English files. The new files must have names unique in a given directory and in order to facilitate their use they should be named in a systematic way. Again, the most convenient would be a naming convention in which name of an original English file will be a part of the translated file name.

Designers of the WebLIS system have to a great extend facilitated selection of names for CDS/ISIS formats and tables in a new language, because the vast majority of English formats have names starting from E and E is the first letter in names of all English validation tables. As E has been chosen as the initial of English, we have to choose another letter as an initial for Spanish and S is an obvious choice. The following naming convention will be adapted for Spanish equivalents of English formats and tables: if the name of an original file starts from E, this initial letter will be replaced by S, otherwise the original name will be preceded with S. In this convention a Spanish equivalent of the EFCONE format will be named SFCONE and a Spanish equivalent of the B861 format will be called SB861.

The only exceptions are the EEOVER and EROVER formats stored in the LOAN database directory. In the WebLIS system overdue notices can be generated directly from the loan module or from the stand-alone LOAN program that performs batch processing of loan transactions (the WebLIS installation program stores the LOAN program in the directory db\libcat\loan-pgm). While the loan module enables to specify a name of the format used to generate an overdue notice, the LOAN program uses for this purpose the EEOVER and EROVER formats. This is why names of these two formats cannot be changed and without a special trick it is not possible to select a language in which overdue notices will be generated by this program. The trick consists in copying the EEOVER and EROVER formats into two special directories, named for instance over-eng and over-esp, and translating into Spanish the formats stored in the over-esp directory. This way we have two sets of formats having the same names and we can copy to the db\libcat\loan directory appropriate formats just before running the LOAN program.

Two other formats that require special modification are called EMHLD and EMOVR. These formats are used for sending hold and overdue notices from the loan module. The ISIS3W program sends these messages directly to an e-mail server and it interprets the first line output by each of these formats as an IP address of this server. Original English formats output IP addresses of the server used by an international organization where WebLIS was initially installed and this is why even these original formats require modification. The system administrator should ensure that all versions of the EMHLD and EMOVR formats output a correct IP address of the e-mail server used by the institution hosting the WebLIS system.

Although the applied naming convention simplifies replacing English names of CDS/ISIS formats and validation tables by their Spanish equivalents, this is a tedious work that requires concentration. Names of these formats and tables appear in various categories of files discussed in this paper:

• in static HTML files editind.html and presind.html,
• in all system definition files,
• in many data presentation and browse formats.

Note that CDS/ISIS format names are used in formats as parameters either in ISIS3W calls, such as
'<A href="/cgi-bin/isis3w.exe?rec_id=',mfn,
'&database=AUTH&search_type=link&lang=eng&format_name=EFCOR">',mhl,if v120:v9980 then v120 else v9980 fi,'</A>',
or in special ISISREF directives, such as
'<ISISREF dbn=loan#;# l=IL:',V810,'#;# PFT=@EFITM#;#>'
(these directives replace in formats used by ISIS3W the REF and L functions of the CDS/ISIS formatting language).

English version	Spanish version	Contents
<isis_worksheet>	<isis_worksheet>
name = LOH;	name = SLOH;	worksheet name
title = Loan;	title = Prestamo;	worksheet header
. . .	. . .
valid_pft = EVLOH;	valid_pft = SVLOH;	validation format
vdt = EVLOH.TAB;	vdt = SVLOH.TAB;	validation table
on_update_pft = @ULOH;	on_update_pft = @SULOH;	update format
proof_pft = @EPALL;	proof_pft = @SPALL;	data presentation format

 
Fig. 3. Exemplary headers of data entry worksheets

While browse and search definitions contain only names of data presentation formats, the data entry worksheet definitions may contain names of all types formats and tables. Validation format and table can be specified in the worksheet header together with insert, update, delete formats as well as a data presentation format. Figure 3 shows the headers of English and Spanish versions of the worksheet used for lending a given item for a given patron. All the elements changed have been distinguished in red (note the difference in worksheet names).

As was already explained, browse formats output lists of already registered values during data entry and if such a list can be generated the Browse button accompanies the textbox where a field is entered on a worksheet page. This feature is available when the field definition contains the parameter lookup_type=2 and then the FMT parameter defines a browse format name. For instance, the MON worksheet used for entering monographic materials contains the following field definition:
<isis_field>
name=call_no; description=<A HREF=/libcat/help/lib/22.html>Call no</A>(22);
tag=22; type=1; pfx=CN=; fmt=EB22; size=medium; lookup_type=2; lookup_choice=1;
</isis_field>
All elements to be changed in the Spanish version of this worksheet are distinguished in red. Note that the field name Call no is displayed as a link and the file libca\help\lib\22.html is output when the user clicks this link. The libcat\help directory contains numerous help files in HTML format (in particular files stored in the lib subdirectory describe fields of the LICAT database and the 22.html file explains rules of data entry in the Call number field). All these files output help information in English. If the system administrator decides to use the help files in the Spanish version of WebLIS, he/she should translate all these files into Spanish and replace names of original help files that output English texts by the names of translated help files.

4. Conclusions

As follows from the previous chapter, internationalization of the WebLIS system is neither easy nor straightforward. Table 3 summarizes the actions to be taken during preparation of a single language version and during preparation of each new language interface in a multilingual version of WebLIS. Not surprisingly, preparation of a new language interface is much more complicated than replacing the English interface with the user interface in another language.

Table 3

User interface files	A single language system	Each new language version in a multilingual system
static HTML files	translation of 3 TOC files minor changes in 4 other files	creation of 7 new HTML files in each of 3 new TOC files: - translation - use of new LANG codes - use of new names of worksheets - use of new names of formats - calling of other language versions changing the names of files referenced in each of 4 other files
system definition files	translation of 21 browse definitions translation of 11 search definitions translations of 26 data entry worksheets	creation of 2 new browse definition files in each of 21 new browse definitions: - translation - use of new names of formats creation of 2 new search definition files in each of 11 new search definitions: - translation - use of new names of formats creation of 26 new worksheet definitions in each of 26 new worksheet definitions: - translation - use of new names of formats & tables
HTML output templates	translation of 14 templates (7 templates in 2 LANG codes) translation of 4 Java scripts	creation of 2 new sets of templates and scripts in each of 14 new templates: - translation - replacing htp_include by SCRIPT translation of 4 new Java scripts removal of SCRIPT tags from 3 new Java scripts
formats and tables	translation of 126 formats & tables	creation of 159 new formats & tables in each of 126 new formats & tables: - translation - use of new LANG codes - use of new names of worksheets - use of new names of formats in each of 33 new formats: - use of new LANG codes - use of new names of worksheets - use of new names of formats

WebLIS is an ISIS3W application and its user interface fully depends on functionality of ISIS3W. Unfortunately, for developers of the ISIS3W program its language related functions were not a priority issue. In spite that the language code is provided as an obligatory parameter in each ISIS3W call, this program uses this parameter in a selective way, for instance it is applied to choose a correct language version of some system definition files only.

No one can expect that preparation of a new language version will be in an ISIS3W application as easy as in programs that store language dependant elements of their user interface in separate databases, but there is a lot of space for improvements. Development of new language version could be significantly simplified if the language code is used for selecting of:

Both ISIS3W and WebLIS are products of the same software house and therefore there is a chance that next releases of WebLIS will use an improved version of the ISIS3W program what will make WebLIS internationalization an easier task than it is today.