Multilingual Web sites: Best practice, guidelines and architectures

Transcription

1 Project Report Multilingual Web sites: Best practice, guidelines and architectures Experiences in designing and building multilingual Web sites Editor: Elisabeth den Os, KPN Suggested readers Anyone who is involved in the process of designing, building or managing multilingual Web sites. Abstract This deliverable addresses the experience of P923 in designing, building, and evaluating the EURESCOM Meeting Support Service, a multilingual web service. In this demonstrator service special attention has been paid to the architecture, that should make the building and maintenance of multilingual pages easy, flexible, and straightforward. It should also be easy to add new languages. The chosen architecture, in which there is a clear separation between content, presentation, and navigation, could be built with current commercial web development tools, and turned out to fulfil the requirements of flexibility and simple language navigation. Fairly new in this demonstrator is the integration of two language technology tools: Machine Translation (Systran Enterprise), and Automatic Summarisation (Extractor). This deliverable also provides information on a user evaluation of Machine Translation and Summarisation. Finally, this deliverable contains information on the use of a Translation Memory (TRADOS) in the context of multilingual web services. EDIN Project P923 For full publication August 2001

2 EURESCOM PARTICIPANTS in Project P923 are: KPN France Télécom British Telecom Telecom Italia Portugal Telecom Multilingual Web sites: Best practice, guidelines and architectures Experiences in designing and building multilingual web sites Editor: Elisabeth den Os, KPN Project leader: Elisabeth den Os, KPN Project supervisor: Name, EURESCOM GmbH EURESCOM published project result; EDIN EURESCOM Participants in Project P923 Disclaimer This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information. This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders.

3 EURESCOM Project Report page 3 (31) Preface Multilinguality is quickly becoming a major issue for the European Telecommunications Companies. Telcos are developing into full-service companies, that offer a wide range of services (e.g. e-commerce) via the Internet. Many Web services must be offered in several languages. The design and maintenance of multilingual Web sites require tools and procedures well beyond what is needed for mono-lingual Web sites. Without suitable tools -based on standardised architectures for multilingual Web sites- these sites and the attendant services are very expensive to create and manage. In previous R&D Projects in the field of Web and Language Technology it has appeared that truly multilingual developments are only possible if companies and research groups from different countries representing different languages collaborate. Therefore EURESCOM was the perfect frame where to undertake studies in this area, and EURESCOM shareholders will reap substantial benefits from them. Though the technology in that area is not expected to become completely mature before a few years, the development speed is increasing. Thus Telecommunications Companies which have experience with cost-effective procedures for developing and maintaining multilingual Web sites will be in a position to acquire a considerable share of this emerging market. The main focus of EURESCOM PROJECT P923 is the development of best practice guidelines for the design of multilingual (and therefore essentially also multicultural) Web based information and transaction services. The key results to be provided by the Project include: 1. a generic architecture for multilingual Web sites that are easy to design and maintain 2. best practice guidelines for building and maintaining multilingual Web sites 3. inventory of existing tools for multilingual text production and knowledge about their suitability for aiding the creation and maintenance of multilingual Web sites 4. practical experience with the creation and use of several multilingual Web sites The three first points were addressed in the first report of the project. This report is the second and the last one of the project. It covers the last two points through the experience of P923 in designing, building, and evaluating a multilingual web service, specifically the EURESCOM Meeting Support Service. The project has 5 participating companies and was lead by Els den Os from KPN EURESCOM Participants in Project P923 EDIN

4 page 4 (31) EURESCOM Project Report Executive Summary Why you should read this project report The benefits for your company For all Telcos the importance of multilingual web sites is rapidly increasing. For example, Internet service providers must be able to offer multilingual web portals, and mobile Internet users expect to be addressed in their own language, even when they are abroad. Project P923 investigated feasible architectures for multilingual web sites, and provided guidelines for the design and construction of sites that use state-of-the art language and speech technology. By doing so, the project makes a contribution to best practice guidelines for cost-effective building and maintenance of multilingual web sites. This Deliverable presents the lessons learned during design, building, and evaluation of a demonstrator for a multilingual web service EURESCOM Meeting Support Service. We present a possible solution for a multilingual architecture, and evaluations of the usefulness and acceptability of Machine Translation, Automatic Summarisation, and a Translation Memory. Aspects addressed by this project report This Deliverable describes the experiences during the building of the demonstrator and presents the user evaluations of three language technology tools that were tested in the context of the demonstrator. The first part of the Deliverable presents information on the design and building phase of the demonstrator. It is argued that it is necessary to take multilinguality into account from the very start of the design of the service. The experiments conducted in this project have shown that it is possible to design a multilingual architecture right from the start. In such an architecture a clear separation must be made between content, presentation of the content on the users screen and navigation, which makes it easy to maintain the site and to add new languages. Once this architecture had been chosen, we did not encounter problems in the construction and maintenance phase that are specific for multilingual sites, and that are not also encountered in monolingual sites. However, at this moment the integration and the effective use of language technology tools still require specific expertise and knowledge. Programming skills are needed to integrate the tools, partly because these tools are not specifically designed for use in web sites. The second part of the Deliverable addresses the usability of three language technology tools in multilingual sites: Machine Translation, Summarisation, and Translation Memory. The Machine Translation tool tested in he project was Systran Enterprise. The usefulness of fully automatic Machine Translation was only tested for documents that are likely to be translated on demand, i.e., if a web surfer encounters a page in a language (s)he does not understand. Systran was used to translate an original French text into English. Twenty-four subjects from four different countries have evaluated this automatically translated text. It turns out that fully automatic Machine Translation is useful and acceptable if users have insufficient command of the original language to read and understand the text. However, our subjects indicated that the Machine Translated text was not easy to read and to comprehend. The number of correctly answered factual questions was lower than for the native French subjects who based their answers on the original French text. The Translation Memory tool tested in the project was TRADOS. Translation Memories are mainly used to support human translators, who provide high quality translations for static web pages. To get a clearer view of the value of Translation Memories in the context of multilingual web sites, KPN has carried out an experiment that should allow us to estimate the cost and time savings that can be expected from the use of a tool like TRADOS. The results of the experiment are compatible with the claims of the vendor and the experience of professional translation bureaux: with closely related text which require repetitive translation proper use of a Translation Memory results in a cost savings of 20% on average. In addition, the consistence and overall quality of the translations will be improved. EDIN EURESCOM Participants in Project P923

5 EURESCOM Project Report page 5 (31) The tool for the automatic generation of Summaries tested in the project was Extractor. This tool was used to summarise two different English versions of a text describing the activities of the research lab of one of the EURESCOM shareholders. One version of the text was created by human translation, the other by fully automatic Machine Translation. The usefulness of the summaries for web surfers was assessed by the same 24 subjects who participated in the test of Systran. The results are somewhat equivocal. It appears that well-designed web pages are quite concise, and therefore difficult to summarise. In addition, it appeared that currently available summarisation technology may only be useful if applied to text written or edited by expert human translators or copy writers. Automatically generated summaries of Machine Translated texts were not considered as useful by our subjects. Conclusions In summary, the major conclusions of this Deliverable are: Multilinguality in web applications should be planned and designed for from the very start of a project The architecture of a multilingual web site should be based on a multi-tiered structure in which contents (data), presentation (the way in which graphics and text appear on the screen of the surfer), and navigation are clearly and formally separated The architectural requirements for multilingual web sites (separation of contents, presentation and navigation) are fully supported by all major development tools There is a fairly large number of language technology tools on the market, which may be used to make the construction and maintenance of web applications more cost-effective, and to improve access to information for the web surfers Optimal integration and use of language technology tools in multilingual web sites still require specific programming skills and linguistic expertise Fully Automatic Machine Translation is useful to enable surfers to access information that is only available in a language that they do not understand Translation Memories can reduce the translation cost involved in maintaining multilingual web applications by as much as 20%. Moreover, Translation Memories will improve the consistency and quality of the translations The usefulness of presently available tools for Automatic Summarisation in multilingual web applications is questionable 2001 EURESCOM Participants in Project P923 EDIN

6 page 6 (31) EURESCOM Project Report List of Authors Luis Almeida (PT) Nuno Beires (PT) Louis Boves (NL) Laura Cantamessa (IT) Maurizio Codogno (IT) Els den Os (NL) Flavio Manconi (IT) Luis Pinho (PT) EDIN EURESCOM Participants in Project P923

7 EURESCOM Project Report page 7 (31) Table of Contents Preface...3 Executive Summary...4 List of Authors...6 Table of Contents...7 List of Figures and Tables...8 Abbreviations...9 Definitions Introduction Objective of this document The organisation of this document The Specification of the demonstrator Parallel vs. non-parallel Web sites Locale-independent navigation Separation of content from Formatting Active client components Active server components Off-line vs. Dynamic Web page creation Language negotiation General guidelines for HTML files Pages with embedded scripts Graphics Use of a Translation Memory in a Translator s Workbench Web content management tools Web site management tools Scripting languages and character encoding The building phase Introduction Architecture General design issues Database Structure Language selection Integrating Language Tools Tools for exclusive use by the web managers Translation Memories Guidelines for selecting a TM system Tools for the service provider and end user Machine Translation Summarisation The user evaluation The usability of Machine Translation Test set-up Test results The Usability of Automatic Summarisation Test set-up Test Results Evaluation of the Translation Memory Conclusions EURESCOM Participants in Project P923 EDIN

8 page 8 (31) EURESCOM Project Report List of Figures and Tables Fig. 1 Screen dump of the home page of the BabelWeb demonstrator.. 17 Fig. 2. Screen dump of the page with information on PT. 18 Table I. Output of TRADOS Analyser for 10 web pages EDIN EURESCOM Participants in Project P923

9 EURESCOM Project Report page 9 (31) Abbreviations ASP MT TM TTS UCS UTF JSP PHP Active Server Pages Machine Translation Translation Memory Text to Speech Universal Character Set UCS Transformation Format 8 (UTF-8) Java Server Pages Personal Home Page (tool) 2001 EURESCOM Participants in Project P923 EDIN

10 page 10 (31) EURESCOM Project Report Definitions PHP In Web programming, PHP is a script language and interpreter, similar to JavaScript and Microsoft s VBScript, that is freely available and used primarily on Linux Web servers. PHP (the initials come from the earliest version of the program, which was called "Personal Home Page Tools") EDIN EURESCOM Participants in Project P923

11 EURESCOM Project Report page 11 (31) 1 Introduction The proof of the pudding is in the eating. This might be the motto of this Deliverable of the EURESCOM Project P923 Multilingual Web Sites: Best Practice and Guidelines and Architectures (Babelweb). Deliverable 1 of this project presented an overview of issues, architectures, and tools for multilingual web site building and maintenance. This Deliverable 2 describes the experiences with actual building a multilingual web service, along some guidelines that were proposed in the first phase of the project. Furthermore it deals with usability issues related to a number of Language and Speech Technology tools: Machine Translation, Translation Memories, Summarisation, and Text to Speech synthesis. We have chosen to build a demonstrator in this project, because we wanted to evaluate the ideas and solutions that were presented in Deliverable 1. We have built the multilingual EURESCOM Meeting Support Service. It provides useful information for a EURESCOM project participant who has to attend a project meeting in a foreign country. We chose this service because: It offers a framework to evaluate multilingual architecture issues It offers a framework for integration of language and speech technology tools It offers a natural possibility to combine internal and external sites It offers the possibility to control the content information It offers a useful service, closely related to tourist information, which means that the findings can be generalised to other web services. 1.1 Objective of this document This document describes the main issues we encountered during design, building, and evaluating the EURESCOM Meeting Support Service. The emphasis clearly lies on the multilingual aspects. Most sections contain a recommendation for web designers and/or builders who are interested in multilingual aspects The organisation of this document This Deliverable is organised as follows. Chapter 2 discusses the main aspects of the functional specification of the demonstrator. Chapter 3 three provides the main findings of the developmental phase, and chapter four gives the results of the evaluation phase of demonstrator. There are three appendices that contain detailed information on the three topics mentioned above EURESCOM Participants in Project P923 EDIN

12 page 12 (31) EURESCOM Project Report 2 The Specification of the demonstrator The main aim of building the demonstrator was to find out whether the proposals made in Deliverable 1 will work in practice. The final goal of the whole operation is to identify best practice solutions for cost-effective construction and maintenance of multilingual services. It was made clear in Deliverable 1 that multilingual aspects can best be tackled by thinking about multilinguality right from the beginning. This is contrary to the usual practice of adding multilinguality to a web site that is already in place, designed for use with a single language in a single locale. The framework we have chosen, the EURESCOM Meeting Support Service and its functionality, had a clear impact on some of our choices. In the next sections we will discuss the major choices. For a full and motivated specification of the demonstrator is provided in Annex Parallel vs. non-parallel Web sites The degree of parallelism of the information in various languages and for various locales determines the structure of the most appropriate architecture. In Deliverable D1, we have defined a number of categories related to parallelism. Seen as a whole, the demonstrator can be viewed as category 2, meaning that all information is generated separately, but that the navigation and storage structures remain the same. Each localised version plays a similar role. This is a choice we have made at the beginning of the design. In principle, we aimed at presenting information in all five languages. However, we left out Dutch because of the lack of adequate Machine Translation software for between Dutch and English, or Dutch and French. Also, because the target audience is supposed to have a sufficient command of English to be able to understand texts in English, no translation of the texts related to BT were provided. 2.2 Locale-independent navigation In the demonstrator that we have built, the same dynamic page is generally used for all the languages, so the navigation process is the same, and the only difference is the language used in the labels, it was our intention to provide a true locale-independent navigation. The information necessary to implement the EURESCOM travel support service was supplied by the different participants in the project, so it was necessary to define a set rules that each partner should respect to allow a locale-independent navigation mechanism. With this set of rules is was possible to achieve a high degree of parallelism in the Web site. In it has already been explained in D1 that a locale-independent navigation system is highly dependent on the degree of parallelism that can be obtained in a multilingual web site. If we want a locale-independent mechanism in our multilingual Web site, we should define and specify a set of rules that allow a high degree of parallelism in our site. This set of rules is strongly dependent on the characteristics of the service that needs to be implemented, its functionalities, the target languages, the culture of the potential users, etc, however it may be not trivial to define these rules. With all these constraints it may not be possible to implement a Locale-independent mechanism in all cases and it may be necessary to find a compromise. 2.3 Separation of content from Formatting The demonstrator was designed in such a way that formatting is general, and independent from the content. In order to get this separation between content and format almost all content for the EURESCOM support service was stored in a relational database. According to the user choices the content is retrieved from the database using dynamic pages based on Active Server Pages (ASP). The page generation software formats the contents according to the defined layout; subsequently, the pages are sent to the user browser by the Web server. In the demonstrator the data repository for the content was a relational database. As an alternative we could have used XML files or even text files with a specific format. However, this last option would not be very practical, because it would require the development of a parser according to the format of the file. The use of XML to EDIN EURESCOM Participants in Project P923

13 EURESCOM Project Report page 13 (31) store the content would be a viable alternative, with some advantages over HTML. XML specifies the structure instead of presentation, allowing the definition of our own tags and attributes to be extensible. With XML it is possible to overcome some of the major weaknesses of HTML, viz. the mix between format and content and its inflexibility due to the fixed number of tags. The first aspect was partially improved with the cascading style sheets (CSS) of DHTML. The style sheets are a collection of styling rules that can be assigned to document elements allowing some control over the format as it is explained in D1. XML is text based, allowing international support via the Unicode character set so it can be used in the multilingual web site development. In the case of the demonstrator we used the Active Server Pages(ASP) technology to generate dynamic pages however there are several technologies that implement dynamic pages such CGI, PHP, JSP or Servlets. The ASP is preferably used in Windows platforms, the CGI can be generated either for Windows or Unix platforms, the PHP is for Unix platforms and the JSP and Servlets are cross-platform solutions. There are several libraries and object components available on the market that can be instantiated inside these dynamic pages to access the data repositories that store the content. The data repositories can be based either on relational databases or on XML files. The use of dynamic pages to generate HTML pages according to the user choices seems to be one of the best approaches to separate format from content. 2.4 Active client components In the design of the demonstrator it was decided not to use any special client components, whether compiled, like applets, or not compiled, like JavaScript or VB scripts. The first kind of components are outside of the scope of this project and the second type of components were not used in the demonstrator due to the characteristics of the service that was implemented in the scope of the demonstrator. However, there are some practical guidelines for code structure related to scripts that can be presented. When possible it is strongly advisable to separate strings from code, in this way we are creating a locale independent script that access locale dependent resources. The easiest way to separate strings is by placing them in: one place within a file, a separate include file or a database. If strings are separated within a file, a comment line can help the web builder or the localizer during the developing or maintenance stages. Whenever possible, write Locale-independent code that can handle the different locale settings that are going to be supported, for instance a script that has to handle the European and US date systems. Control the use of variables; preferentially use only one variable for each string that requires translation. It is strongly advisable to add comments to the code, which will help the web builder or the localiser in updates or maintenance tasks. Use variable names that are not words. Variable names are often common words that risk translation. For example, if we consider the portion of code <select name= salutation > it is difficult for the translator to know if salutation is a name used internally by the script, a database query statement, or an element to be translated. If code and strings are not separated, it is advisable to include explanatory comments in the source file or alternatively to use variable names that are not words, such as <select name= salutationfld >. This solution works when the web builder assigns variables, but it may not work with for example SQL statements, which use plain English. Avoid breaking sentences, because broken sentences are difficult to read and translate. Sometimes sentences are unnecessarily broken, just to give code a clean wrap. If it is necessary to break the text, it is advisable to look to punctuation-periods, commas, colons, semicolons, etc.- as a good place to insert a break EURESCOM Participants in Project P923 EDIN

14 page 14 (31) 2.5 Active server components EURESCOM Project Report Some components have been especially built up for the project, namely the interface for the Extractor summarisation tool and for the Systran Enterprise machine translation. They are not directly related to multilinguality, but they must nevertheless be taken into account, because the selected language must be given as parameter to the tools. Besides these components the set of objects provided by Microsoft to access and interact with the database was used. 2.6 Off-line vs. Dynamic Web page creation In the BabelWeb demonstrator both static and dynamic pages are used, depending on the kind of information that we had. As explained above, most of the information present in the site will be stored in a database and retrieved to build the page shown to the user. In this case, we will have dynamic web page creation, since there is no place in the site where the exact appearance of the page is stored. Weather information, on the other hand, is automatically retrieved from an external site, and stored on the disk server in HTML files. In this case, we can talk about off-line web page creation, even if the page is dynamically updated, because it is statically stored. The expressions page is both generated and stored off line. 2.7 Language negotiation In the BabelWeb demonstrator language selection buttons appear on each page of the Web site, exploiting the fact that we had to put a banner on top of the page anyway. This approach is not optimal, as explained in [1], but it is nevertheless a good compromise and it lets the user change language in every moment. As explained in D1, it is possible to access browser properties through scripts to get the user language selection. With this facility it is possible to load the version of the multilingual Web site according to the language selected in the browser. 2.8 General guidelines for HTML files Apart from the coding already mentioned,, there is no special processing, such as CSS, Style Sheets, or Dynamic Fonts. The use of CSS may be very useful in the development of multilingual web sites because in some cases it can be used as an alternative to graphical images. Besides the decrease of the file download time that can be achieved with CSS, it allows in many cases the creation of a common visual design for the different language versions present on the multilingual web site. Independently of the language selected, the CSS can automatically accommodate the translated text for the different languages, avoiding all the process of graphical file generation for each language available in the site. 2.9 Pages with embedded scripts The demonstrator is almost completely built with ASP technology, except for some pages, that are in plain HTML. As said before, the pages sent to the client do not use scripts and are pure HTML pages. Incontrast, on the server side we have dynamic pages, based on ASP, that generate the HTML pages to the client browsers Graphics We used Adobe PhotoShop, which lets the graphical designer build pictures with different views: the views may also correspond to the labels in different languages. The graphic edit tools like Adobe PhotoShop support file formats in which the information of the image is organised in different layers. This feature is extremely useful for the development of multilingual web sites, because it allows an easy translation of the text contained within the graphic image. During the graphical design stage it is advisable to create the images bearing in mind the languages that the web site must support, leaving enough space to accommodate translations. One possibility that we did not explore in this demonstrator, would be to use an automatic process to check whether EDIN EURESCOM Participants in Project P923

15 EURESCOM Project Report page 15 (31) translations fit within the spaces provided. Since there are few graphic items with embedded text, we found it easier to perform this check by hand Use of a Translation Memory in a Translator s Workbench The Translation Memory tool TRADOS was used to check whether such systems actually improve the work of a translator, even if the Translation Memory is not developed for the same kind of texts as found in the target site Web content management tools FrontPage was used to build the general layout, and InterDev was used to build the code. Neither system has any special facilities for multilinguality. However they can both use UTF-8 coded characters Web site management tools We did not use such tools, because we have a rather strict control over the fixed text. Besides, the pages which are changing more frequently are all translated on-the-fly: this means that we don t have to check for new text, since this is all new from the point of view of the system Scripting languages and character encoding Even if for the purpose of the demonstrator, we could have limited ourselves to ISO (or ISO ), we decided to adopt UTF-8 encoding so that we could eventually go to Unicode without any problem EURESCOM Participants in Project P923 EDIN

16 page 16 (31) EURESCOM Project Report 3 The building phase 3.1 Introduction During the actual building of the demonstrator detailed logs were kept of all problems, procedures and results. The aim of the logs was to be able to document, analyse, and as a result better understand, the main issues involved in building multilingual web sites. Due to the tight constraints in terms of manpower and time to completion, it was evidently impossible to make the experiment a comprehensive one. Decisions were required which were specific to the application domain, the global architecture, and the language technology tools to be integrated. However, we are confident that our findings can be generalised to a much wider range of domains, architectures and tools. 3.2 Architecture In this section we describe our findings related to the overall design and architecture of multilingual web sites General design issues The choice of the general architecture was heavily influenced by the type of application we decided to build, viz. the EURESCOM Travel Support Service. This web site should provide general information on all shareholders participating in the project, general information about the country of origin, the town(s) where the research labs are located, etc. We wanted to provide essentially the same information for all shareholders and countries. Moreover, we wanted to offer the same navigation trees for all shareholders/countries. On its home page the BabelWeb demonstrator offers identical information categories for all partners or countries. Fig. 1 shows a screen dump of the home page, displayed in English. At the second level of the navigation trees, the same general structure was implemented for all countries. From the second level independent links to external sites were enabled, that are naturally different between the countries Implications of parallel information The decision to offer identical navigation for all countries/languages entails the need to have reasonably parallel versions of all pages at the highest levels of the site. However, since the information in the top level pages is inherently different for all operators, independent pages must be stored. For instance, the general descriptions of the Operators, and the general information on the countries is independent for KPN, BT, etc. To allow identical navigation and comparable appearance of the pages, all participating operators had to provide the same type of information, in roughly the same type of text. Most operators provided the texts in their native language and in English. Text for use in the top level pages of a web site like the EURESCOM Travel Support site must be of high quality. Therefore, unedited Machine Translation is not an option. Experience in collecting the information from the partners has shown that this process is all but trivial. Information on the companies and the research labs is not easily available in comparable form for all shareholders. The same goes for information on the countries and the towns. Moreover, it appeared to be difficult to specify the exact format in which the texts had to be provided in such a way that it was easy for the partners to cast their contributions in the right format. Collecting parallel information from different sources, and casting that information in the format needed for a web site with homogeneous appearance and navigation for independent parallel information streams is difficult and time consuming. If collecting and formatting information from independent sources cannot be avoided and it often cannot one must make sure that enough time and resources are allocated, both at the receiving and at the sending side. It is strongly advised that the information be collected incrementally, in small chunks. This procedure allows clarification and refinement of the formatting instructions during the process. EDIN EURESCOM Participants in Project P923

17 EURESCOM Project Report page 17 (31) Database Structure In an early stage of the design process a three layer structure was chosen, in which the data and the presentation are separated. This decision entails the need to build a database to store the information. During the process of building the demonstrator it appeared that it is necessary to structure the database in two layers, one for storing the language/locale independent information and another to store the language/locale dependent information. This database structure reflects the structure of the navigation tree. On the top level pointers are included to country/language specific pages. It is strongly advised to separate language/locale dependent from language/locale independent information in the database of a multilingual web site Graphical Design The graphical design of a web site has a very strong impact on its appeal. The graphical design of a multilingual (and multi-locale) web site must take into account more constraints than a monolingual site. Icons, and even colours, may have different connotations and associations in different countries or cultures. One striking example is the use of the colour orange, which evokes very strong (positive and negative) emotions in Ireland. In order to allow identical navigation through the information for each country the pages were designed as frames. At the left side of each page a column was reserved for the navigation buttons. Enabling language switching on each page requires that language selection buttons are present on each page. Inevitably, the buttons for language selection and navigation buttons take up a considerable amount of real estate, thereby limiting the space which is avalable for text and other information. The design of the home page is shown in Fig. 1.; the layout of a typical page at the second level is shown in Fig. 2. The implementation of graphical elements (e.g. buttons) in a multilingual web site make specific requirements that are less frequently encountered in mono-lingual sites. Often, icons and buttons consist of a combination of graphical elements and texts. A fully localised version of a web site requires that the texts in the icons and buttons be translated. Therefore, the text should not be integrated in the graphics in the form of pixel data, because this would require to store all combinations of the graphics and texts for all languages. Moreover, it would make the maintenance of the web site more complex, if texts have to be changed. In the BabelWeb demonstrator the graphical data is separated from the textual data. This is done by using multiple layers for the icons and buttons, one for the graphics and one for the text. Many software packages support multi-layer graphics. In BabelWeb Adobe Photoshop was used for this purpose. Graphical design of multilingual web pages must take locale-specific connotations of pictures and colours into account. One should use frames to facilitate the consistent use of language selection and navigation buttons. However, the division of the pages into frames that display fixed or variable information reduces the area that can be used for text and other information on a screen. Buttons and icons should be implemented in a multi-layered structure, separating picture data from text data Language selection Language navigation can be done in several different ways. Experiments have shown that users prefer to be able to switch between languages within each and every page of a web site. Some multilingual web sites would transfer the user to the top level page as the results of a language switch. For the BabelWeb demonstrator it It was decided to allow language switching from all pages maintained by the web site manager. Switching between languages in external pages is only implemented for the weather information, that is obtained on-line from the CNN Weather service. Language switching is enabled through a set of icons that appear in the same position on all pages. A combination of flags and text (language names) was used. It is generally assumed that such a 2001 EURESCOM Participants in Project P923 EDIN

18 page 18 (31) EURESCOM Project Report combination is the best possible way of indicating the choices. Of course, the language names must be compatible with the language that is selected. However, one must be aware that problems can occur with countries that have several official languages. These problems will be especially severe in countries like India, where different languages come with different writing systems, which may not be recognisable across language borders. This is an area where more research, focused on non- Western languages and cultures, is definitely needed. Language selection buttons should appear on each page. A combination of graphical and textual information, like a flag and the language name, are preferred over either flags alone or language names alone. Fig. 1 Screen dump of the home page of the BabelWeb demonstrator Dynamic Pages Web pages can be stored in a database for display, or they can be generated on demand from data that do not need to be formatted in advance. The latter technique has a large number of advantages, and consequently is gaining popularity among builders of web applications. It has already been pointed out that separating data and presentation is almost essential in a multilingual web site. Thus, there is virtually no alternative for an implementation in which the pages are generated on the fly. The use of dynamic pages for multilingual web sites is strongly recommended. On the Windows NT platform this can be accomplished by using Active Server Pages. For Unix systems alternative software packages such as JSP or PHP are available, which offer the same functionality. EDIN EURESCOM Participants in Project P923

19 EURESCOM Project Report page 19 (31) Fig. 2. Screen dump of the page with information on PT 3.3 Integrating Language Tools During the process of building the application the experience with integrating the language tools was logged. It soon became evident that we were dealing with two quite different types of tools, viz. Translation Memory systems (TM for short) like TRADOS on the one hand and Machine Translation (like Systran Enterprise) and Summarisation Tools (like Extractor) on the other. TM systems are only useful to support the people who create and maintain the web service. The other category of tools can be used by both the end users and the persons responsible for the maintenance of the contents of the web site. In section 3.4 we will discuss the tools that are only useful for the web builders. In section 3.5 we discuss the tools that are useful for both sides. The different functions of the language tools are reflected by different ways in which they are integrated in the workflow and the web application. If the tools are used by the persons responsible for the creation and maintenance of the contents integration must be such that it supports the work of teams of professionals, who can be trained to make judicial use of the tools. Especially Machine Translation, and perhaps to a lesser extent automatic Summarisation, can also be used on demand, by the web surfers who cannot be expected to be trained in the proper usage of those tools, neither from the point of view of system integration, nor with respect to their actual operation and performance. 3.4 Tools for exclusive use by the web managers In this section we present our findings with respect to language tools that will only be used by the web persons who are in charge of the maintenance of the contents of the web service. The single most important such tool is a Translation Memory system. Not very surprisingly, given their quite 2001 EURESCOM Participants in Project P923 EDIN

20 page 20 (31) EURESCOM Project Report different roles in the process of building and maintaining a web site, the use of a TM system is different for the web manager and the translators. Translation Memory systems consist of several modules, among which a memory of translation pairs for words, expressions, phrases and sentences; a module that checks texts and computes the proportion of the words and expressions that can be found in the memory (called the Analyser); and a module for updating the memory by adding new translation pairs. More detailed information on TMs can be found in Deliverable 1. Quite a number of TM systems are available on the market. The high level functional specifications of these software packages are virtually identical. Yet, products may differ substantially at the operational level, as well as in terms of cost, licensing, etc. TMs were originally designed to support the management and the execution of translation processes. We have found that the typical usage of a TM for a web master will be limited to the management function Translation Memories Translation Memories like TRADOS are part of the workflow or document flow; their major role is in the maintenance phase of a web application, rather than during the building phase. Translation Memories are used to support repetitive translations of essentially the same text. TMs can also be useful in the first translation of new texts, provided that these texts contain the same kind of expressions that have been found in other texts that were previously translated. For a TM to be useful in the maintenance of a web site a procedure must be put in place by which each text that has been changed is sent to the Analyser of the TM system, to establish the proportion of the new version of the text for which approved translations are already available. The result of this analysis is sent to the web site manager, who must then decide what to do. If the proportion of fragments for which no translations were found in the TM is small, or if the previously unseen fragments mainly consist of proper nouns, the manager can decide to translate the text herself, using the translation equivalents found in the TM. If the proportion of misses in the TM is too large, and if the quality of the translation must be high, the web site manager will probably decide to sent the new version to a human translator. The latter can be in-house, or work in a professional translation bureau. Independently of where the translator is located, the web site manager can use the statistics from the TM to estimate the cost of human translation and to determine its relative priority. Fair estimates of the costs of outsourcing the translation can only be obtained if both the web site and the translation office use the exact same version of the TM. This requires tight coupling of the memories. Some translation or localisation firms offer support in maintaining TMs. Since new translations must be approved by expert translators, it is the translation office that is responsible for updating a TM. However, for the process sketched above to be feasible, the translation office must forward the updated memory to the web site manager. Alternatively, the work/document flow could be organised in such a way that updated documents in the web site are sent to the Analyser that accesses a memory that is maintained by the translation office. If this can be done, only one copy of the TM needs to be maintained Guidelines for selecting a TM system When it comes to selecting one of the TM products that are available on the market for integration in the work flow for building and maintaining a web site several issues must be considered: Will a TM be at all useful? It is not a priori evident whether the cost of integrating a TM in the work flow of a multilingual web application can be justified. The Analyser function of the TM system will only return a set of statistics. Therefore, it remains the task of the web master to interpret the statistics, and to act upon them. This requires some basic expertise in the use of TM systems on the part of the web manager. By far the most important function the TM will serve for the web manager is to support the decisions whether a page that has been updated should be sent to a professional translator. This is EDIN EURESCOM Participants in Project P923

21 EURESCOM Project Report page 21 (31) the more so if the web manager is not in the position to perform simple translation tasks personally, or to delegate these tasks to a competent person in the web maintenance team other than a professional translator. If simple translation tasks cannot be performed locally, all texts that have been changed must be sent to (external) professional translators. In these cases the TM is an invaluable help for the web master in evaluating and monitoring estimated translation costs. If information in a web site can only be updated by changing data in forms or similar structured representations, and updated pages are generated (almost) automatically from these data (resulting in static pages to be stored in the database underlying the application), one probably does not need a TM system to monitor the need for re-translation. Most likely, a TM system will only make sense if changes are made to free text, or if new pages containing free text are added to the database. All professional translation services will be able to help a web site manager to analyse the type of documents, and the type of updates to those documents. Based on such an analysis it will be possible to make an informed estimate of the usefulness of a TM system in a specific application. Cost-effective usage of a TM system in a multilingual web application requires specific expertise, that probably will require some degree of training related to the specific product Ease of use of the Analyser function For the web master, the Analyser function of a TM system is probably by far the most important one. In order for this function to be cost-effective, it must be easy to automate the work and document flow to a very large extent. First of all, an alerting procedure is needed, that reports all changes in documents in the web site to the web master. The structure and the implementation of this alerting function will depend heavily on the ways in which documents in the web site can be updated. If only the web master has the privilege to update pages, a complicated alerting scheme is not necessary. However, if several information providers have access to the database with documents, an automatic procedure that enforces a check of the updates is desirable. It is easy to imagine that the procedure can become quite complicated, and heavily dependent on the type of documents and the way in which updates are performed. Web pages containing free text will come in HTML or XML format. For the Analyser function of the TM system to work properly, the web master must have access to the DTD of the pages. Without the DTD, the TM system will not be able to parse and process the input pages properly. Some TM systems will come with an API to access the Analyser function; other TM system may offer alternative means of accessing the Analyser automatically from within a web application. The ease with which the Analyser function can be accessed, and the dependability and functionality of this access evidently has a large impact on the cost of integrating the system. Most TM systems are mainly targeted at human translators, who may not be interested in checking documents offered for translation automatically. This may cause considerable differences between the functionality of automatic access procedures. Whereas human translators should be consulted if it comes to decide whether a TM system is at all useful, software engineers should be consulted to assess the cost of integrating a specific product in a web application. So far, little independent information on the ease with which different products can be integrated into the work flow is available Distributed Processing Another issue of considerable practical importance is the relation between the web master and the translation office. Many companies may not have internal translation services, that can be contracted to take care of the human translation tasks involved in the creation and operation of a multilingual web service. More often than not, translation (or more precisely: localisation) tasks are outsourced to specialised agencies. The physical and organisational distance between the web master and the translation bureau will have an impact on the work flow, and possibly also on the details of the way in which the TM system is best integrated in the web manager s working procedures EURESCOM Participants in Project P923 EDIN