domain: info.info-cl info shs

text:
Christian Boitet
email: christian.boitet@imag.fr

Valérie Bellynck
email: valeriebellynck@imag.fr

Mathieu Mangeot
email: mathieu.mangeot@imag.fr

Carlos Ramisch Getalp

Towards Higher Quality Internal and Outside Multilingualization of Web Site

Keywords: Multilingual access, Machine Translation (MT), online MT, Web localization, collaborative translation environment, extended translation memory, translation of dynamic Web sites

The multilingualization of Web sites with high quality is increasingly important, but is unsolvable in most situations where internal quality certification is needed, and not solved in the majority of other situations. We demonstrate it by analyzing a variety of techniques to make the underlying software easily localizable and to manage the translation of textual content in the classical internal mode, that is by modifying the languagedependent resources. A new idea is that volunteer final users should be able to contribute to the improvement or even production of translated resources and content. For this, we have developed a PHP piece of code which naive webmasters (not computer scientists nor professional translators) can add to a Web site to enable internal multilingualization by users with enough access rights: in management mode, these users can edit the texts of titles, button labels, messages, etc. in text areas appearing in context in the Web page. If Web site developers follow some recommendations, all textual interface elements should be localizable in this way.

Another angle of attack, applicable in all cases where navigating a site though a gateway is possible, consists in replacing the problem of diffusion by the problem of access in multiple languages. We introduce the concept of iMAG (interactive Multilingual Access Gateway, dedicated to a Web site or domain) to solve the problem of higher quality multilingual access. First, by using available MT systems or by default morphological processors and bilingual dictionaries, any page of an elected website is made instantly accessible in many languages, with a generally low quality profile, as through usual translation gateways. Over time, the quality profile of textual GUI elements, Web pages and even documents (if accessible in html) will improve thanks to outside contributors, who will post-edit or produce the translations from the reading context. This is only possible because the iMAG associated to the website stores the translations in its translation memory (TM) and the contributed dictionary items it its dictionary. The TM has quality levels, according to the users' profiles, and scores within levels. An API will be proposed so that the developers of the elected website can connect their to its iMAG, retrieve the best level translations, certify them if necessary, and put them in their localized resources. At that point, external localization meets internal localization.

Introduction

More and more information is disseminated trough Web sites, and there is a desire or even an obligation to make it accessible in many languages, with a quality level far above what general-purpose MT can achieve. International bodies such as the EU or UNESCO or ITU have actually a legal obligation to do it (in more than 20 languages for Europe, in 6 languages for UNESCO and ITU). Large and small firms have to publish their documentation in many languages, and to adapt, or localize their products. Software publishers are a case in this point: IBM localizes in 25 languages, Adobe in 32, HP in 40, MicroSoft in 45, etc. Another kind of would be multilingual quality publishers are Web communities dedicated to causes such as human rights (PaxHumana), peace, health, or simply to some domains (e.g., cooking). But official organizations legally bound to publish in many languages don't do it in reality, or only for a very small proportion of the information, even if they spend a lot on translation. Many firms can also not bear the costs of HQ translation, and limit their localization to a few languages, which reduces their potential market, and dramatically increases the cost of their hot lines, under heavy pressure because users cannot understand well enough the English documentation, or the low-quality translations provided. We propose two complementary approaches to solve this problem. First, outside localization is possible for Web sites, although it may be differently handled for program-related textual material (labels of GUI elements such as titles, buttons, and program messages) and for contentrelated material. Whether that content is stored in static Web pages or dynamically generated from a database makes no difference in our approach, based on associating an iMAG (interactive Multilingual Access Gateway) to an elected Web site or domain. Second, inside localization techniques can be dramatically improved in the case of Web sites, with respect to classical techniques. The first step is to allow not only developers, but managers and reliable users of Web sites to edit the localized resources (program-related as well as content-related) in their language in an easy way. According to the design of the Web site, the localized strings appear immediately, or only after the next build of the packages used. The second step is to allow localization in context, which is a dream for translators of software packages. For the moment, our technique is limited to Web sites. If the developer follows some guidelines and organizes the code appropriately, the manager and reliable users can localize the Web site in context, while using the site, switching seamlessly between usage context and editing context: in management mode, an editable text area appears next to each localizable object, and the page is updated after the next click outside it. The first section discusses in more details the differences between inside and outside localization techniques, according to various translational situations. The second section describes pros and cons of classical inside techniques, applied to Web sites, and introduces an innovative in context localization technique. The third section presents outside localization techniques, and introduces the iMAG concept, which extends the translation gateway concept to allow contributive quality improvement.

Inside and outside localization

The proper term to use in our context is multilingualization or linguistic porting, rather than localization, which implies not only translation into other languages, but more adaptations.

For example, a vertical menu placed at the left for left to right scripts (e.g. English, Hindi) should be placed to the right in the case of right to left scripts (e.g. Arabic, or Urdu). We will however often use localization here instead of multilingualization for the sake of brevity. Inside localization is done by working on the code and resources of an application (a Web site in particular), while outside localization is done by translating and adapting what is produced by the application, without any intervention on its code and resources.

An unsolvable problem: quick certified HQ multilingual diffusion

Many official organizations such as the European Union (EU) or UNESCO have several official languages in which they are supposed to disseminate all their documents. However, any multilingualization index of their websites is abysmally low. Here is an example taken from the EU site, where that index is less than 25% (6/23), even at the first level. When one goes down 2 clicks, it decreases to 4-8% (1-2/23).

That happens often because of the presence of a (understandable) certification policy. No material can be disseminated without formal approval. In the case of translation, that means that professional translators hired by the organism or firm have to "bless" any translation before it is published as coming from it.

Figure 1: low multilingualization index at EU site

In 2004-05, a group of 3 labs translated the textual material of the B@bel Web site of Unesco from English into Chinese, French, Russian, Spanish (and later Thai), 4 of the 5 other Unesco official languages. That material comprised 42301 words, about 169 standard pages, divided in 2896 segments of 14.9 words in average (the 1000 longest were 15.6 words long in average). The translations were all revised by native speakers with good knowledge of the domain.

Although this had been done in the framework of a research contract from Unesco, it was later impossible to get Unesco to include these translations in its database. That database is indeed prepared to handle the 6 languages in question, but remains almost empty for all but English.

Multilingual access with unguaranteed & unlabeled quality is not enough

Using free translation gateways is also not a solution when a really good understanding of the content is necessary. Trying to browse in French (or even worse in German) the Europe Web site(s) for calls for proposals is a conclusive experience. These calls should (by European law!) be available in all 23 official languages at the same time, with the same quality. The 1700 translators of the EU are certainly not enough to cope, and that number did not considerably augment with the number of languages growing from 9 around 1982 to 23 in 2007, 25 years later.

Misunderstandings about progress in MT

The kind of MT which would be necessary to cover that kind of need is simply not there. There are many claims about the progress made in MT in the last 25 years. It may be true that a lot more language pairs are covered, but usability when HQ is needed has not improved, on the contrary.

Even for main language pairs, Systran admittedly did not improve its quality significantly since 1990 or so. Small improvements are now coming from the use of statistical techniques (to try to correct mistakes in the output, or better to choose another morphosyntactic analysis in the output lattice).

Google is now proposing many language pairs built by SMT, but their reliability is even lower. Unseen words simply disappear, while they at least show in the outputs of Systran or Reverso, and can be outlined on demand. More generally, claims to the quality progress ignore the basic fact about MT, which is that "C . A . Q << 1" (the product of coverage by automaticity by quality is far lower than 1), which is inherent in the problem. To achieve HQ in large domains, one must use some kind of human help, such as interactive disambiguation in the source language, or interactive choice among a large quantity of candidates in the target language, or (co)edition of an intermediate form.

Inside multilingualization

The classical way to internationalize a Web site, and more generally any application, is to separate from the code the natural language strings to be shown or printed (or pronounced) by the application, and to put them in separate resources.

One can distinguish 5 kinds of segments to localize:

• A: short, fixed texts without variables.

• B: parametrized messages with variables and possible variants in the surrounding text, such as error messages or personalized invites. • C: longer and more complex texts, such as online help included in the code. • D: the same, but residing not next to the code, but elsewhere, possibly on another Web site. The is the case of the minimal online help of Dokuwiki (reference manual). • E: pages built with the tools of the considered Web site (content).

Localization of messages and GUI texts

These textual elements (A and B above) are represented as formats, that is strings containing variables and formatting controls, such as "Max temperature was %f °C" (or "%3:1f" to put 3 digits before the decimal point and 2 after).

The gettext / ngettext technique

Although it is used for Web applications such as WordPress (a CMS 1 blogging software), the gettext library (www.gnu.org/software/gettext/) was originally designed for standalone software. It contains a compiler of message catalogs and the gettext and (more powerful) ngettext macros.

Here is an example where ngettext is used to

1 Content Management System
generate variants (singular and plural forms) in the text around the (instanciated) variable.

// nplurals = number of variants for the plural. // plural varies from 0 to nplurals-1, msgstr[plural] will be selected. // Catalog en_US: 1 variant for plural in English Plural-Forms: nplurals=2; plural=n != 1; # catalog header msgid "Match to %d point"

# key for case n=1 msgid_plural "Match to %d points" # ---case n≠1 msgstr[0] "Match to %d point" # n == 1 msgstr[1] "Match to %d points" # n == 0, 2, 3 ... // Catalog jp: no variants for plural in Japanese Plural-Forms: nplurals=1; plural= 0; // plural=0: msgid "Match to %d point" msgid_plural "Match to %d points" msgstr[0] "%d POINTO MATTI" # all n // Catalogs for Russian : 3 variants for plural. Plural-Forms: nplurals=3; # condition (OK here, false on GNU site!) plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2); msgid "Match to %d point" msgid_plural "Match to %d points" msgstr[0] "..."

# In the "native" program, messages that need to be localized are tagged (msgid, msgid_plural).

Then, the compiler generates a file with all the messages that need to be localized. This file is duplicated and translated into every needed language. A final compilation produces a binary file used at runtime for displaying the messages in the user's preferred language. This library has been adapted to many programming languages, including PHP: WordPress is a software programmed in PHP and uses the PHP-gettext.php library. Advantages. Because the messages are first compiled before runtime, the execution is faster than with an array loaded on demand at runtime. Inconvenients. In the translation files, only the messages are displayed. Their context is missing.

But it is often difficult to translate messages without any context.2 Also, in some cases, when a software is available for download, only compiled .mo files are included, not the source files. Thus it is very difficult to modify a translation. Furthermore, even if the source files are available, the gettext library must be installed locally to recompile and obtain the new .mo files.

Finally, it happens that different plugins use different localization techniques.

The PHP array technique

The Inconvenients. With this technique, the whole context is also missing. Furthermore, the use of an array increases the execution time of the scripts.

Inside localization of Web pages

How to improve Web sites localization? We will first compare some localization techniques.

The template technique

A template is the analog of a format for a whole Web page.

We take as example our Jibiki platform, which is based on the Enhydra Java Web Server. Each Web page is compiled from an HTML template (.po) into a java class. At runtime, the display method of the java class is called and creates what is displayed to the user.

Figure 4: localization with the template technique

In order to internationalize the platform, we developed a java method that chooses at runtime which template to display, depending on the user's preferred language and the language templates available. Every page has a default template. Some templates are translated into one or several languages. The template of the preferred language is chosen first. If it is not available, the default template is used. In theory, someone who wishes to translate a template can do so by editing it with an HTML editor, without having to know HTML. In practice, however, this method is rarely used because of several problems. (1) Many HTML editors such as DreamWeaver modify the structure of the template while editing it. It is then impossible to compile it.

(2) A Web page is often built with a combination of several templates: it may be difficult to translate them, because it is not possible to see the entire Web page when translating. (3) It is not possible to recreate all the conditions in which a Web page is seen online, for example when error messages appear, because the templates are edited offline. Advantages. Because the whole template is translated, there are no problems with the variables contained in the messages. It is also possible to translate javascript messages if their code is inside the templates. Inconvenients. There may be inconsistencies in the translations because it is not possible to reuse already translated messages or parts: the same button with the same functionality can be translated differently depending on the page and the author. Remaining problems. Some parts of the code are still difficult to translate, for example internal java messages targeted to the user (mainly error and feedback messages). Also, there is no mechanism to automatically send a newly created template to the appropriate translators to translate it into all target languages.

Language Negociation

The choice of the language at run time can be negociated by the Apache (or Tomcat) server, or by geolocalization, as done by Google. Apache Web server. The LN module serves the page matching the browser's preferred language. Geolocalization. The results of a request depends on the user's location. If a user queries google.com from France, s/he will be redirected to the google.fr engine, etc. and the results of the same query can thus be different from one country to another.

Conclusion. Even if the LN or geolocalization choice is adequate in most cases, a multilingual

Web site must always display on each page a link to its translations in the other available languages. Furthermore, if it is technically feasible, it should memorize the choice of the user during the navigation on the site and remember it when the user comes back later.

Organization of resources

Another crucial aspect is the physical organization of the textual resources in the different languages.

Here is an example for the Chuwiki CMS: In Chuwiki, the glossary is very small, and one edits in effect a simple script that assigns values to variables. In Dokuwiki, the organization is more complex (see Figure 8). The glossary is larger, and is stored in an associative table. Elements contain variables, to be substituted on the fly. In PHP, the problem of change of order of parameters is solved if one numbers them by writing '%s1\$', '%s2\$', etc., thanks to an extension of the vsprintf function. Linking resources from Web pages through special links appearing always or on demand is a way to "turn around" the problem of context, so that one can navigate in a Web site, find the resource(s) used in the current page, and translate or correct them, knowing the context.

Localization in context

A more natural approach is to localize from the Web application itself. We have developed a piece of PHP code, easy to integrate in Web sites to do that. In management mode, a text area appears next to each localizable element. Clicking outside it lets the page appear with the updated text. If someone wants to modify a translation, it is sometimes very difficult to find where it is stored: in a template, in the database, in a localization file, etc. It even may not be possible to find it when for example, the software is translated with gettext and the source file is not distributed.

If someone writes a translation into a new language or corrects an existing translation, there is no simple mechanism to submit the new translation to the developer of the software. Sometimes, developers provide a way to submit translation files, e.g. via a post in a forum. It would be more efficient to be able to send back automatically a new translation to the developers of the software via a standardized protocol. None of these techniques allows a user to translate dynamically on the fly and to easily send back the translation result to the developers of the software. It is also not possible to reuse existing translated chunks of messages like with a translation memory.

Outside automated contributive localization & quality improvement

Call to a translation gateway

Yahoo!, Voilà, Google Translator, Systranbox and Babelfish are examples of MT translation gateways. The incoming Web page is segmented, segments are translated by the online MT server, links are modified so that accessed pages come back to the gateway, and a target Web page is sent on the fly to the user's browser. It is enough to copy the url of the original page into the gateway, but it is also possible for a Web site developer to add a button to some or all of the Web pages.

Advantages. The module is external so there is no need to install or compile anything.

Inconvenients. The translation engine is not tuned to a specific domain, thus the quality is usually not very good, or rather low. However, that technique is generally used only for getting an overall idea of the source page at the price of a short delay (about 0.5 to 1 second per page for Systran). Finally, there are actually not many acceptable available language pairs (of the 35 Systran pairs available around 2000, 8 were said to be usable by the EC).

Combining translation gateways

(VoTrung 2004) has produced a system to translate a possibly multilingual text, not necessarily a Web page) into a specified target language tl. For that, he first segments the text into parts homogeneous with respect to language and coding, and converts it into an utf-8 text with tags indicating the language and original coding of each part. Each part is then submitted to MT, after another encoding conversion if necessary. If no MT system exists from a source language sl into tl, a double translation is attempted through an intermediate language, in general English (it may be shown to the user). The results are then assembled and a target text is produced. A Web service allows to see several translations produced by different routes, in the hope that errors of one system may be compensated by other systems.

One could continue along these lines, e.g. by allowing the user to correct the intermediate English form, if any, to get a better result in his language, but the quality limitations cannot be overcome.

Another approach has been developed, which concerns only the content of documents distributed through a CMS. Y. Bey has developed te BEYTrans prototype, which is a Web service for communities of volunteer translators (Bey & al. 2006(Bey & al. , 2007) ) offering linguistic helps (online dynamic dictionary and translation memory, call to MT systems, online translation editor).

The iMAG concept

We propose to replace the problem of HQ certified translation by that of multilingual access, with quality increasing over time thanks to contributive post-edition.

To implement that idea, we build iMAGs (interactive Multilingual Access Gateways). An iMAG is a translation gateway, like Systranbox or Google Translator, which replaces on the fly a Web page by its pre-translation, and allows to browse a site in the chosen target language, by prefixing the links in the page by the url of the gateway. Contrary to usual translation gateways, an iMAG is dedicated to an elected Web site or domain. That is the key to enable improvements in translation quality over time. The iMAG has a translation memory in which, ultimately, the full set of information of its elected Web site, divided into segments, the minimal translation units, will be stored. For each segment, we store translations at 5 estimated quality levels, with scores in each level:

• word for word (*),

• MT result (**), and then translation or post-edition by • a native speaker of the target language (***),

• a professional translator (****),

• a translator certified by the elected site (*****). A score can be added. For example, a post-editor may want to tell that he has doubts or is sure about his work on one particular segment. An iMAG contains a terminological and phraseological dictionary specialized to the texts of its elected site, and built from them and from the contributions of post-editors. And, last but not least, it offers an online editor, tightly integrating the linguistic helps, and offering them in a proactive way: when a segment is edited, suggestions from the dictionaries and the TM are precomputed, and MT has already been performed.

Current prototype built on SECTra_w

The scenario is as follows. Suppose a user wants to get access to page P (originally in source language sl) of site W in target language tl. S/he pastes the url of P in the iMAG dedicated to W and submits it. P is segmented into segments or translation units (TUs), which is often not trivial. Each segment is looked for in the translation memory (exact match or fuzzy match above a certain threshold). If no exact match is found, MT systems are called. If the language pair is not provided by any of the available MT, a word by word translation may be provided (*), and/or a double MT through English is produced (** with low score!), to get something rather than nothing.

Having translated each segment with a known a priori quality level, the iMAG constructs a new HTML page by replacing each source segment with its best translation, thereby adding javascript code and other information (the source text in particular). The constructed page is sent to the user (see Figure 12). As in GoogleTranslate, added javascript code enables users to switch seamlessly to the online translation editor, and all links are changed to allow navigation in the target language. The difference is that translations improved by post-edition, if any, are added to the TM, and immediately available if a page containing them is consulted. Another advantage (for the future) is the possibility to build an MT system from the collected specialized data.

Towards mixed outside/inside contributive & incremental localization

Preparatory Work. There is a possibility to increase the quality of the iMAG translations by doing some preparatory work. For example, the translation memory can be bootstrapped with the existing site textual material. In the background, the iMAG could query some shared terminological resources in order to find High Quality translated segments and to transmit them to the elected Web Site.

Conclusion

Classical inside localization techniques are hard to apply to Web sites, in particular because developers are often not "hard" programmers. Moreover, the organization of textual resources and of the localization process varies enormously, even between instances of the same generic CMS (like Chuwiki, Dokuwiki, Xwiki, Joomla…). We have proposed and developed a technique allowing even users to localize a Web site in context, while using the site, in a special management mode.

We have also prototyped the new iMAG concept to perform contributive outside localization. Both are very promising directions for the future.

Figure 2 :

 2 Figure 2: Example of using ngettext

Figure 5 :

 5 Figure 5: languages resources in Chuwiki

Figure 7 :

 7 Figure 7: language resources in Dokuwiki $lang['subscribe_success'] = 'Ajout de %s à la liste d\'abonnés de %s'; $lang['subscribe_error] = 'Erreur à l\'ajout de %s à la liste d\'abonnés de %s'; $lang['subscribe_noaddress] = 'Aucune adresse associée à votre nom d'utilisateur, impossible de vous abonner'; $lang['unsubscribe_success'] = 'Suppression de %s de la liste d\'abonnés de %s'; $lang['unsubscribe_error] = 'Erreur à la suppression de %s de la liste d\'abonnés de %s';

Figure 8 :

 8 Figure 8: resource file for messages in DokuWiki

Figure 9 :

 9 Figure 9: text with variables in wiki transcription (Dokuwiki)

Figure 10 :

 10 Figure 10: normal view of a Web page

Figure 12 :

 12 Figure 12: Source and target Web page parallel display (SECTra_w)

Figure 13 :

 13 Figure 13: post-edition interface in SECTra_w Incremental Improvements. Once a first version of the Web iMAG site is settled, it is possible to increase the quality of the translations during the life of the elected Web site.In the background, the iMAG could query some shared terminological resources in order to find High Quality translated segments and to transmit them to the elected Web Site.

  PHP array technique is used by many CMS coded in PHP, such as the Dotclear blogging software. This technique is very similar to the gettext technique. Message files are in the same format, but each is compiled into a PHP array instead of into a .mo file. It is possible to reuse the same message in different Web pages. Also, contrary to the gettext technique, there is no need to install the gettext tools to compile the messages files.

	$GLOBALS['__l10n']['Invalid user level'] = 'Niveau
	d\'utilisateur invalide';
	$GLOBALS['__l10n']['User password missing'] = 'Pas
	de mot de passe';
	$GLOBALS['__l10n']['User name missing'] = 'Pas de
	nom d\'utilisateur';
	$GLOBALS['__l10n']['Invalid email address'] =
	'Adresse email invalide';
	Figure 3: a PHP array with localized messages
	Advantages.

That is one of the main problems encountered by IBM-Japan when localizing the giant CATIA software.


Mohammad Daoud

Mathieu Mangeot
email: mathieu.mangeot@imag.fr

CLIR-Based Collaborative Construction of a Multilingual Terminological Dictionary for Cultural Resources

Keywords: multilingual term database, dictionary initialization, community-based translation, cross-lingual information retrieval, automatic terminology translation

We will describe ongoing work in developing a collaborative environment to construct a CLIRbased multilingual terminological dictionary dedicated to the Digital Silk Road project and web site launched and managed by NII (National institute of Informatics, Japan-Tokyo). A considerable amount of cultural resources has been digitized, including 95 rare books written in 10 different languages. In order to make them searchable and accessible easily by the visitors of the site, themselves multilingual as well, a cross lingual information retrieval system is being built. As these books are very rich in specialized terms, an important part of that endeavour is to gather these terms in many languages in a terminologicial dictionary (a database of terms contianing some information potentially usable to later build a real terminological database). For that purpose, we use a participative approach, where visitors of the online archive are the main source of the terms used in the languages they know, while multilingual online resources are used to initialize the term base through a process that depends on the archived textual data.

Introduction

The Digital Silk Road project [START_REF] Ono | Memory of the Silk Road -The Digital Silk Road Project[END_REF]) is an initiative started by the National Institute of Informatics (Tokyo) in 2002, to archive cultural historical resources along the Silk Road, by digitizing them and making them available and accessible online. One of the most important sub-projects is the Digital Archive of Toyo Bunko Rare Books [START_REF] Nii | Digital Archive of Toyo Bunko Rare Books[END_REF] where tens of old rare books available at Toyo Bunko library have been digitized using OCR (Optical Character Recognition) technology. The digitized collection contains books from different languages (English, French, Russian…), all of them related to the historical Silk Road, like the 2 volumes of the Ancient Khotan by Marc Aurel Stein, and the "Mission Scientifique dans la Haute Asie" by Jules-Léon Dutreuil de Rhins.

In this paper we are presenting our work in developing a collaborative multilingual terminological dictionary3 dedicated to these digitized resources, that will interact with a Cross-Lingual Information Retrieval system (CLIR). This companionship between the dictionary and the CLIR system will achieve two results: (1) trigger users who are browsing and searching the archive to contribute to the dictionary, (2) translate search requests using the dictionary, so that both systems will help each other.

The next section will describe the problems and show some related work, then we will propose our solution in section three. In the fourth section, we will present the design of the system and its components, and in the fifth section we will describe the process of seeding the dictionary, and present the current prototype. A conclusion and some perspectives will follow.

Problems and Related Work

Producing a domain-specific multilingual terminological database of high quality is a very difficult and complicated task, and depends heavily on human terminologists [START_REF] Cabre | Terminology: Theory, methods, and applications[END_REF].

Traditionally, this task starts by studying the domain, finding its logical elements and subdomains, then a team of terminologists starts analyzing specialized textual material to find the most relevant and interesting terms, and then teams of terminologists translate each term into the targeted languages, and they would define it, and add the necessary descriptive information, to be standardized and adopted. This approach needs a lot of resources, particularly, human resources. Only huge organizations are able to conduct such kind of work. Table 1 provides some examples of online multilingual terminological databases built and made available by large organizations and standardization bodies. As shown in table 1, the providers have mature resources and experience to build such data bases. In fact, those online systems are continuations to efforts started decades ago, and they have been compiled using material from older and existing databases.

Not only are the conventional approaches in building a multilingual terminological data base very expensive, but it is usually difficult to achieve good coverage (either informational or linguistic), especially in particular on specific domains. Besides, terminologists are more prone than domain experts to introduce inaccuracies. In this situation, a possible and (we think) necessary solution is to depend on volunteers knowing quite well the domain at hand, and let them contribute to the access multilinguization process through a collaborative environment. For example, ITOLDU [START_REF] Bellynck | ITOLDU, a Web Service to Pool Technical Lexical Terms in a Learning Environment and Contribute to Multilingual Lexical Databases[END_REF]) collected 17000 English-French terms in 20 technical domains from 250 French students (learners of Englich). Yakushite.net [START_REF] Murata | Implementation of collaborative translation environment[END_REF]) is another example, where users contribute to bilingual dictionaries (organized following a domain hierarchy)

that is used to enrich both the online Pensée machine translation system and the human translation aids. Also, Papillon [START_REF] Sérasset | Interlingual lexical organisation for multilingual lexical databases in nadia[END_REF][START_REF] Boitet | The PAPILLON project: cooperatively building a multilingual lexical data-base to derive open source dictionaries \& lexicons[END_REF][START_REF] Sérasset | A Generic Collaborative Platform for Multilingual Lexical Database Development[END_REF]) is a

Jibiki-based [START_REF] Mangeot | Dictionary Building with the Jibiki Platform. Software Demonstration[END_REF]) general purpose collaborative multilingual dictionary.

The problem with building terminological databases collaboratively is that it is difficult to attract domain experts to contribute: in the examples mentioned above, one can not expect massive contribution from normal people who are only visiting the dictionary, and one can even less expect volunteers to replace professional terminologists. A volunteer could translate a term, but s/ he may not be able to give full descriptive information about a term (its definition, usage, domain, context…), and, if s/he may, it will certainly not be in the way a professional terminologist would.

Another point to be considered is that such a database should be seeded, so that visitors can find initial data to start the contribution. For that, using online resources seems to be a very promising option. Projects such as MultiMatch [START_REF] Jones | Domain-Specific Query Translation for Multilingual Information Access Using Machine Translation Augmented With Dictionaries Mined From Wikipedia[END_REF], and PanImage [START_REF] Etzioni | Lexical translation with application to image searching on the web[END_REF]) use Wikitionaries [START_REF] Wikitionary | Wikitionary[END_REF]), Wikipedia [START_REF] Wikipedia | Wikipedia[END_REF], and other online dictionaries for this problem. A similar approach will be used in our case with the consideration of the DSR's data and needs.

3 Proposed Solution

3.1Overview

Our proposal is to build an easy to use collaborative environment where normal online archive visitors are oriented to contribute spontaneously by translating related terms in the languages they know, and possibly, what they are translating is the search terms that they use to browse the archived data.

As shown in figure 1, historical physical books have been digitized and indexed into a SOLRbased search engine. And we analyzed the output OCR text to initialize our term database.

We expect users to send monolingual search requests in any language supported by our system to get multilingual answers. Having a term base of multilingual equivalences could achieve this [START_REF] Chen | Cross-Language Retrieval Experiments at CLEF 2002[END_REF]) [START_REF] Oard | Global Access to Multilingual Information[END_REF]. A bilingual user who could send a bilingual search request could be a valid candidate to contribute, in fact the same bilingual request could be a valid dictionary contribution, and so the multilingual request. We plan that users who use our search engine will use the terminological dictionary to translate their requests and will be able to edit and add new entries to the dictionary spontaneously.

Figure 1 : general view of the proposed solution

Note that the collaborative dictionary could have at the same time direct contributors and visitors.

3.2The Online Collaborative System

The search engine we use for indexing the OCR books is Solr-Apache [START_REF] Apache | Solr[END_REF], an open source search server based on the Lucene Java search library, configurable to be used for languages other than English. Its availability and advanced features make it a good choice for our experiment. As shown in figure 2, the OCR text will be indexed to an instance of Solr. As the online archive contains scanned images and associated OCR text of each book, users could be more interested in the scanned images, while digitized OCR text can make these images searchable and improve accessibility of the books.

Figure 2 : System components and their interactions

A user will deal with the multilingual dictionary and Solr search engine through a collaborative environment that makes it possible for him to search the DSR books, translate the search requests, search the dictionary itself and add new entries to it.

Online Collaborative Environment

Search-Solr Dictionary-SOLR

Yahoo! Term Caller

Volunteers will be equipped with some online reference data and assistance such as showing the suggested translation by Google Translate [START_REF] Google | Google Translate[END_REF]) and any initial translation available in the database.

Offline tools are interacting with some online multilingual resources to prepare the initial multilingual database as we will describe later.

3.3Multilingual Dictionary Structure

Figure 3 shows the architectural design of the collaborative multilingual terminological dictionary we are developing.

User layer will interacts with users by a simple set of HTML pages and web forms that will interpret the contribution and search logic developed at the business layer.

Data Layer

Business Layer

User Layer

Solr multilingual data storage

Data validation, retrieval logic, contribution logic…

User interfaces, HTML, At the data layer, multilingual dictionary entries will be indexed into a Solr index, which will give mature dictionary lock-up facilities (provided by a powerful search engine).

Each entry will be indexed as a solr XML document, each field of the document will be configured to have different indexing and querying analyzer based on its language, here is a simple multilingual document.

Note that the structure can be changed dynamically to include any kind of information needed later. Its simplicity will make it easy for users to contribute, their contribution will be automatically transfer into an XML document and indexed into the dictionary, contributors are not required to provide descriptive information, while it is very important for a term base, it is not in the context of a multilingual search engine. In this experiment, we are trying to imitate the typical manual construction of a terminological database. This process usually contains two main time consuming steps: (1) document consultation, during which a terminologist tries to find the important terms available in a relevant set of documents, and (2) terminology translation. This process has been used to construct the initial manually developed database, which contains around 700 terms, available in up to 8 languages. In this experiment we associated these terms with our database by transforming the entries into the appropriate xml format.

Our process will do a similar job automatically, but the results will only have the status of a proposal "raw material"). Figure 5 shows the main tools and steps of our approach.

Figure 5 : the process of seeding the database

Each page of an English OCR book is sent to Yahoo! Terms [START_REF] Yahoo | Yahoo Terms[END_REF]) to find the most important terms, assuming these terms are good candidates to be in our database. After filtering them, a tool will translate them using Wikipedia.

For each term provided by Yahoo! Terms, we form a Wikipedia URL to the term's article at the English Wikipedia, for example, the term "cuneiform script" would give the following URL: http:// en.wikipedia.org/wiki/Cuneiform_script

We retrieve that article and analyze it to construct a multilingual entry. As an English article usually contain links to equivalent articles in different languages, we use these links to translate the term, and we use also the categorization information to associate a simple descriptive classification to the entry. From such an article, we find the relevant terms and we translate them again using the same method.

As a first experiment, 80000 English terms have been extracted from the historical books. More than 22000 terms have been multilingualised (they are now in 1 up to 20 languages) automatically using Wikipedia and other cultural glossaries.

Prototype

5.1Implementation

The first prototype of the system has been developed using Java Server Pages; the server is running over Apache-Tomcat 5.x. Users will interact with the system using a very simple web interface. When they will search the Digital Silk Road Archive in their own language, their request will be multilingualised and sent to the Solr search engine.

to change the translation(s) of their request, or add new translations in the dictionary. Here lies an interesting synergy between a search tool and a contribution platform.

Users can already add new terms through a very simple form where they are asked to add the translation of the term in any of the languages they know, and the system provides them with the term translated using Google Translate and other online dictionaries as well as the available translations in the local database.

The dictionary is implemented to serve as an independent entity as well: users can access it directly, search its database and add new entries.

5.2Screen shots

The first screen shot, figure 6, shows the main user interface. A user can input his search term in one of the fields corresponding to his language, and then he can translate the term into other languages to send a multilingual search request.

In the example of figure 6, a French user wrote "lapis-lazuli" into the French field and clicked on "Translate search term" to have it translated into 11 languages (the current interface shows only 11 languages). The results contain links to English, French, and German books available in our archive that contains the term lapis lazuli, or its equivalences in other languages. At any time, a user can choose to add his new suggestion.

Conclusion

In this paper we presented our work in developing a collaborative multilingual term base dedicated to a digital archive, which works as a companion to a dedicated CLIR-based system.

Building terminological multilingual databases is very expensive and complicated task; it needs resources from huge organizations, while smaller communities can not afford to build their own multilingual databases, even collaboratively, as collaborative environments are designed only for sophisticated users (mostly terminologists, which brings the problems of traditional approaches).

Ignoring the needs of normal users (likely subject matter experts) will almost surely lead to a failure. Another important problem is how to make the collaborative process attractive enough, especially for people who are interested in the community (website) itself.

The collaborative approach we are proposing and developing will consider all the contributors needs, specially the attractiveness and easiness of the contribution, by attaching the collaborative environment to a multilingual search tool, where users search requests are translated by the local multilingual database, and then they can edit the translation or add it, if it is not available.

To initialize the dictionary, we suggested a process that uses the archived data to extract the important terms and translate them from online accessible resources such as Wikipedia. As an experiment, we extracted 80000 monolingual key terms from the digitized historical books we have, using the Yahoo Term! API. After suitable filtration, we obtained translations for more than 22000 terms (into 1 up to 20 languages).

The initially developed prototype demonstrates the main functionalities of the proposed collaborative environment. Another version is under development currently, to meet all the needs of contributors and DSR's online archive visitors. In the next phase we will try to make the collaborative environment and the construction process generic and dynamic enough so that any community can create an instance of the platform and dedicate it to their needs and data. Similar communities should be helped to communicate and use their resources along with available online multilingual resources. As for the Digital Silk Road database, new languages will be added, and care will be given to languages along the Silk Road, especially to poorly equipped languages (pi-languages) and "frozen" languages like Sanskrit which was included in the first experiment.

Figure 3 :

 3 Figure 3 : 3 tiers architecture of the terminological dictionary

Figure

  Figure 4 : a multilingual entry to be indexed into Solr-dictionary

Figure 6 :Figure 7 :

 67 Figure 6 : main web interface, where users can add their search terms, and get or put their translations in the dictionary

Figure 8 :

 8 Figure 8: multilingual search results for "lapis lazuli"

Table 1 : some existing multilingual terminological online databases

 1

	Name	Number of	Languages Domain	Provider
		multilingual
		terms
	IATE (IATE 2008) 8.4 million	The 23 EU	General,	EU
		terms	official	155 domains
			languages
	UNTerm (IATE	80,000 terms The six UN	100 subjects	UN
	2008)		official	related to the UN
			languages
	FAOTerm (FAO	58,000 terms 7 languages FAO related	FAO
	2008)			domains and
				organizational
				bodies
	Electropedia (IEC	20,000 terms 9 languages electrical and	International
	2008)			electronic	Electrotechnical
				terminology in	Commission (IEC)
				75 categories
	The Great	3 million terms French,	200 categories Quebec board of the
	Terminological		English, and		French language
	Dictionary (La		Latin		(Office québécois
	Grand Dictionnaire				de la langue
	Terminologique)				française)
	(OQLF 2008)

The second author works for the National Institute of Informatics (Tokyo, Japan).

We use this somewhat unorthodox term to denote a collection of terms for concepts in some knowledge area, possibly containing information such as definitions, contexts, domains & sub-domains, and examples of use. While that information may be useful for helping readers access a specialized document in a foreign language, it is by no means of the kind and quality of what professional terminologists would put in a terminological database such as IATE (http://www.iate.europa.eu) -although they might use it as « raw material » for their work.


Mathieu Mangeot
email: mathieu.mangeot@univ-savoie.fr

Papillon project: Retrospective and Perspectives

This paper describes the first five years of life of the Papillon project with four main phases: the birth with the motivations of such a project; the extension with the decision to build a multilingual pivot dictionary; the implementation with the realization of "Jibiki", a generic dictionary management platform and the population with the use of semantic vectors for linking entries and an ongoing project: word games, for creating specific lexical information.

Introduction

This paper describes the first five years of life of the Papillon project which goal is to build a multilingual pivot dictionary with a rich microstructure. The idea is that everyone can contribute online to the dictionary. The resulting data is freely and publicly available. The paper is divided in four sections, one for each phase of the project in historic order: the birth, the extension, the implementation and the population.

Phase I, birth: a French-Japanese bilingual dictionary

2.1. History The Papillon project (first named FeJ for French-English-Japanese) [START_REF] ´ć Hristian | The papillon project: cooperatively building a multilingual lexical data-base to derive open source dictionaries and lexicons[END_REF][START_REF] Mangeot | Construction collaborative d'une base lexicale multilingue[END_REF] was launched in early 2000 by Emmanuel Planas, François Brown de Colstoun and Mutsuko Tomokiyo. Emmanuel Planas was postdoc researcher at NTT Research Centre, located in Keihanna, Japan and François Brown de Colstoun was scientific attaché at the embassy of France in Tokyo, Japan. Mutsuko Tomokiyo was a linguist Ph.D. student in Grenoble, France. They were confronted every day with the needs of a good French-Japanese dictionary. That was the starting point of the project.

The first institutional partners were the home institutions of the initiators: the GETA-CLIPS laboratory in Grenoble, France and the Embassy of France in Japan. The National Institute of Informatics (NII) also joined the project through contacts with NII researchers.

Motivations

The first motivations of the project were the following:

• Few resources The main problem is the lack of free and good French-Japanese dictionaries. The few complete French-Japanese resources are expensive, and tailored for Japanese speakers. The free lexicons available on the Web are very insufficient even for simple vocabulary (10,000 entries). Thus, the majority of French speakers have no choice but using English-Japanese dictionaries. This is also true for many other languages. Even for those with a good knowledge of English, it automatically adds confusion.

• Lack of information The most complete French-Japanese dictionaries were built for Japanese speakers, thus there is a lack of information necessary for French speakers: transliteration of kanji, numerical specifiers, etc.

• High construction costs The traditional way of building a dictionary needs lots of money and time. As an example, the construction of the EDR English-Japanese dictionary cost 1,200 human-year for about 300,000 entries in each language. The public price, 14,3 millions of yens (100,000 €) is so expensive that only companies can afford it. Furthermore, it does not even reflect the construction costs. The initiators had no choice but finding another way to build their dictionary.

•

Collaborative projects An interesting way seems to launch a collaborative project like the LINUX construction paradigm. People contribute at their level.

The result is free of rights and free so that every can benefit from it. At that time, there were already dictionaries building projects that were using this method, like the Edict Japanese-English dictionary project launched and still managed by Jim Breen for more than ten years. Now, the success of the Wikipedia project confirms our idea.

Meetings

The initiators had a user point of view of the dictionary. They were not specialists of computational lexicography. They decided to ask other researchers (mainly from GETA-CLIPS) to join the project and the decision was taken to hold the first Papillon meeting [START_REF] Tomokiyo | Papillon: a project of lexical database for english, french and japanese, using interlingual links[END_REF] at the National Institute of Informatics, Tokyo, Japan in August 2000.

Since then, we decided to organize a meeting every year.

The 2001 meeting took place in July in Grenoble. The dictionary structures [START_REF] Serasset | Papillon lexical database project: Monolingual dictionaries and interlingual links[END_REF]) were adopted during this meeting.

The 2002 meeting took place in July in Tokyo. We took there important decisions concerning the data built in the framework of the project: it is free of rights and freely and publicly available. In order to ensure a long life to the Papillon project, we organized our way of working in a way that

´ it would not depend on any specific founds. The scientific leaders are university researchers with a full time position.

The project advances also thanks to Ph.D. fellows or postdoctorate researchers whose subject integrates a scientific issue of the project. We decided also to organize every meeting as a workshop with scientific reviewing committee in parallel with an international conference so that it would be easier for researchers to obtain founds for coming.

The 2003 meeting took place in July in Sapporo. We discussed mainly about the platform used for building the dictionary.

Phase II, extension: a multilingual pivot dictionary

3.1. History

The first idea was to build a multi-target French to English and Japanese dictionary following the model of the FeM French-English-Malay dictionary. But then, the research conducted at GETA-CLIPS on pivot structures and the opportunity to open the project to many languages led us to decide to build a multilingual pivot dictionary. In the same way, we decided to use an entry microstructure based on the word sense level and very detailed in order for the dictionary to be used both by humans and by machines.

Macrostructure

The multilingual pivot macrostructure with interlingual links is based on Gilles Sérasset's Ph.D. Thesis (Serasset, 1994b;Serasset, 1994a;Serasset, 1994c) and has been experimented at a small scale by Etienne Blanc (Blanc, 1995) with the PARAX database. This structure consists in one monolingual volume for every language of the dictionary and one pivot volume in the middle see Figure 1. The monolingual volumes gathers monolingual entries at a word sense level, i.e. monolingual acceptions (called lexies). The entries of different languages are then linked between each others via interlingual acceptions (called axies) that can be seen as complex translation links. These acceptions may also be linked together by refinement links in order to cope with the semantic discrepancies between languages.

Each sense or meaning of each entry of a monolingual volume is linked to one or more acceptions of the pivot volume. For example, like in figure 2 in French " affection " has two meanings: "affection" and "disease". The vocable "affection" will consequently be linked to two "lexies" (corresponding to two word senses) in the French monolingual dictionary, which in turn will be linked to two interlingual acception or "axies" in the pivot volume. This structure, rather complex (see Figure 3) has been chosen for mainly two reasons:

1.

It has been proven language independent and thus, appropriate for any of our languages present in our dictionary. Of course, there are some parts that are language dependent such as the grammatical properties or the language levels, but the main part remains the same.

2. It has been elaborated to be theoretically used both by humans or machines.

Each lexie or lexical unit is made of a name, grammatical properties (mainly a part of speech), a semantic formula which can be seen as a formal definition. In the case of a predicative lexie, it describes the entire predicate and its After the first Papillon meeting in July 2000, Gilles Sérasset and I began to implement a more robust prototype in Java based on the specifications described in my Ph.D. thesis with the goal to obtain a generic platform for managing (querying, editing, importing, exporting) dictionaries in any structure.

In order to follow the LINUX construction paradigm not only for the data but also for the software, we chose to use only free open-source software for building the platform. Furthermore, we plan to release it in the future as a sourceforge project.

The Jibiki Platform

The Jibiki platform1 [START_REF] Mangeot | Frameworks, implementation and open problems for the collaborative building of a multilingual lexical database[END_REF], (Sérasset, 2004) is a community web site primarily developed for the Papillon project. This platform is entirely written in Java using the "Enhydra2 " web development Framework.

All XML data is stored in a standard relational database (Postgres). This community web site proposes several services:

´• a unified interface to simultaneously access the Papillon MLDB and several other monolingual and bilingual dictionaries;

• a specific edition interface to contribute to the dictionaries stored on the platform,

• an open document repository where registered users may share writings related to the project; among these documents, one may find all the papers presented in the different Papillon workshops organized each year by the project partners;

• a mailing list archive,

To encourage volunteers, we think that it is important to give a real service to attract as many Internet users as possible. As a result, we began our development with a service to allow users to access to many dictionaries with different structures but in a unified way (see Figure 4). This service currently gives access to thirteen (13) multilingual, bilingual and monolingual dictionaries, representing more than one million entries.

Figure 4: Query of "Orthographe" in three dictionaries

Every available dictionary will be queried according to its own structure from a multi-criteria search interface (see 4.2.). Moreover, all results will be displayed in a form that fits the structure. Any monolingual, bilingual or multilingual dictionary may be added in this collection, provided that it is available in XML format. With the Jibiki platform, giving access to a new, unknown, dictionary is a matter of writing two XML files: a dictionary description and an XSL stylesheet. For currently available dictionaries, this took an average of about one hour per dictionary. The description file gathers dictionary meta-information and a minimum set of information in the dictionary's XML structure. The Jibiki platform defines a standard structure of an abstract dictionary containing the most frequent subset of information found in most dictionaries. This abstract structure is called the Common Dictionary Markup (Mangeot, 2002). To describe a new dictionary, one has to write an XML file that associate CDM elements to pointers in the original dictionary structure.

. Figure 5: Multicriteria Advanced Search Interface in Several Dictionaries Along with this description, one has to define an XSL style sheet that will be applied on requested dictionary elements to produce the HTML code that defines the final form of the result. If such a style sheet is not provided, the Jibiki platform will itself transform the dictionary structure into a CDM structure and apply a generic style sheet on this structure.

The key feature: an online generic editor

The main purpose of the Jibiki platform is to gather a community around the development of one or several dictionaries. Thus, the crucial challenge that we faced was to provide a way to edit the dictionary entries directly on the platform. It was specifically difficult because we wanted to be able to edit any kind of dictionary entry (the editor had to adapt itself to the structure of the entries) and to edit them online with a simple browser (it had to be bult only with a combination of HTML forms and simple javascripts). We did not even want to use java applets because of compatibility problems. A preliminary version of the editor [START_REF] ´mathieu | Online generic editing of heterogeneous dictionary entries in papillon project[END_REF] was developed in collaboration with David Thevenin with his tool called ARTStudio for the development of adaptative plastic user interfaces. It was fragile and very difficult to handle. Furthermore, some parts of the code were not open source. Thus, a new simplified version has been recoded from scratch afterwards. The new editor works with a template XHTML interface that is instanciated with the entry that the user wants to edit. This template can be generated automatically from a description of the entry structure in XML schema. It can be modified afterwards for improving the rendering on the screen. Thus, the only data needed to edit a dictionary entry on the jibiki platform (apart from the dictionary metadata described previously) is the XML schema of the structure of the entry and furthermore, any type of dictionary entry as long as it is encoded in XML. We chose to use XML schema because it allows for a finer description compared to DTDs (for instance, we may define the set of valid values of the textual content of an XML element). Moreover XML schemata provides a simple inheritance mechanism that is useful for the definition of a dictionary. HTML forms are very limited. The available interactors are text fields, radio buttons, check boxes and pop up menus. It was not enough to be able to edit complex entries. Thus, we had to build more complex interactors from the combination of the previous ones in order to handle lists (adding,deleting, moving an item on a list) and links (links to entries in the same volume or other ones). These elements can be themselves complex objects containing lists of other objects, etc. Any user, who is registered and logged in to the Papillon web site, may contribute to the Papillon dictionary by creating or editing an entry. Moreover, when a user asks for an unknown word, he is encouraged to contribute it to the dictionary. Contribution is made through a standard HTML interface (see Figure 6). Every change made in the entry is stored in a history. It is then possible to come back to any previous version of the entry just like the usual "undo" commands. The writing process is divided in several steps depending on the project. The GDEF is the most complete with three steps:

• A contributor writes an entry; It is next revised by a reviewer;

• It is then validated by a validator;

Conclusion

The platform is now used by four different projects:

• the Papillon3 project,

• the GDEF4 project [START_REF] Chalvin | Méthodes et outils pour la lexicographie bilingue en ligne : le cas du grand dictionnaire estonien-français[END_REF], about a bilingual Estonian-French dictionary,

• the LexALP5 project [START_REF] Sérasset | Multilingual legal terminology on the jibiki platform: The lexalp project[END_REF], about a multilingual (English, French, German, Italian and Slovene) terminological database on the legal terms of the alpine convention,

• the TriDict trilingual (Sinhala, Tamil, English) dictionary.

There are still lots of ongoing developments on the platform with still a perspective of genericity in the different resources handled.

For those who want to use the platform for their projects, we are open to any collaboration. The only condition is that all the data produced with the platform must be publicly available and free of rights.

Phase IV, population: semantic vectors and word games

In order to facilitate the construction of Papillon dictionary, we decided to reuse existing data. The hypothesis are that it is easier to correct existing data than to build new data from scratch and that the public users prefer to have slightly incorrect data that no data at all when they lookup words in a dictionary. The population faces two serious issues: the building of interlingual links between the lexies and the specific lexical information that is not available in any dictionary. We decided to use semantic vectors for the first issues and word games for the second one.

Semantic Vectors

The first problem is augmented by the fact that we chose to work at the word sense level, not at the vocable level.

There is no unique way to divide a word into senses. In two dictionaries of the same language, for many entries, the division into word senses will be different. Thus, when one wants to merge the entries of two different dictionaries at the word sense level, s/he has to find a way to cope with this problem. The solution we found uses semantic vectors in order to calculate the semantic distance between two lexies of two different dictionaries we want to merge and to determine if they can be merged or not. The conceptual vectors model has been presented in [START_REF] Lafourcade | Lexical sorting and lexical transfer by conceptual vectors[END_REF][START_REF] Mathieu Lafourcade | Vecteurs conceptuels et structuration emergente de terminologies[END_REF]. Each textual segment (word, phrase, text) is linked with a thematic association that is represented by a vector of concepts.

The set of concepts is predefined and constitutes a multidimensional vector space on which the word senses can be projected.

In this vector framework, it is possible to use the notion of similarity (usually used in information retrieval) and angular distance between two vectors. It will be used as an evaluation of the thematic distance beween word senses. In order to merge lexies coming from different dictionaries, the first step is to calculate the conceptual vector that is linked to each of the lexies. For example, in French, the set of concepts is predefined with the 873 concepts of the Larousse thesaurus. The second step is to bootstrap the computation by manually indexing 5,000 terms in each language.

Then the definition of each lexie is analyzed with a morphological analyzer. Then, using the manual indexed vectors of known words and the resulting analysis tree, we compute the vectors associated to each lexie and word-form. The process is reiterated until a stability is reached.

Once the process is finished, the dictionary is "vectorized". It is then possible to merge two dictionaries of the same language by looking at the thematic distance of the conceptual vectors of each lexie. We consider that two conceptual vectors are close enough if their thematic distance is less than a threshold . The more the threshold is low, the more the lexies can be considered as being merged. Nevertheless, it may be difficult to merge completely automatically the lexies. An acceptable value for the threshold is t π .

Word Games

The issue is to find methods for building some particular crucial lexical data which is furthermore not available in existing dictionaries. It is the case for collocations coded in our entries through lexical functions. example, in English, the notion of "fever" is intensified by the adjective "strong, the notion of "smoker" by the adjective "heavy", etc. or, more particularly for asian languages, special counters must be used for specific types of objects. In Japanese, "wa" is the counter for the rabbits (usagi san wa, 3 rabbits) and "hiki" is the counter for cats (neko ni hiki, 2 cats). The goal of the project "jeu de mots" (word game) is to experiment and study the use of "word games" for building or /4 collecting precise lexical information. The idea is to generate automatically or semi-automatically word games tat can take the shape of a multiple-choice test (e.g. Is it possible to say ... in English ?) or fill-In-the-blank exercises (complete "strong fever, heavy smoker, rain") Each generated exercise will be used to complete or validate the information available in the dictionaries. Te targeted languages in this project framework are Chinese, French, Japanese, Malay and Thai. The exercises will be submitted to students and web surfers, (via the Papillon website) who will work on their mother tongue. The answers collected will be analyzed and the method will be tested and evaluated on each language. The gathered information will be publicly available on the Papillon website. This project has been accepted and funded by the French government under the STIC-Asia program driven by INRIA research organization.

Conclusion

We presented a very challenging project that is already six years old and has already produced interesting results theoretically with research on multilingual pivot structures and practically through "jibiki", an online generic dictionary management platform. We are welcoming anybody who is motivated by the project and wants to join the project. It is mainly based on voluntary work and aims to build a reference lexical resource.

Figure 1 :

 1 Figure

Figure 2 :

 2 Figure 2: Macrostructure in Detail with Interlingual Links

Figure 3 :

 3 Figure 3: Microstructure of the French lexie "MEURTRE"

Figure 6 :

 6 Figure 6: Interface for Writing an Entry

Figure 7 :

 7 Figure 7: Linking Acceptions with Vectors

see http://jibiki.univ-savoie.fr/jibiki

see http://www.enhydra.org/

see http://www.papillon-dictionary.org

see http://www.estfra.ee

LexALP: Legal Language Harmonisation System for Environment and Spatial Planning within the Multilingual Alps