Najeh Hajlaoui
email: najeh.hajlaoui@imag.fr

Daoud Maher Daoud
email: daoud@ammanu.edu.jo

Christian Boitet
email: christian.boitet@imag.fr

Methods for porting NL-based restricted e-commerce systems into other languages

Multilingualizing systems handling content is an important but difficult problem. As a manifestation of this difficulty, very few multilingual services are available today. The process of multilingualization depends on the translational situation: types and level of possible accesses, available resources, and linguistic competences of participants involved in the multilingualization of an application. Several strategies of multilingualization are then possible (by translation, by internal or external localization etc.). We present a real case of linguistic porting (from Arabic to French) of an e-commerce application deployed in Jordan, using spontaneous SMS in Arabic for buying and selling second-hand cars. Despite the distance between Arabic and French, the localization methods used give good results because of the proximity of the two sublanguages of Arabic and French in this restricted domain.

Introduction

Methods for multilingualizing e-commerce services based on content extraction from spontaneous texts depends on two aspects of the translational situation:

• the level of access to resources of the initial application. Four cases are possible: complete access to the source code, access limited to the internal representation, access limited to the dictionary, and no access.

• the linguistic qualification level of the persons involved in the process (level of knowledge of the source language, competence in NLP) and the resources (corpora, dictionaries) available for the new language (s), in particular for the "sublanguages" at hand. We first discuss the requirement in localizing the Content Extractor (CE, or content extraction module) of such an application, and an analysis of the possible methods. We then present a case study, the linguistic porting (from Arabic into French) of CATS, an application to which we have complete access, so that several multilingualization strategies are possible. In the next section, we present an "external" localization strategy which requires only access to the internal representation. Then, we evaluate this method by comparing it with the results produced by the original monolingual system. We also compare it with the "internal" localization method, which consists in adapting the existing content extractor, and has been described in another paper [START_REF] Hajlaoui | Multilinguïsation de services de gestion de contenu. IC "Ingénierie des Connaissances[END_REF].

Multilingualizing NLP-based services

We concentrate on NLP-based systems that perform specific tasks in restricted domains, Figure 1 shows the general structure of these systems. Examples of such applications and services are: categorization of various documents such as AFP (Agence France Presse) reports or customer messages on a SAS (Service After Sale) server, and information extraction to feed or consult a database (e.g. small ads, FAQ, automated hotlines).

Benefits and necessity of NL interfaces

The main benefits of building systems based on the processing of spontaneous unedited text are:

• the naturalness of interaction, • the ability of expressing complex expressions,

• the possibility (more recently) of designing and building domain-focused services based on a domain-specific thesaurus or ontology. Integrating a module processing small spontaneous task-related texts (ads, messages…) seems to be the only answer to the growing ergonomic needs, especially for e-commerce applications.

The study of the current scene shows that the deployed or operational e-commerce NL interface systems are rare and most of them are only prototypes. Furthermore, when we find an application, we get very few information about its internal procedure and how its multilinguization has been done or envisaged. Among the few we found are Pertinence Summarizer [START_REF] Lehman | Construction d'un système de résumé automatique de textes de type scientifique et technique[END_REF], a system of automatic summarization of multilingual texts, Amilcare [START_REF] Ciravegna | Adaptive information extraction from text by rule induction and generalisation[END_REF]), an adaptive system of information extraction, NLSA "Natural Language Sales Assistant", a dialogue-based system through the Web deployed by IBM, and CATS "Classifieds Ads Transaction System" [START_REF] Daoud | It is necessary and possible to build (multilingual) NL-based restricted e-commerce systems with mixed sublanguage and content-oriented methods[END_REF]), a Arabic-based SMS system for handling classified ads related to buying and selling cars and real estate.

Sublanguage and content extraction

The reasons why handling spontaneous text is difficult are similar to those encountered in speech processing: non standard grammar (more or less oral), errors (spelling, typing errors), use of some typographical conventions (SMS-specific abbreviations, smileys). Often enough, classified ads or alarms/warnings (road traffic, natural disasters) form a sublanguage which is relatively far from the general language. The consequence is that it is not possible to use the "analysis approach" and associated tools, developed for written general and clean language, even by specializing them. Rather, it seems necessary to adopt a content extraction approach, using the particularities of the sublanguage at hand.

Possible approaches to "porting"

Common need: a corpus in L2

The primary data needed for porting an application treating spontaneous texts in language L1 to language L2 is a representative corpus in L2 of the same type of data… but that is almost never available. It is hence generally necessary to create one by translation, or by simulation or imagination, and post-edition. For example, the Real Estate part of CATS treats SMS concerning Amman. To localize it to French, one should handle cities in France, Belgium, Switzerland, Canada, or Africa etc., and hence one should develop a corpus covering the various corresponding sublanguages. That would be a too expensive process. Because of that problem, we limit our ambition to porting and not localizing applications. In the case of CATS, porting to French means that French users could use CATS for sending French SMS in the same situation (real estate in Amman), so that a suitable corpus could then be created by translating and post-editing the corpus of available SMS from Arabic to French. The "good size" of the initial L2 corpus depends on the strategy used. If we adapt an existing CE, the translation of the L1 corpus used for initial development or for regular testing should suffice. If we develop an L2-L1 MT system, we might need a much larger corpus. However, a recent experiment seems to indicate that a SMT usable by the CE to work well can be developed with a rather small corpus, and a complete dictionary.

Translation

If there is no access to the code, dictionary, and internal content representation of the target application, the only possible approach to localize it from L1 to L2 is to develop an MT system to automatically translate its (spontaneous) inputs from L2 into L1. This approach might look applicable and straightforward. However, from the practical perspective it is not. As a matter of fact, for restricted domains where we have special sublanguage with specific terminology, traditional MT is not useful.

Porting or adapting a CE

Each considered application App uses a specific CRL (content representation language), say CRL_app. Several types of content representation are used, such as property lists (<attribute, value> pairs), typed features structures, logical expressions (Prolog), logico-functional expressions, objects (classes (methods, attributes), instances). Deriving a CE from one application for another one is difficult, even in the same language, because one must guarantee a minimum level of quality, correctness and completeness of the extracted content, as well as the relevance and linguistic adequacy of the produced answers. Localization at the level of content extraction can be achieved by "internal" porting or "external" adaptation.

2.3.1

Internal CE localization The first possibility consists in adapting the CE of the application from L1 to L2; but that is viable only if • the developers agree to open their code and tools,

• the code and tools are relatively easy to understand, • the resources are not too heavy to create (in particular the dictionary). That method requires of course training the localization team with the tools and methods used. Under these conditions, adaptation can be done at a very reasonable cost, and further maintenance (to "follow" the drift of the sublanguage) can later be done cheaply.

External CE localization

The second solution consists in adapting an available CE for L2 to the sublanguage at hand, and to translate its results into the target CRL_app. For a company wanting to offer multilingualization services, it would indeed be an ideal situation to have a generic CE, and to adapt it to each situation (language, sublanguage, domain, CRL, task, other constraints). However, there are still no known generic CEs of that power, and not even generic CEs for particular languages, so that this approach cannot be considered at present. A third approach is then to adapt an existing content extractor, developed for L2 and a different domain/task, or for another language and the same domain/task. We have previously experimented the first method [START_REF] Hajlaoui | Multilinguïsation de services de gestion de contenu. IC "Ingénierie des Connaissances[END_REF]) by porting the Cats part of CATS from Arabic to French: for that, we adapted its native Arabic CE, written in EnCo, by translating its dictionary, and modifying a few analysis rules. We also tried the third method, on exactly the same task, and report on that experiment in the following section.

Case study: external CE adaptation

Presentation of CATS

CATS (Classifieds Ads Transaction System) is a platform for buying and selling goods (cars, real estate…) based on the use of Arabic SMS and created by the second author [START_REF] Daoud | It is necessary and possible to build (multilingual) NL-based restricted e-commerce systems with mixed sublanguage and content-oriented methods[END_REF]. It is deployed by Fastlink (the largest mobile operator in Jordan). It is a C2C based e-commerce system that uses content extraction technology based on sublanguage analysis and knowledge representation to enable SMS users to post and search for classified ads in Arabic. It has two main functionalities: the submission for selling items and the answering of users' queries through interaction in spontaneous natural language. The system receives an entry in full text without a pre-specified layout, recognizes the various relevant entries, and produces a knowledge representation for further processing. We have two types of users' requests:

• "Sell" post: in which the user is a potential seller.

• "Looking for" post: in which the user is a potential buyer.

Table 1 shows some examples of the car domain, for which we are interested in a first time.

Looking The overall structure of the CATS reflects both the corpus analysis and the adopted knowledge representation. The CATS system consists of a content extraction (CE) component and a query manager QM component. The CE component receives SMS text and decodes it into the corresponding knowledge representation CRL-CATS using a domain-specific lexicon. The system is able to extract knowledge from both types of messages. The QM component takes the KR and converts it into SQL statements. It also issues the SQL statements (query or insert), and checks, validates and formats the results. It also handles situations where no answer found. One important aspect of this design is that both questions and postings (documents) are processed by the same engine, using the same knowledge representation, leading to accurate matching of questions with answers. CE is written in EnCo (Uchida and Zhu 1999) and uses a lexicon specific to the domain and a grammar specific to the sublangage. In CRL-CATS (Content Representation Language for CATS), a posted SMS is represented as a set of binary relations between objects. It is a kind of semantic graph with a UNL-like syntax. There are no variables, but the dictionary is used as a type lattice allowing specialization and generalization.

In the preceding example, there is one object, a car (saloon), with 4 properties. The first is sal (type of post, selling or buying, here sale for selling). The other properties are mak (make), with value RENAULT (country<France,country<europe), mod (model), with value Megane(country<France, country< europe,make<RENAULT), and yea (year), with value 2000.

Necessity of an "initial" corpus

For all localization methods of the CATS system into French, the first thing to do was to collect or build a "French starting corpus", similar to that used by Daoud at the beginning of his project for Arabic. That was obviously necessary to study the syntactic form of the SMS to be treated in French, and to see also which lexical categories to expect. Initially, we used an Arabic corpus generated by CATS and translated it into "French spontaneous SMS", expected to be sent (in Jordan) by French-speaking people. A rough translation produced by a non-French person is generally very different compared to a natural and functional translation produced by a French person, i.e. compared to what a French person would say in a spontaneous way in the same situation. We evaluated this translation difference between rough/literal and natural/functional translations by calculating the edit distance between two translations. The average distance is 21,88 [START_REF] Hajlaoui | Recherche et production de corpus de messages pour la multilinguisation de sites de e-commerce en SMS, initialement en arabe[END_REF], for an average length of 66 characters.

In order to develop this corpus, we adopted the following technique: starting from the ads model constituted by 50 types of SMS revised and considered to be functional, we multiplied the number of these ads by forming different combinations of properties and values (make, model, year, colour, price…). For example, we replace a year by another (je cherche une voiture modèle 98) → je cherche une voiture modèle 99…) or a make by another (A vendre BMW rouge → A vendre PEUGEOT noire).

External localization

We adapted an existing French extractor of 31,918 lines written in Tcl/Tk by H.Blanchon for the Nespole! project [START_REF] Blanchon | Comment définir, mesurer et améliorer la qualité, l'utilisabilité et l'utilité des systèmes de TAO de l'écrit et de l'oral. Une bataille contre le[END_REF], and producing IF (Interchange Format) representations. The IF is a semantico-pragmatic pivot used for restricted domains. The second step was then to translate the IF expressions into CRL-cats graphs. The IF is a semantico-pragmatic pivot used for restricted domains. Figure 3 shows the IF specification components: speech act, concept and arguments. In the beginning of this adaptation, we have the code of the second demonstrator, the paper and electronic version of the IF specification (version of 08-18-2002) and the CRL-CATS specification.

;the week of 12, we have simple and double rooms available

IF and French-IF CE adaptation

We adapted the IF specification to the Cars domain. We also enriched it by adding new arguments like vehicle-motor-type, vehicle-hand, etc. We added new actions, essentially the buying action e-buy and the selling action e-sell. We used the same stages to extract information about the Cars domain. We tried to eliminate the instructions which posed problem and/or which were not necessary to reduce the computing time. We added new instructions related the added arguments and actions. Most of the work was done on the arguments instantiation stage related to the vehicle domain: we instantiate the vehicle specification vehicle-spec, as well as other less interesting arguments such as: We call the obtained result "IF-CATS" (output1 in the example). We built a compiler, which analyses and transforms the IF-CATS expressions in CRL-CATS graphs by using an "IF-CRL" dictionary which facilitates the substitution of the arguments.

3.3.3

Compiler IF-CATS_CRL-CATS We built a compiler, which analyses and transforms the IF-CATS expressions in CRL-CATS graphs by using an "IF-CRL" dictionary which facilitates the substitution of the arguments. Figure 6 gives the same result of the CRL-CATS protected by the compiler. It is the same result as that of Figure 2. It shows that it is possible to obtain the same CRL-CATS format as that produced by the EnCo 1 tool, except for the symbols 00, 0J, 0R which are added by the EnCo tool. We translated manually the corpus used for the evaluation of CATS Arabic version (original). We computed the recall R, the precision P and the F-measure F for each most important property (action "sale or buy", "make", "model", "year", "price"). P = number of correct entities identified by the system/ total number of entities identified by the system; R = number of correct entities identified by the system/ total number of entities identified by the human; F = 2PR/(P+R) Table 2 summarizes the results obtained and Table 3 shows details [START_REF] Hajlaoui | Portage linguistique d'applications de gestion de contenu[END_REF]. Properties having numbers as values, like price and year, lower the percentage of porting by external adaptation, but the advantage is that that method requires only to access the internal representation of the application.

Conclusion

We have presented several possible methods for "porting" applications based on handling the content of spontaneous NL messages in a "native" language L1 into another language, L2. In a previous paper, we described an experiment and an evaluation of the "internal" strategy, consisting in adapting the native CE (content extractor) to L2.

Here, we reported on another case study, in which we experimented the "external" strategy, consisting in adapting an existing CE for L2 to the domain and to the CRL (content representation language) of the target application. The evaluation was done similarly, on the same part of the CATS system, Cars, to port it from Arabic to French. Porting by translating messages from L2 to L1 (here from French to Arabic) has also been done, and its evaluation is also given. An interesting conclusion of these experiments is that, in a real case of linguistic porting, all three localization methods used gave good results. The most likely reason for that seems to be that, although Arabic and are quite distant as "general languages", their considered sublanguages are quite similar. That corroborates the analysis made by [START_REF] Kittredge | Analyzing Language in Restricted Domains[END_REF]).

Figure 1 :

 1 Figure 1: general structure of NLP-based systems

  :00,sale:00) mak(saloon:00,RENAULT(country<France,county <europe):07) mod(saloon:00,Megane(country<France,country <europe,make<RENAULT):0C) yea(saloon:00,2000:0K) [/S]

Figure 2

 2 Figure 2: a CRL-CATS representation

Figure 3 :

 3 Figure3: content extractor for French in tourism domain[START_REF] Blanchon | Comment définir, mesurer et améliorer la qualité, l'utilisabilité et l'utilité des systèmes de TAO de l'écrit et de l'oral. Une bataille contre le[END_REF]

Figure 4 :

 4 Figure 4: structure of French analysis module into IF for the NESPOLE second demonstrator[START_REF] Blanchon | Comment définir, mesurer et améliorer la qualité, l'utilisabilité et l'utilité des systèmes de TAO de l'écrit et de l'oral. Une bataille contre le[END_REF]

  Figure 5: result of content extraction on a French SMS

;Figure

  Figure 6: an IF-CATS_CRL-CATS compiler result

  Figure 7 allows to better visualize the comparison between the values of F-measure found for each version of the system.

Figure 7 :

 7 Figure 7: comparison between F-measures

Table 1 :

 1 examples in the cars domain

	for
	Honda, model 97,
	price between 3500
	and 3750
	Looking for sport
	car
	I want Mercedes
	car model 82 white
	color
	Opel Vectra car for
	sale year2000 full
	option
	For sale BMW 520
	color dark green
	full check year 89
	full except sunroof
	licensed in a good
	condition with a
	price 8500.
	Opel Astra station
	color red (power
	sunroof Center
	Electrical windows
	and mirrors check
	for sale
	I have a Land
	Rover car I want to
	sell it
	Wanted a Peugeot
	406 car
	In need for a car
	not more than 2000
	dinar in good
	condition and
	economical in fuel.
	Buying a car
	I want to sell a
	Daewoo Lemens
	car year 92 full
	check full option

Table 3 :

 3 comparison between result of content extraction

Acknowledgments

We would like to thank our reviewers, who made many constructive remarks and suggestions, which we gladly incorporated in this new version of the paper.


Najeh Hajlaoui
email: najeh.hajlaoui@imag.fr

Localizing content management application for spontaneous textual utterances in natural language

Keywords: Localization, spontaneous texts, Content Extraction, SMS (Shorts Messages Services), CRL (Content Language Representation)

The multilinguisation of content management services is an important but difficult problem and very few services do it. In fact it depends on the translation situation: types and level of possible accesses, available resources, linguistic competences of participants in the multilinguisation of application. Several strategies of multilinguisation are then possible (by translation, by internal or external localization etc.). We illustrate this study by a real case of linguistic porting (Arab to French) of an E-commerce application deployed in Jordan, using texts of spontaneous SMS for buying and selling second-hand cars. In spite the long distance between Arabic and French, the localization methods used give good results because of the proximity of the two sublanguages of Arabic and French.

Introduction

Multilinguisation of E-commerce services using spontaneous texts in natural language is an important but difficult problem, and very few services do it. It depends on two principal factors on the translation situation:

• The access level to resources of the initial application, four cases are possible: complete access to the source code, access limited to the internal representation, access limited to the dictionary, and any access.

• The linguistic qualification level of participants in the multilinguisation of the application, which can be defined by knowing or not the source language, or by the linguistic abilities of the team in charge for the localization (specialist or not in NLP). We present primarily the requirement in localization of content extraction application followed by an analysis for the possible methods. Then, we illustrate our study by the linguistic porting (from Arabic into French) of an E-commerce application for which the two factors presented above are assured, and several strategies of multilinguisation are then possible. We present a strategy of localization called "external" which requires a simple access to the internal representation. Then, we evaluate it results compared to the results given by the original version system and by another localization method called "internal", which consists adapting the existing content extractor. This internal method is described in an other paper submitted.

1 Multilinguisation of content management services is a important and difficult problem and very few services do it

Requirement in localization for content extractor in natural language

The characteristics of the applications, which we are interested in primarily, are those of the E-commerce, and those that give added value by the processing of the content. Main types of applications and services are : categorization of various documents (messages of AFP "Agence France-presse", messages of customers on a SAS "Service After Sale" server,…) : "Who is interested by what", information extraction to feed or consult a data base (example: small ads, FAQ "Frequently Asked Questions", automated hotlines).

Increasing importance of offering multilingual services

Offering a multilingual service is a necessity for deployment in many countries. For example, CISCO society (http:// www.cisco.com/) is obliged to use translation systems to (badly) translate its documentation. Indeed, the call centres are overloaded, and they are very expensive. This example shows the necessity of local multilingual services : of course, in multilingual countries (Canada, India, US), but also in monolingual countries (France) because of tourism and new mobility.

In spite of the interest of spontaneous utterances processing, few services do it

Interest

The interest of a spontaneous utterances processing service is summarized in the following points:

• Naturalness of interaction,

• Possibility for the users of expressing anything, whereas forums and menus, in modal character, do not allow it, • Possibility (more recently) of building and let evolve the design domain-focused service (thesaurus ontology job). A service of spontaneous texts processing (ads, messages…) can be an answer to a technical and ergonomic need, especially in the E-commerce domain. Menu-driven navigation and keyword search provided by most commercial sites have tremendous limitations, as they tend to overwhelm and frustrate users with lengthy and rigid interactions. User interest in a particular site decreases exponentially with the increase in the number of mouse clicks [START_REF] Huberman | Strong Regularities in World Wide Web Surfing[END_REF]. Hence shortening the interaction path to provide useful information becomes important. Many e-commerce sites attempt to solve the problem by providing keyword search capabilities. However, keyword search engines usually require that users know domain specific jargon, so that the keywords could possibly match indexing terms used in the product catalog or documents. Keyword search does not allow users to precisely describe their intentions, and, more important, it lacks understanding of the semantic meaning of the search words and phrases.

Few services treat spontaneous texts, even in monolingual context

After having interrogated several search engines (Google, AltaVista, Tiscali…) on the subject of processing spontaneous texts in natural language applications, we obtained very few positive results. When we found something, we had very few information about internal procedure and their multilinguisation. We passed as request, several and various keywords (localizing natural language message processors, localization NLP free text, localization NLP interfaces, multilingual customer message processsing, multilingual customer messages tools, multilingual customer relationship processing, multilingual NLP e-commerce, multilingual online sales customer support, multilingual online sales NLP customer support, categorizing natural language message, handling natural language messages in business, Natural Language Conversational Interface in Online Sales…).

It seems that there are still very few ! Few applications or theories correspond even partially to our request, like Pertinence Summarizer [START_REF] Lehman | Construction d'un système de résumé automatique de textes de type scientifique et technique[END_REF]) -a software of automatic summary of multilingual texts -, Amilcare [START_REF] Ciravegna | Adaptive information extraction from text by rule induction and generalisation[END_REF]) -an adaptive system of information extraction -, NLSA "Natural Language Sales Assistant" -a dialogue-based system through the Web deployed by IBM -and still better CATS "Classifieds Ads Through SMS" [START_REF] Daoud | It is necessary and possible to build (multilingual) NL-based restricted e-commerce systems with mixed sublanguage and contend-oriented methods[END_REF]) -a Arabic-based SMS system for buying and selling cars and real estate.

Possible reasons (why few services treat the spontaneous texts in

natural language) Our hypothesis on possible reasons for which very few services process spontaneous texts in natural language is that this work has inherent difficulties and that their multilinguisation creates large problems. These are similar to problems encountered in speech processing: "not standard" grammar (more or less oral), errors (spelling, typing errors), use of typographical conventions suitable for the context (ex SMS, chat, emotion, abbreviation). Often enough, we are in a "sublanguage" relatively far from the "general language", as small ads or alarms/warnings (road traffic, natural disasters). In general, we can not use tools made for written "general" and "clean" language. It is necessary to "translate" spontaneous texts in natural language into a "content representation " formalism and in most cases, an application has its own formalism.

Necessity of a specific approach to each sublanguage and inefficiency of tools made for the general languages

Applications processing spontaneous texts in natural language generally use a content representation. We find several forms of content representations like lists <attributes, values>, structures of typed features, logical expressions (Prolog), logico-functional expressions, objects (classes (methods, attributes), instances). For example, the CATS system uses a representation like Propriety = colour {object = saloon, value = blue } for selling and buying second-hand cars. Often, an application has its own formalism. Adapting or porting a "content extractor" from one application to another is difficult, even for the same language, because it is necessary to be able to guarantee a minimum level of quality, correctness/completion of the content extraction, relevance of produced answers (processing + management) and linguistic adequacy of these answers. The primary data to provide for a linguistic porting of an application treating spontaneous texts in natural language is a corpus of the same type of data, which is not always obvious to find. It is generally necessary to work by simulation/imagination and adaptation. For example, CATS treats real estate SMS in Amman. But to adapt CATS into French supposes to choose a city in France, Belgium, Switzerland, Canada, or Africa… And when we want to port into languages unknown to the developers and owners of the application/service, that becomes very expensive. Generally, the "sublanguage" used (naturally) is relatively far from the "general language". Consequently, the existing tools (Machine Translation or Content Extraction tools) made for the "general language" do not work. Under these conditions, specific approach to each sublanguage is then essential.

Reflexions about possible approaches

By translation

A first idea consists in translating spontaneous texts from L2 language into the original language L1 of the application to be located. The translation and the revision of an existing corpus then the adaptation to the corresponding sublanguage in the other language, can help the localization operation and especially enable to create an initial version of corpora, but the automatic translation systems are not available for all language pairs. Very far from there, they are useful only for "clean" texts and does not work with spontaneous texts. Adding the construction of a targets corpus problem to allow the evaluation of the porting operation. As an example, for artisanal development, we can take training words, but difficulty which arises moreover, it is how to define the "good size of corpus". The idea of realisation of an automatic translation system for spontaneous texts is not impossible but several questions arise: which type of system? Which size of resources must we have?

Creation a statistical system

For the case of the statistical systems, two main problems have to be solved:

• Estimation of the bilingual corpus size necessary according to the estimated "proximity" of the native and target sublanguages. • Construction of this corpus. The experiment can start with a minimal size under the effect of the sublanguages proximity.

Creation a symbolic system (dictionaries, rules, heuristic)

The advantage of the creating a symbolic system based on heuristic, dictionaries, and rules is that it can be very small and developed in a few weeks. On the other hand, the major disadvantage is that it is necessary to have a linguist expert specialist of the concerned language.

By realization of a new content extractor for each concerned language

The realization of new content extractor can be done by several methods. The first solution is to adapt the existing content extractor from L1 to L2, but that is viable, only if

• the developers agree to open their code/tools to cooperate with collaborators • This code/tools is also easy to understand • The resources are not too heavy to create (in particular the dictionary if there exists) • Maintenance then can be done at simple cost, by simple collaborations. This method of "internal localization" of native content extractor requires of course a training of the localization team with tools and methods used. The second solution would consist, for a company wanting to offer multilinguisation/porting services. The idea is to implement a generic content extractor and to adapt it to each situation (languages, sublanguage, domains, CRL "Content Represntation Language, task, constraints). We will see in the following part that seems very difficult to consider currently. In several contexts, "contributors" in multilinguisation task haven't access to application content extractor, nor to an "universal" content extractor. In this case, a third solution could then be to find and to adapt an existing and available content extractor, it can be for the same concerned language L2, with a different domain/task, or it can be for another language (different to L2) but with the same domain/task. We illustrate the first method by a real case of linguistic porting (Arabic to French) of CATS system by adapting their content extractor, initially envisaged for Arabic SMS. This method is called "internal adaptation" and it is described in other paper to be published. We illustrate the third method by a real case of linguistic porting (Arabic to French) of CATS system by an "external adaptation". It consist to adapt another existing content extractor and to translate the results in the CATS content representation formalism. This method requires a simple access to the internal representation. We describe this method in the following section.

3 Illustration: localization of the CATS system (Arabic-based to French) 3.1 Presentation of CATS CATS (Classifieds Ads Through SMS) is a platform for buying and selling goods (cars, real estate…) based on the use of the Arabic SMS and created by Daoud. It is deployed by Fastlink, the largest mobile phone operator in Jordan. Although there is no direct transaction, it helps the users to sell and to buy by putting them in contact. These SMS are sent to a single special number and are recorded automatically in a data corpus. Their texts are analysed and an answer is sent automatically to the sender of the SMS if the request corresponds to one or more proposals. If nothing is found, the system says it in its answer, and resends the request later when the data base changes. The structure of CATS is summarized in two main components: a Content Extractor "CE" and a Query Manager "QM". CE receives the SMS and decodes their texts into a CRL-CATS representation (Content Representation Language) by using lexicons specific to the domain. CRL-CATS is a Property {object, value} representation.

;Selling Renault Megane m 2000 In the preceding example, the second property is make (mak), the object is a car (saloon) and the value is equal to (RENAULT(country<France,country<europe)). For the property model (mod), the object is a car (saloon) and the value is equal to (Megane(country<France,country<europe,make< RENAULT)). For the property year (yea), the object is a car (saloon) and the value is (2000). The QM converts the CRL-CATS representation into a SQL text (selection request for the buying and/or insertion request for selling). It treats also the situations in which no answer is found.

Necessity of starting corpus

For all localization methods of CATS system into French, the first thing to do is to collect or build a "French starting corpus", similar to that used by Daoud at the beginning of his project for Arabic. That was obviously necessary to study the syntactic form of the SMS to be treated in French, and to see also which lexical categories to expect. A first idea is to use the CATS corpus in Arabic and to translate it into "French spontaneous SMS", supposed to be sent (in Jordan) by French-speaking people.

A rough translation produced by a non-French person is generally very different compared to a natural and functional translation produced by a French person, i.e. compared to what a French person would say in a spontaneous way in the same situation. We evaluated this translation difference between rough and natural or literal and functional by calculating the edit distance between two translations. The average distance is 21,88 [START_REF] Hajlaoui | Recherche et production de corpus de messages pour la multilinguisation de sites de e-commerce en SMS, initialement en arabe[END_REF]. The distance used is the minimal number of suppressions, insertions or replacements of letters necessary to transform a rough (or a literal) translation into a natural (or a functional) translation. We showed in a precedent paper [START_REF] Hajlaoui | Recherche et production de corpus de messages pour la multilinguisation de sites de e-commerce en SMS, initialement en arabe[END_REF]) that direct translations of a real corpus of natural sentences can not give natural results. Taking this hypothesis, we tried to produce a small French corpus functionally equivalent to the Arabic initial corpus.

In order to develop this corpus, we adopted the following technique: starting from the ads model constituted by 50 types of SMS revised and considered to be functional, we multiplied the number of these ads by forming different arguments combinations used (make, model, year, color, price…). For example, we replace a year by another (je cherche une voiture modèle 98 ) → (je cherche une voiture modèle 99…) or a make by another (A vendre BMW rouge) → (A vendre PEUGEOT noire)…

External localization

An external localization method consists in adapting an existing and available content extractor, for the same language (French), but to change the domain (from tourism to automobile). Concretely we adapted an existing French extractor of 31 918 lines of code in Tcltk, created by H.Blanchon for the Nespole! project [START_REF] Blanchon | Comment définir, mesurer et améliorer la qualité, l'utilisabilité et l'utilité des systèmes de TAO de l'écrit et de l'oral. Une bataille contre le bruit, l'ambiguïté, et le manque de contexte[END_REF]). In his work, Blanchon used the IF "Interchange Format" representation. The IF is a semantico-pragmatic pivot used for restricted domains. In the NESPOLE! project, the passage to the IF pivot uses a method based on the relevant sequences recognition automat. The following figure shows the IF specification components: speech act, concept and arguments. In the beginning of this adaptation, we have the code of the second demonstrator, the paper and electronics version of the IF specification (version of 08-18-2002) and the CRL-CATS specification.

;the week of 12, we have simple and double rooms available Figure 1 : content extractor for French in tourism domain [START_REF] Blanchon | Comment définir, mesurer et améliorer la qualité, l'utilisabilité et l'utilité des systèmes de TAO de l'écrit et de l'oral. Une bataille contre le bruit, l'ambiguïté, et le manque de contexte[END_REF]

Content extraction method in Nespole!

We tried to understand and use the method used in the second module. As the following figure shows, the method used for the analysis (French to IF) has the following stages:

• Segmentation in SDU (Semantic Dialogue Units).

• Detection of the domain.

• Construction of speech acts prefix and instantiation of dependent arguments.

• Instantiation of arguments related to domain and management of subordinations.

• Complementation of speech acts

Adaptation of the IF into IF-CATS and of the French-IF code

We adapted IF specification to the cars domain. We also enriched it by adding new arguments like vehicle-motor-type, vehicle-hand… We added new actions, essentially buying action e-buy and selling action e-sell. We used the same stages to extract information about the cars domain. We tried to eliminate the instructions which posed problem and/or which were not necessary to reduce the computing time. We added new instructions related the added arguments and actions.

Much work was done in the arguments instantiation stage related to the "vehicle" domain: we instantiate essentially vehicle specification "vehicle-spec", as well as other less interesting arguments such as: theDistance, theLocation, theDuration, theDestination, theTime, thePrice… A VehicleSpec2If function allows research and construction of the arguments related to "vehicle" concept. The only argument which was programmed in the second demonstrator code is "frenchvehicle", which can have value as "voiture, ski, camion, bus, train, avion… " Other arguments exist in initial IF specification, but they are not programmed, such as: "makevehicle, modelvehicle, sizevehicle, frenchcolor, agevehicle, pricevehicle" In the same way, the Argument2if function builds the IF associated values. The following figure is an example of result obtained after adaptation. We call the obtained result "IF-CATS" (sortie1 in the preceding example).

Compiler IF-CATS_CRL-CATS

We built a compiler, which analyzes and transforms the IF-CATS result in the CRL-CATS format by using a "IF-CRL" dictionary related to this structure, which allows the substitution of the arguments. The following figure gives an example of the result of the compiler. It shows that it is possible to obtain the same CRL-CATS format as that produced by the EnCo 1 tool, except for the symbols 00, 0J, 0R which are added by the EnCo tool (Figure 1 is an example produced by EnCo).

; I want to sell a Renault clio mod 1998

1 EnCo is a tool based on rules and dictionaries used for content extraction in originale version of CATS system. We computed the recall R, the precision P and the F-measure F for each most important property as follows (action "sale or buy", "Make", "Model", "year", "price"): P = number of correct entities identified by the system/ total number of entities identified by the system; R = number of correct entities identified by the system/ total number of entities identified by the human; F = 2PR/(P+R)

Results

The percentages of porting by internal adaptation (compared to the original version) vary between 95% and 100%, with an average of 98%. The percentages of porting by external adaptation (compared to the original version) vary between 46% and 99%, with an average of 77%.

Let us note that properties treating the number like price and years that make low the value of porting percentage by external adaptation, but its advantage is it requires a simple access to internal representation of the application.

Conclusion

We chose CATS, as application to be located because it is a platform treating spontaneous SMS in naturel language, which we have access to all its resources. We presented a "external" localization method, which requires a simple access to the internal representation of the application, it gives good results because of the proximity of the sublanguages.

Figure 1 :

 1 Figure 1: example of CRL-CATS representation with its English translation

Figure 2 :

 2 Figure 2 : Structure of French analysis module into IF for the NESPOLE second demonstrator[START_REF] Blanchon | Comment définir, mesurer et améliorer la qualité, l'utilisabilité et l'utilité des systèmes de TAO de l'écrit et de l'oral. Une bataille contre le bruit, l'ambiguïté, et le manque de contexte[END_REF]

Entrée 1 =

 1 Figure 3 : example of result of the content extractor for French SMS

Figure 4 :

 4 Figure 4 : an example of IF-CATS_CRL-CATS compiler result

Tableau 1 :

 1 comparison between result of content extractionThe following figure allows to visualize better the comparison between the values of Fmeasure found for each version of the system.

Figure 5 :

 5 Figure 5 : comparison between F-measure

standard page = 250 words