ࡱ>  VGHIKL)Root Entry111111111111111111111 F1111z~@11Data111111111111111111111111111 111111111111111111.111Table17P   T WordDocumentFGH I J    x  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~6      !"#$%&'()*+,-./012345M789:;<=>?@ABCDEFJNSOPQR]TUWXYZ[\^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'-/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry111111111111111111111 F1111r} @11Data111111111111111111111111111 111111111111111111.111Table17P    WordDocumentFGH I J    %v  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~SummaryInformation   (   DocumentSummaryInformation8P7P7`P711CompObj7P77` 77`X7`0TableP7`P,f personal multilingual high-quality communication over the Internet, our challenge is to go from the LIDIA mockup to a real system relying on a huge lexical database. Second, we have started a long term project in Speech Translation (ST), and concentrate first on the French part of CSTARII demonstrators, to show that useful ST systems can be obtained by integrating admittedly imperfect speech recognition and machine translation components in a communication environment permitting limited user control and multimedia feedback. In both projects, we reuse the Ariane-G5/LIDIA software, with some new developments: (1) for UNL, we are building a multilingual database to generate Ariane and interactive disambiguation dictionaries, and filters between UNL graphs and Ariane-trees; (2) our first CSTAR prototype uses http access to Ariane-G5, and MT starts from a phonetic word lattice output by the speech recognizer. In both projects, we also reuse the LIDIA multilevel pivot approach, where linguistic structures contain a lexical level of interlingual acceptions, but the analysis strategy is heuristic for CSTAR and all-paths as in LIDIA for UNL, and interlingual acceptions are of a different nature. Basic software tools and linguistic methodology for multilingual MT-R Research in MT has been pursued at Grenoble since 1961. At the end of the first period, around 1967-70, a first Russian-French system had been developed, and tested on more than 400,000 running words of real texts (scientific articles). The aim was MT for the watcher, or pure MT, or MT-W, where a fully automatic process produces unrevised rough translations good enough that the reader, assumed to be a specialist of the domain, can access the content of the original without knowing the source language. Such translations are often judged to be very bad by professional translators and very good by users. Almost all PC-based current systems are of this kind. Due to a change of computer system (IBM 7044 to IBM 360/67), which would have necessitated an important conversion hardly justifiable without the prospect of immediate operational use, this first system was abandoned, despite its remarkable quality and coverage. This was the occasion to start exploring new ideas in the context of MT for the revisor, or MT-R, which aims at automatically producing raw translations designed to be revised by a professional in order to get final results of professional quality. As the step of human revision must naturally be performed on a computer, MT for the translator (machine aids for human translation and revision) was also studied. In 1978, a new methodology for linguistic programming had been formulated by B.Vauquois (multilevel transfer approach, heuristic programming), and began to be tried on various language pairs, with a large effort on Russian-French, using the components of the first ever (and maybe still unique) comprehensive MT shell, that is to say, a computer environment for the development and use of multilingual MT systems, which was called Ariane-78 at the beginning of 1978, when its first complete version became available. Incidentally, this name was chosen several months before it became also used for the European rocket. It was meant as a reference to the Greek goddess and her famous thread, in order to stress the idea that computer science, even if essential, must be put to the service of linguists and lexicographers who are not computer scientists and allow them to work autonomously, thanks to symbolic, rule-based, specialized languages for linguistic programming (SLLP) and to a transparent interactive user interface. Thanks to support from CNRS and DRET (Ministery of Defense), a first full-sized preoperational Russian-French system was developed and tested, from the beginning of 1980 to the end of 1986. In parallel, an effort in technological transfer towards industry was undertaken, in particular in the framework of the Machine-Aided-Translation National Project (CAT-NP, or PN-TAO in French, 1983-87  ADDIN ENRef [7]). GETA augmented considerably the power and reliability of Ariane-78.4, and was at the heart of the linguistic specification of the French-English system for aircraft manuals built in cooperation with industrial partners. Since then, the Ariane system has been considerably extended  ADDIN ENRef [10]. The first section describes it in some detail, to show that such an MT shell is rather complex. In the second section, we show how linguistic programming techniques in MT have changed from the stage of workmanship to that of real engineering. This has in turn led to the development of new tools associated with Ariane-G5 and to the evolution of the linguistic methodology (static grammars). In order to give a concrete overview of the linguistic methodology and of what modern MT for the revisor can produce, this section also presents several raw (unrevised) industry-oriented translations produced by B'VITAL's Ariane/aero/F-E system after 3 years of development. Ariane-G5, an MT shell for building multilingual MT-R systems General principles Ariane-G5 is a generator (G) of MT systems based on five (5) specialized languages for linguistic programming (SLLP). Each such language is compiled. The internal structures produced by its compiler are used as parameters by its engine. The complete documentation, in French, is available at GETA ( ADDIN ENRef [6] and later additions). Large parts are available in English and in Chinese (translation by the JTMAT group at Shanghai Jiao tong University). Although Ariane-G5 is particularly well adapted to the transfer approach and to heuristic analysis and generation, it does not impose them. Apart from some implementation limits, the only strong constraint is that the structures representing the units of translation be decorated trees. Intrinsic semantics (a term borrowed from J.P.Descls) is represented in these languages, hence in a linguistic fashion. If one wants to write a system specialized to a restricted sub-language and to a microdomain, it is possible to use the same technique as for METEO  ADDIN ENRef [21] and to write semantic grammars and dictionaries. In order to construct a system equipped with extrinsic semantics (ontology of the universe of reference), it would be necessary to couple Ariane-G5 with an expert corrector system, as suggested and prototyped in  ADDIN ENRef [28]. As opposed to almost all existing systems, Ariane-G5 presents the advantage that the unit of translation is not restricted to the sentence, but may contain several paragraphs (in general, 100 to 200 occurrences, i.e., almost a standard page). Hardware and software environment Ariane-G5 runs under VM/ESA/CMS, on IBM computers with 390 architecture (a 9221-130 at GETA, PS-2 with 390 card). Since 1993, it is accessible through the Internet. VM/ESA is a hypervisor which simulates a set of virtual machines. Each virtual machine runs under its own operating system. For example, it is possible to let virtual machines run at the same time under MVS/TSO, CMS, and AIX. The RSCS subsystem allows one to organize the virtual machines and the real resources (peripherals) as a network. CMS is a powerful interactive single-user operating system, which supports a large number of programming languages and tools. It is generally used for software development or for interactive applications. The current version of Ariane-G5 represents about 400,000 source lines, plus 30,000 lines of messages for each dialogue language. The executable part resides on a minidisk (virtual disk) of a particular virtual machine, and takes about 10Mb. To allow another virtual machine to be a user machine (of Ariane), one simply performs a logical connection (as B/A) of Ariane's minidisk to the machine's minidisk (A). From then on, Ariane manages on the user minidisk two specialized data bases, one containing the lingware and the other the texts (with a maximum of 3,000 source and target languages, 1,000 corpora and 10,000 texts per corpus). The minimal computer background necessary to use Ariane-G5 consists of learning the elementary commands for beginning and ending a VM/ESA session (login, logout), the XEDIT screen editor, and, for the developers of MT systems, the organization of the interactive monitor and the SLLPs. Logical organisation Steps, phases and articulations of the translation process Translation from a source language into a target language is performed in three successive steps: analysis, transfer and generation. Each step is realized in at least two and at most four successive phases, possibly linked together by articulations, which may be considered in first approximation as simple coordinate changes". Each phase is identified by a two-letter mnemonic (e.g. AM for morphological analysis analyse morphologique in French), and each articulation by a four-letter mnemonic (e.g. AMAS for the AM-AS articulation). In analysis, the successive phases are: AM (morphological analysis) obligatory, written in ATEF; AX (expansive analysis X) optional, written in EXPANS; AY (expansive analysis Y) optional, written in EXPANS; AS (structural analysis) obligatory, written in ROBRA. In transfer, the successive phases are: TL (lexical transfer) obligatory, written in EXPANS; TX (expansive transfer X) optional, written in EXPANS; TS (structural transfer) obligatory, written in ROBRA; TY (expansive transfer Y) optional, written in EXPANS. In generation, the successive phases are: GX (expansive generation X) optional, written in EXPANS; GS (syntactic generation) obligatory, written in ROBRA; GY (expansive generation Y) optional, written in EXPANS; GM (morphological generation) obligatory, written in SYGMOR. In the current version, the order of these phases within each step is fixed. Hence, the possible articulations, all written in TRACOMPL, are AMAX, AMAY, AMAS, AXAY, AXAS, AYAS, ASTL, then TLTX, TLTS, TXTS, TSTY, TSGX, TSGS, TYGX, TYGS, and finally GXGS, GSGY, GSGM and GYGM. As a matter of fact, one needs to write articulations only for composing two phases taken from lingware components using heterogeneous sets of variables (see below). The linguistic operations performed in each phase do not necessarily correspond to their names in a strict manner. For example, morphological analysis may be realized in AM, but it is also possible to distribute it between AM, AX, AY and a fraction of AS (for example, to test for the occurrence of predicted possible discontinuous idioms). In general, lexical transfer is also distributed between (at least) TL and TS, for analogous reasons. Similarly, morphological generation of a language such as Arabic  ADDIN ENRef [41] may advantageously be distributed between the end of GS and GM. Essential data types and basic terminology At the input and output sides of the translation process, the unit of translation is a simple string of characters. The 256 EBCDIC characters may be used in the specialized languages to build strings, and all are considered to be atomic (e.g., , ɔ and are not known to be variants of e). The blank (X'40') is used as separator of occurrences. A translation unit, then, is received as a sequence of occurrences by the AM phase. From the output of AM to the input of GM, a unit of translation is represented by a decorated tree. Each phase contains a part, named DV, where the linguist declares the decoration type, or set of variables in Ariane-G5 terminology. An elementary variable (variable for short) is defined by a name and an (anonymous) type. This type is defined by a kind (exclusive, non-exclusive, arithmetical, lexical) and a list of values. Each variable has a null value, denoted by its name followed by 0". - An exclusive variable V defined by V == (V1, V2, V3) takes its values in {V0, V1, V2, V3}. There is an analogy with the scalar types of Pascal, but here value identifiers are local to the types. - A non-exclusive variable V defined by V == (V1, V2, V3) takes its values in the power set of {V1, V2, V3}. V0 denotes the empty set. There is an analogy with the set types of Pascal, the preceding remark being still valid. - An arithmetical variable V defined by V == (n), where n is a non null natural integer, takes its values in: . - There is always one (and only one) lexical variable, named UL, for lexical unit (unit lexicale), which is predefined and takes its values in the set consisting of: - the predefined values '' (UL0), 'ULTXT', 'ULFRA', 'ULSOL', 'ULOCC', 'ULMCP'; - the values introduced in the lingware components (essentially in the dictionaries); - the values constructed dynamically (for example to handle unknown words). A decoration, or mask of variables in Ariane-G5 jargon, is a combination of values for all the variables of the considered set, very much analogous to a property list in LISP. It is possible to group variables in a hierarchical fashion, the top of the hierarchy being predeclared until a level depending on the specialized language. VAR always denotes the set of variables minus the UL variable. In ATEF, two subsets, VARM and VARS, are distinguished and declared separately, for the abovementioned morphological and syntactic variables (although, as for the phases, the linguists do not in general respect that division and add a number of variables of semantic nature). VARM and VARS are further subdivided into VAREM and VARNM, VARES and VARNS (exclusive and non-exclusive), as there are no arithmetical variables in ATEF. hape\\ProxyStubClsid&&{00020424-0000-0000-C000-000000000046}rrTypeLib&&{00020905-0000-0000-C000-000In ROBRA and EXPANS, where the three kinds of variables are possible, the top of the hierarchy is VAR(VARE, VARN, VARA), where  is a character (redefinable in DV) characteristic of the phase. By default,  is set to S, R, C, D, G for AS, TL, TS, GS, GM, and to X for the other EXPANS phases. For example, in AS, in order to refine VARE into syntactic and semantic variables, themselves divided into properties and relations, one might write: -EXC- ** (key-word for  exclusive ). VSYNTE == (PSYNTE (CAT (N, V, A, R, S), K (PHVB, PHINF, GV, GN, GA)) ,RSYNTE (FS (SUJ, OBJ1, OBJ2, EPIT, CIRC)). VSEME == (PSEME (PREDIC (STATE, ACTION, PROC), MATTER (DISC, CONT)) ,RSEME (RL (ARG0, ARG1, ARG2, ARG01, ARG02, TRL10))). -NEX- ** non-exclusive. A format (template) is a constant mask of variables to which a name has been given, in order to use it as an abbreviation in dictionaries and grammars. A decorated tree is an oriented and ordered tree where each node bears a decoration. Components and variants of a phase As in most NLP systems, a lingware written in a specialized language is organized into physically distinct components, for reasons of modularity and size. The components of a phase form an acyclic dependency graph (known by the compiler). - An ATEF phase contains two components of variables declaration (DVM, DVS), morphological, syntactic and general formats (FTM, FTS, FTSG, the last one being op000-0000-C000-000000000046}r)rTypeLib&&{00020905-0000-0000-C000-0tional), 1 to 7 grammars GRi (1d"id"7), 1 to 6 dictionaries of  morphs DICi (1d"id"6), at least one of them being of  bases (morphs with lexical references), and from 0 to 7 dictionaries of fixed connex idioms, DICi (7d"id"14). FTM depends on DVM, FTS on DVM and DVS, FTSG on FTS, the DICi on the formats, and the grammars on the dictionaries. - An EXPANS phase contains a component of variable declaration (DV), one of  condition and assignment procedures on decorations (PROC), one of  assignment formats (FAF), optionnally one of proper condition formats (FCP), and from 1 to 7 dictionaries (DICi). PROC, FAF and FCP depend on DV, and the DICi on the preceding. - A ROBRA phase contains DV, FAF, and from 1 to 7 grammars (GR1 to GR7), with the natural dependencies. &{000209AD-0000-0000-C000-000000000046} Dictionary\7\ProxyStubClsid&&{00020424-0000-0000-C000-000000000046}r8rTypeLib&&{00020905-0000-0000-C000-000000000046}- A SYGMOR phase contains DV, FAF, PCP ( proper condition procedures ), GRi (1d"id"7), and DICi (1d"id"13, at least one dictionary being accessed by the UL), with the same dependencies as in ATEF, with the exception that grammars do not depend on dictionaries. - A TRACOMPL articulation contains only one component, DV. The Ariane-G5 environment ensures at all times the coherency of the compiled components as a function of these dependencies and of the modifications made by the user (linguist). Each phase may give rise to variants, to be defined according to the types of texts to be translated. - In ATEF and SYGMOR, one chooses one of the grammars. - In EXPANS, one chooses an ordered subset of the dictionaires, and the mode (deterministic or not) of the engine. - In ROBRA, one defines a list of at most 14 grammars to be executed sequentially, the same one being allowed to occur more than once. By combining these choices and the choice of a path in the graph of phases (from AM to GM for a translation), one obtains execution lines (for debugging) and production lines (for cranking out translations) which are also memorized and managed by Ariane-G5. Principles of linguistic use Although Ariane-G5 does not propose or impose any methodology of linguistic programming, most of its users follow a certain number of principles, mainly due to B.Vauquois, which it may be useful to mention briefly at this point. Intermediate structures In the context of MT-R of a sublanguage, B.Vauquois recommends that analysis delivers a UMA-structure, for unique, multilevel and abstract structure  ADDIN ENRef [49, 50]. The geometry of the tree reflects one choice for the organization into syntagmatic groups, but the structure is an abstract tree, from which the text may not necessarily be reconstructed in an immediate way. For example, it is convenient to regroup discontinuous constituents (e.g. les garons les ont tous vues for the kidsi have alli seen themj), to variabilize negations, auxiliaries, articles, strongly governed prepositions, certain modals, etc., thus obtaining trees considerably smaller than the concrete (surface) trees provided by direct application of extended context-free grammars (GPSG or others). In principle, each internal node dominates a leaf which is the governor of the group (from gouverneur in French, usually head in English), unless the governor is itself a compound. In order to get a dependency structure analogous to those of the Prague school, it is enough, in a first approximation, to recursively send up each governor to replace its mother node. In other words, Vauquois structures are lexicalized intermediates between constituent and dependency structures, at least geometrically. Properties and relations are coded in the decorations attached to the nodes and constitue the algebraic part of the structure. For example, a node having attribute of object as value of the syntactic function (SF=ATROBJ) is the attribute of the group dominated by its (unique) sister node having SF=OBJ1. Hence, there are two syntactic levels, that of classes (morphosyntactic and syntagmatic), and that of functions. To translate into languages which are not extremely near to the source language without having to write large structural transfers, it is advisable to add two more levels, logical and semantic. The logical level (RL variable, for relation logique) gives the positions of arguments of linguistic predicates. ARG0 denotes the logical subject (most often actor or agent) of the predicate which is the head (governor) of the same group, ARG1 denotes its logical object (in general the patient, but not in ergative constructs such as the twig breaks), and ARG2 denotes its third argument. The numbering is such that ARG1 corresponds to OBJ1 in standard active constructs, but that is purely a convention. For example, the building of the house and to build the house have identical structures at that level, the group (of) the house being ARG1. TRL10 is used in place of ARG1 if the predicate is attributive (to be, to seem, to appear), and TRL21 in place of ARG2 if the predicate attributes ARG2 to ARG1 (to consider ARG1 as TRL21). This is a way to indicate that the relation does not link the node with the governor (the predicate), but with another argument. Similarly, one often uses another variable (such as RLI, for inverse logical relation) to code the link between arguments in control constructs. For example, in I ask him to come, the group to come is ARG1 of ask, and bears RLI=00 if ARG0 (I) is coming and RLI=02 if ARG2 (he) is coming. Finally, we use, mainly on circumstancials (modifiers), the semantic relation (RS), which grosso modo corresponds to the deep case (localization, origin, goal, accompaniment, manner, qualification, measure, cause, concession, etc.). In practice, RL and RS are complementary, because it is extremely difficult (even manually) to assign RS to arguments in a reliable manner, and circumstancials can be correctly translated only if their RS are known. In this respect, the famous problem of the translation of prepositions is often not well stated. If an argument is concerned, the whole construct (predicate+arguments, e.g. to talk about sth. with sb., to count for sb., sth.) should be translated as a block. If a circumstantial is concerned, the RS, possibly particularized by the preposition (or its absence) should be translated. For instance, in to come by Lyon and to come via Lyon, the circumstantial should bear RS=LOC, SEM=SPACE and SLOC=QUA (localization in space, movement through sth.), thus allowing for exact translation of by (par and not prs de, ct de, devant, de, daprs, suivant, ). Keeping the preposition also allows one to translate more exactly in a language like French, which also has two prepositions for this sense (par, via). Several levels are similarly used for the actualization variables, such as number (morphological and logical), time vs. tense, etc. The order of the text is reflected as much as possible in the structure. As a matter of fact, order gives important information which is not well formalized, such as thematic articulation and emphasis. This avoids coding it explicitly in a tactical variable. If one considers the UMA-structure of a sentence only at the deep levels, it can be thought to represent a whole family of sentences of equivalent meanings. If it is considered at all levels, it should correspond to only one sentence, notwithstanding spelling variants (such as disc/disk, program/programme, or corpuses/corpora). Besides these various levels of linguistic description, one also encodes in the UMA-structures produced by analysis unresolved ambiguities and doubts on parts of the construction, in order to avoid a combinatory explosion, and to be able to warn the revisor and at the same time to try to transfer those ambiguities which persist in translation (e.g. the conquest of the Romans). The aim of transfer is to perform lexical translation, and some adaptations of the structure aiming at delivering to the generator a structure coherent with the linguistic system of the target language. This structure is called GMA-structure, for generating, multilevel, abstract structure. In principle, the generator considers that the GMA-structure it receives is under-specified with respect to the surface levels, and recomputes them. Hence, the first logical step of generation consists of selecting a paraphrase of the meaning expressed by the GMA-structure by computing the UMA-structure of the translation to be produced. The second step consists of producing a surface tree (concrete tree, or UMC-structure), by creating nodes for articles, auxiliaries, negation elements, punctuations, by dividing or merging sentences if necessary, etc. The third step is the morphological generation which, starting from the sequence of the leaves, constructs the occurrences of the final text. Organization of dictionaries The notion of lexical unit is very useful for the generation step. It allows one to represent derivational families in a compact way. Modern dictionaries use a similar notion. In analysis, that notion allows one to reduce the size of the dictionaries, and to handle in a systematic way neologisms obtained by productive derivations. From the linguistic point of view, one is naturally led to regroup, for example, to heat, heater, heating, heatable, in the UL heat-V, the derivations used having the three aspects of semantics, syntax and semantics (e.g. agent or instrument noun ending in -er), in order of importance. From the practical point of view, one often separates the agent or instrument noun from such a family, because the derivation in question cannot be used to produce paraphrases usable in translation (heater > something which heats?), and because that allows one to separate the purely terminological indexing of those terms from the more complex indexing of a whole family of deverbals. According to the syntactic class of the principal lemma (source of the derivations), one distinguishes verbal, nominal and adjectival ULs. Of course, there are ULs reduced to only one term (function words, non-derived adverbs such as there, here). In Ariane-78, it was necessary to represent all lexical information in the AM dictionaries. In Ariane-G5, lexical expansion phases have been introduced to give the possibility of distributing the information. A possible organization is to use AM to go from morphs (roots, affixes, endings) to lemmas, AX to go to the ULs, and AY to handle non fixed or discontinuous idioms (e.g. verbs with separable particles in German). If interlingual wordsenses or acceptions are added, they may be introduced as values of a non-exclusive variable defined by SENSE==(1, 2, MaxNumSense). Organisation of grammars In ATEF and SYGMOR, organizing the grammars is quite simple, although one should resist the temptation to overuse ATEF heuristic functions. In ROBRA, the programming technique is quite different according to whether analysis, transfer or generation is concerned. Analysis usually begins by working in parallel on the whole unit of translation to normalize the tree (compound words, resolution of immediately solvable ambiguities, grouping of discontinuous idioms, dates, proper nouns, etc.). Then, a sentence-specific transformational sub-system is recursively called on each sentence. Other sub-systems may be called on groups (clauses, phrases). This allows the strategy (traversal of the control graph) to be directed by the data. The end of analysis usually consists of processing again the whole tree, which for example allows one to try to find referents of pronouns for which none has been found inside the sentences where they occur. In transfer, things are quite simple. One handles the translations of complex groups, tests the context conditions coded in the subtrees representing multiple translations, in order to reduce polysemies, and adjusts the g-structure, thereby possibly annotating it with advices or orders to the generator, in order to trigger the production of particular syntactic forms (e.g. to get the reflexive or the passive for stylistic reasons). Generation uses recursive descent to produce the UMA-structure, and then to begin construction of the UMC-structure. Parallel processing is usually used to assign final values to surface actualization variables (to propagate agreement constraints), which may lead to slight modifications of the geometry (insertion of auxiliaries and clitics). On should be cautious not to use grammars at the same time iteratively and recursively, because that leads to numerous useless grammar calls. The interactive interface Under Ariane-G5, it is possible to: - work on the linguistic components (phases, articulations) in the subenvironments PRAM, PRGM, PRAMAX, PRGYGM (creation, modification, compilation, listing). - work on the texts (PRTXT), with numerous facilities. - work on the execution lines and on the production lines. - execute all or part of the translation process for debugging purposes (each phase receives parameters for tracing and for outputting the result), using one available execution line. - crank out translations (no tracing is permitted), using an available production line. - revise raw translations (in multiwindow mode under XEDIT, with the possibility of switching to THAM, which offers additional facilities). - perform actions on several phases at the same time (compilation, listing, erasing, duplication). - obtain various informations on the objects managed by Ariane (list of source and target languages, of corpuses, links between source and target languages, compilation status). - read or modify the global parameters (dialogue mode, current source and target languages, current corpus). An on-line help is available, for the most part at two levels of detail. This interactive monitor is described in  ADDIN ENRef [44]. It represents about 50,000 lines of EXEC2 and 100,000 of ASM370. The specialized languages ATEF, a language for morphological analysis ATEF was designed in 1971 by J.Chauch  ADDIN ENRef [24], who wrote the engine, while P.Guillaume and M.Quzel-Ambrunaz wrote the compilers of the different components. Since then, ATEF has undergone numerous extensions, but the underlying algorithmic model has not varied. As a matter of fact, it is a very satisfactory tool. The system successively handles each occurrence of the text, examining a priori all possible analyses (non-deterministic total mode with backtracking). The current occurrence is named C. An analysis result is a decoration or a sequence of decorations (in the case of compound words). Each step of a particular analysis consists of choosing one of the open dictionaries, in finding there an item which key, the morph, is a prefix (or a suffix, in right-to-left mode) of what remains to be analyzed (noted A), which is reduced accordingly, and in applying one of the rules associated with the morphological format of the considered item. The rules may contain conditions bearing on the current state (decoration C), on the strings C and A, on the partial results produced by the current analysis (PS1 to PS9) in case of a compound word, and also on the four preceding occurrences (from P1 to P4) and on the results of their analysis. A particular form of condition consists of giving a list of sub-rules and in asking that at least one of them applies (as a sub-rule may itself have sub-rules, that happens in non-deterministic unary mode with backtracking). It is finally possible to store a condition on the analysis of the following occurrence. There exist three types of action: assignment of values to mask C, transformation of what remains to be segmented (string A), and call of special functions. These functions allow to: - control the built-in backtracking by pruning the choice tree (functions FINAL, ARRET, ARD, ARF, STOP) or by opening and closing dictionaries (through assignment of the obligatory non-exclusive morphological variable DICT); - produce a partial result from the current state C (function SOL); - transform C or A into a UL, thereby reducing A to '' (functions TRANS and TRANSA); - decide that a sentence boundary has been reached (function INIT). If an occurrence is not recognized (unknown word), that is, if no analysis succeeds in reducing A to '' while producing a current state C having a non-null UL, the system starts analysis again, after having attached to the occurrence the obligatory morphological format MODINC, which must in particular call the obligatory rule MOTINC (rule of the unknown word). As that rule may call sub-rules, and as that format may call other rules, it is possible to construct a true grammar of the unknown word, and to program sophisticated strategies for analyzing unknown words. During processing, the automaton (ATEF engine) constructs a (4-colour backward) graph where the nodes are the masks (or lists of masks for the compound words) associated with the solutions found, and the edges indicate compatibility between analyses (at distance 1 to 4). The final graph is finally transformed into the desired form. The Q-graph output is now no longer available, and two other output forms, as 1-colour forward graph and as tree with homosentences (presenting all paths in the 4-colour graph separately) are no longer used. The standard output of ATEF is a tree without homosentences, which encodes ambiguities. Its root corresponds to the whole text and bears UL='ULTXT'. Its daughters correspond to the sentences (determined by the grammar) and bear UL='ULFRA'. Under each of them are nodes with UL='ULOCC', which correspond to the occurrences (words or fixed connex idioms). Under each 'ULOCC' are the different results of the morphological analysis of the corresponding occurrence. Each result is either a mask of variables (a node) or a sub-tree with root having UL='ULMCP' (compound word) dominating the masks corresponding to the different parts recognized in the word. ROBRA, a language for transforming decorated trees ROBRA  ADDIN ENRef [14] is a language for writing transformational systems working on decorated trees. It is the successor of the CETA language  ADDIN ENRef [24] Numerous extensions have been introduced, the semantics has been made more precise, and the engine has been totally respecified and rewritten. A transformational system (ST) is defined by a control graph (GC), a set of transformational grammars (GT) and a set of rules (RP for production rules). A GT is an ordered set of rules. A GC is a graph where each node bears a GT or the exit symbol (&NUL) and the edges bear tree conditions. Note that each grammar component GRi of a ROBRA phase actually countains a whole transformational system, possibly consisting of a large GC with dozens of GTs. To execute an ST on an object tree (AO), ROBRA uses the GC as non-deterministic (unary with backtracking) control structure: starting from an initial node, it looks for the first valid path leading to an exit. On this path, it executes the grammars countained in the nodes, and traverses an edge only if the current AO verifies its condition. The execution of a GT consists of one elementary application in unitary (U) mode, or of several in iterated mode (E for exhaustive). In an elementary application, many rules of the GT are applied in parallel, which necessitates a mechanism for conflict resolution. An elementary application ends only after the recursive calls of sub-grammars (SGT) or sub-systems (SST) possibly triggered by the application of certain rules have been completed. A system of interdictions (rules are marked, nodes are blocked) allows one to statically test the ST for decidability: the compiler may warn the user of the risks of undecidability (loops in the GC, free mode in an iterative GT, constraint on recursive calls not satisfied, etc.). The schemas which appear in left-hand sides of rules have a very great expressive power. For each node, it is possible to indicate whether its daughters are to be looked for in leftmost or rightmost positions, in order or out of order (free permutations). It is possible to look for nodes at unspecified depths by using generalized nodes. Finally, the rules may be context-sensitive, the root of the schema (RS) being possibly different from the root of the effective transformation (RT). What is not dominated by the RT constitutes the context, or hat. The RT may itself be active or contextual. What it dominates belongs to the active part. The notion of parallel rewriting in ROBRA is quite strong, as parallelism may be normal (RT located on distinct nodes of a cut of the AO), vertical (a RT may dominate another), and horizontal (several contextual RT and at most one active RT may be instantiated on the same node of the AO). Finally, it is possible to write extremely complex conditional assignments of variables in the right-hand side of rules, which contributes to making ROBRA an extremely powerful tool. ROBRA is really a production system of the substitution type, even if, in the current implementation, elementary application of a transformational grammar is done by transduction of an input tree into an output tree (both represented linearly). For that reason, the decoration type is necessarily preserved by a transformation system. EXPANS, a language for lexical expansion and transfer EXPANS is based on a model of transduction of decorated trees  ADDIN ENRef [31]. The decoration types of the input and output trees may be different. Each node is transformed into a sub-tree in the output tree. This sub-tree is determined by consultation of the dictionaries, in their order of priority, through the UL born by the node. A default action is always foreseen. A dictionary item has a UL value as key, and a list of triplets as content. The conditions concern the node of the input tree and possibly its immediate neighbours (mother, left and right sisters). The image describes the geometry of the sub-tree to be produced, and the assignments allow to compute the values of the variables on the nodes of the sub-tree from those of the accessible input nodes. At the level of a dictionary, if the UL of the node is found, EXPANS looks for the first triplet whose condition is verified (the last condition must be empty, that is, identically true), and the corresponding sub-tree is produced. Otherwise, this dictionary fails. In deterministic mode, dictionaries are searched in their order of priority until a success is obtained. In non-deterministic mode, all dictionaries are searched, in order, and the image produced is a sub-tree constructed by rooting the sub-trees produced by the dictonaries under a new node. This mode allows for example not to hide the usual translation of a word which has also a different translation in a particular domain whose dictionary has been given higher priority. SYGMOR, a language for morphological generation SYGMOR is based on the model of a finite-state deterministic transducer, whose first version was designed by B.Thouin and programmed by D.Jaeger.  ADDIN ENRef [30] describes the extensions and amendments he contributed to it in recent years. SYGMOR takes as input a sequence of decorations and produces as output a string of characters. A context reduced to the current (C) and preceding (P) decorations is available, and two strings are used, the working string T (chane de Travail), and the output buffer S (chane en Sortie). The grammar has quite a simple structure. Each rule is made of a condition, actions and subsequent rules. Actions consist essentially of writing to the right, to the left or at the middle (last point of concatenation) of T a literal string or the result of accessing one of the dictionaries through the value of one of the variables of C (dictionaries accessed by the UL give the bases, the others the affixes). It is also possible to modify C, and to recall S to T (by concatenating it to the left and emptying it). For each decoration, SYGMOR looks for the first applicable rule and applies it. It then applies the subsequent rules in order, without taking their subsequent rules into account. A subsequent rule may be obligatory or optional. If an obligatory rule fails, SYGMOR goes back to the initial state and applies the rule MOTINC, if present, and otherwise the default error action (empty S, then do S:=T). Processing continues by taking into account the subsequent rules of the last rule applied, until an empty list of subsequent rules is reached. TRACOMPL, a language for transforming decorations (articulations") TRACOMPL  ADDIN ENRef [31] is the sub-language used to write all DV components. It has been made into an autonomous language to allow for writing articulations. The goal is to transform decorations of a Set1 into a Set2. For that, we proceed in two steps: - First, one describes Set2 and what should be known of Set1 in order to perform the transformation. The names of the variables present in both sets are prefixed by $ and those of variables present in Set1 but not carried over to Set2 by $$. The others (not prefixed) are considered to be new. - One completes this by writing (CVAR part) a conditional action which can test the variables of the input decoration in Set1, in Set2 after the reformatting described by the preceding part, and in Set2 in their current state (during execution of the action). Because of this, it is possible to perform arbitrary transformations of variables. Evolution of tools and methodology due to experiments in MT-R The organization presented above seems somewhat complex. Why several languages? Why optional phases? As a matter of fact, the initial architecture was a lot simpler, and almost all extensions have been motivated by express demands of linguists. What we want to illustrate now is that an "MT shell" such as Ariane-G5, with its powerful rule-based languages, is still not enough: developers taking parts in various experiments in building MT-R prototypical or operational systems have expressed the need for more engineering-oriented tools, supporting the development of independent and static lexical and grammatical knowledge. MT-R systems developed with Ariane-G5 The preoperational Russian-French prototype (198087) The development of the Russian-French system  ADDIN ENRef [15] from the stage of mockup to that of a real prototype, used in a preoperational setting (a flow of texts was regularly sent, translations had to be sent back within a certain time, dictionaries had to be improved together with a specialist of technique and translation) has shown us the necessity of developing tools to help linguistic programming in Ariane, such as ATLAS or VISULEX. Since the beginning of the eighties, it has become evident that this type of programming could and should be compared with the programming of large software systems, and attacked accordingly. As an example, the Ariane-78 software has cost about 30 man years of work, and the Russain-French lingware about 80. This prototype, realized by N.Ndobejkine and his collaborators, is not strongly specialized for a certain type of texts. Its vocabulary, of about 30,000 terms (simple and compound terms, idioms), contains 5 to 6,000 general terms, the rest being distributed between various scientific and technical domains (space and earth sciences, metallurgy, aeronautics, linguistics). At the beginning, it was not clear whether MT for the watcher or MT for the revisor was aimed at. It appeared that the quality obtained was good enough to allow for revision of a page in about 1/4 of an hour, a time very much comparable to that of the revision of a human raw translation of course, the errors are not the same. The analyzers of English and the translation mockups (198389) The methodology for constructing MT systems in Ariane owes much to various cooperations through which B.Vauquois was able to try various methods and come up with the above-mentioned principles. This effort began as soon as 1973-74 with studies on the analysis of French, together with SFB/100 at Saarbrcken (J.Weissenborn, E.Stegentritt), and then of Portugese (P.Daun Fraga). The methods developed for French were taken over and improved for Portugese, and again reused and improved on French, in the context of a feasibility study on French-English for the French Telecoms (Vauquois, Guilbaud, Dymetman) in 81-82. The analysis of English then became the common point of several studies made in cooperation. The most important led to an English-Malay laboratory prototype  ADDIN ENRef [48]. Others led to mockups into Chinese  ADDIN ENRef [57], Thai, and finally Arabic  ADDIN ENRef [41]. This analysis was also used as the starting point for work on a "standard analyzer" of English undertaken during the MAT-NP and pursued for some time afterwards at B'VITAL. B'VITAL's operational French-English system (Ariane/aero/F-E) The most comprehensive work on French-English using Ariane has been done by B'VITAL, a small firm founded during the MAT-NP in 85-87. The static grammar of French consists of about 150 construct boards (boards are 2-dimensional representations of correspondence rules) and 450 disambiguation boards (preference rules). AS is more than 20,000 lines long (in ROBRA). The dictionaries contain about 20,000 terms, of which more than half are terminological. Commented examples of French-English translations The following examples have been selected from raw translations produced by B'VITAL's Ariane/aero/F-E system after three years of development. Aprs essai, sassurer du fonctionnement correct de lensemble raccord.After test, check that the coupling assembly works correctly.Note here the passage from a nominal (prepositional) phrase du fonctionnement correct to a verbal clause, that works correctly, with as corollary the passage from the adjective correct to the adverb correctly. These transformations are not performed during transfer. It is the first step of syntactic generation which, starting from the g-structure (generating structure), considered as underspecified with respect to the syntactic functions and the syntagmatic and morphosyntactic classes, recomputes these levels depending on the initial goal (here, to construct a verbal phrase), using the deeper levels (logical relations inside the strict predicative frame, semantic relations for the circumstancial complements). Using the notion of lexical unit, the generator knows, without having to consult a dictionary, which lemmas are contained in the considered derivational family, which contains the possible paraphrases. Here, fonctionnement has been reduced to the UL fonctionner-V, itself translated as work-V, which bears the potentiality of deriving an action noun. It is then simply the order of preference between the rules controlling the choice of syntagmatic categories which triggers the construction of a subordinate clause rather than of a nominal phrase (the correct working of the coupling assembly). Porter sur celle-ci la date de la dernire rception ou rvision.Write on this one the date of the last reception or of service.Porter is a support verb here, and porter une date is translated as to write a date and not as to carry a date, thanks to a test performed at lexical transfer on the syntactic and semantic features of the second argument (ARG1) of porter (its logical object). Effectuer la vidange gnrale et la purge du carburant (voir chapitre 12).Drain in a general manner and bleed fuel (see chapter 12).Effectuer la vidange is translated here by the simple verb to drain, thanks to the notion of lexical unit, and to the organization of the lexical transfer. Vidange is reduced to vidanger-V, and that UL gives in translation a (sub)tree in which the possibility of the presence of a support verb such as effectuer, faire, etc., is coded. The translation of the support verb, if present, will be erased by structural transfer. Le bouchon a pour but dassurer la protection dun raccord auto-obturable lorsque celui-ci nest pas utilis au sol ou en vol.The trap is used for carrying out the self-sealing coupling protection when this one is not used at the ground or in flight.Avoir pour but is recognized as a compound predicate, avoir-but-V(x0,x1), translated as use-V(x1,x0), with a conversion of argumets. This explains the generation of a passive. Enduire lgrement le joint neuf de liquide dutilisation.Slightly coat the new joint with operating fluid.The translation of prepositions is always delicate. It is necessary to know whether they introduce arguments or circumstantials. Here, enduire-V is a predicate with 3 arguments (qn enduit qn/qc de qc), the third one being introduced by de. The analyzer prefers to fill the argument frame, and the introductor of the corresponding argument of coat-V is with. Ouvrir progressivement le robinet (3), appliquer une pression jusqu 1,5 bar jusqu lallumage du voyant lumineux DS2 et lextinction du voyant DS1.Gradually open tap (3), apply a pressure up to 1,5 bar until the light DS2 switching on ((ignition)) and the signal lamp DS1 extinction.Here the preposition jusqu introduces two circumstantials. What is really translated is the semantic relation (here, RS=LOC with SEM=TEMPS and SLOC=QUA), refined by the preposition and by the semantic features of the governor (Vauquois term for head) of the group, here PROCESS for allumer-V, and of the predicate (appliquer-V). Ouvrir progressivement le robinet (3) jusqu obtenir une pression de 9 bars.Gradually open tap (3) until a pressure of 9 bars is obtained.No explicit transformation is performed. The infinitive clause is rendered by a subordinate clause simply through the normal functioning of the generator, as explained above. As argument 0 (logical subject) is not expressed, a passive is generated. This is only a matter of stylistic preference. It would be equally possible to generate until one obtains a pressure of 9 bars, or until obtaining, as in the following example. Procder la dpose des panneaux.Remove the panels.IMPORTANT: avant de dposer ou de reposer le panneau central intrados de voilure, il est ncessaire de procder certaines modifications.IMPORTANT: before removing or reinstalling the lower central wing panel, it is necessary to proceed with some modifications.Here, the construct preferred for the conjunction before is the gerundive. On the other hand, the preposition introduces argument 1. In the m-structure produced by analysis, it may well have been suppressed. With is contained in the valency frame of proceed-V for the same argument position, hence it is introduced by the generator. Evolution of tools and methodology Tools associated with Ariane-G5 A variety of tools have been implemented besides Ariane-G5 to support the development of large dictionaries (ATLAS, VISULEX, BDTAO, TTEDIT) and to handle texts containing markups and non-roman characters (THAM, LT, SCRIBERE). Helps to construct MT systems ATLAS, a system to help indexing in coded dictionaries ATLAS is a language for writing indexing charts and has been used to produce numerous indexing manuals of the Russian-French system. One describes an acyclic graph where the internal nodes bear questions, the edges possible answers, and the leaves the results attained (usually, names of formats or of procedures). This graph may be drawn, to produce paper manuals, or be used dynamically, to create menus on- screen in a window and send the results to the appropriate places in a second window showing the dictionary to be constructed or modified. VISULEX, a tool for the synthetic visualization of lexical informations contained in lingware written in Ariane VISULEX  ADDIN ENRef [2] allows one to visualize all or part of the lexical informations contained in a system written in Ariane-78 or Ariane-G5, at two levels (codes and comments), which frees linguists from having to search many files at the same time. BDTAO, a lexical data base management system for MT BDTAO is a lexical data base management system specifically designed by B'VITAL for MT, but not for Ariane only. Analysis and generation formats and dictionaries are compiled from the corresponding monolingual sub-base. For transfer, there is one sub-base for each language pair. There is a distinction between the kernel dictionary, which belongs to the grammatical system of the language and is directly coded, the general dictionary, and the terminological dictionaries. In transfer, the general part is much more complex than the terminological part, and the construction of the corresponding Ariane dictionaries is not yet fully automated (in the meantime, standard indexing manuals are used to index directly in Ariane TL dictionaries). TTEDIT, a transformational editor of decorated trees TTEDIT  ADDIN ENRef [26] is a tree editor (trees may bear simple labels or complex decorations). Its originality is that its basic operations are sub-tree transformations, as in ROBRA, and not direct manipulations on the nodes and edges. This allows one to work on large trees, in the same manner as one works on texts with editors equipped with highly parametrized search-and-replace facilities. TTEDIT is completely integrated with the standard editor XEDIT, and also allows one to write macros, which are in fact transformational grammars analogous to those of ROBRA. TTEDIT has been in particular used in order to carry out, starting from a tree produced by BVITALs analyzer of French and transformed by a transfer written for the occasion (in Ariane), additional ad hoc transformations leading to an analysis interface structure conforming to the linguistic legislation of the Eurotra project and to the personal preferences of people in charge, for special cases not foreseen by that legislation  ADDIN ENRef [29]. Tools for handling texts THAM THAM stands for Machine-Aided Human Translation (Traduction Humaine Aide par la Machine). Programmed in EXEC2/XEDIT, THAM works as an XEDIT macro  ADDIN ENRef [2]. Suppose that an Ariane user is revising a raw machine translation. By simply hitting a key, he starts THAM, which allows him to access a natural dictionary, dynamically modifiable, together with the revised text, the raw translation and the source text. THAM may also be used in stand-alone mode. This tool is by far not a full translator/revisor workstation, like those offered by certain firms (Weidner, ALPS), but only a useful extension to XEDIT. As a matter of fact, for industrial use, it is far preferable to revise the translations on a PC, a MacIntosh, or, if luxury is permitted, on a Xerox Star"! machine. LT, a language for writing transcriptors LT  ADDIN ENRef [36] allows one to quickly write transcriptors of texts. For example, the Russian-French system uses a transcription of the Russian texts in a subset of PL/I character set (upper case roman letters, digits and some special signs). Transcriptors written in LT are used to output texts in cyrillic and Chinese scripts while a Roman transcription is preferred within Ariane-G5. A recent implementation in CLOS has been used to transform a large dictionary between various formats  ADDIN ENRef [27]. The abstract model here is a finite-state transducer with two tapes. The input tape has two reading heads. The first one can only go forward, while the second one, used as a look-ahead, may go forward or be recalled to the position of the first one. The output tape has one writing head. The states are structured: a full state is the combination of an elementary state and of a set of values of a certain number of variables. Writing a transcriptor consists of declaring the variables and their types (e.g. font, language, length of the look-ahead), and then in describing the graph of the transition system, with one node for each elementary state. The edges bear the transitions, which are classical production rules. There are a number of predefined functions, as well as facilities for parametrizing and factorizing, to avoid writing too many rules. SCRIBERE, an extension to the SCRIPT/DCF formatter SCRIBERE allows one to describe the textual content and the logical structure of a document by using macros written in IBMs SCRIPT/DCF. This tool offers possibilities inspired by SGML. It has been developed by D.Bachut and N.Verastegui to compensate for the unavailability of GML and SGML at the time. Markup takes into account certain aspects of linguistic nature (current language, current transcription, etc.). Static grammars and lexical data bases The need for a static specification of dynamic analysis and generation grammars appeared around 1980 because of cooperation with linguists having no computational background.  ADDIN ENRef [23] and  ADDIN ENRef [51] present the formal and practical aspects of the first "static grammar" formalism. A methodology for specifying and implementing analyzers and generators from static grammars was then defined and tested during the ESOPE project of ADI on the development of a pedagogical English-French mockup (BEX-FEX), and put to full use for the development of B'VITAL's Ariane/aero/F-E system. In a nutshell, a static grammar describes the correspondence between texts and associated linguistic structures in a non-directional way. Terminals and non-terminals of static rules stand for subcorrespondences. Although the rewriting mechanism is classical (context-free with attribute and constraints), the structures so defined can be "natural" abstract trees, possibly strongly non-projective  ADDIN ENRef [49]. Static grammars were first prepared on paper. A first computer environment to handle them was then implemented on a Macintosh by integrating an array of commercially available tools  ADDIN ENRef [56]. In the following years, several studies have been made to refine their formal semantics  ADDIN ENRef [18, 37, 58] and some improvements have been proposed. At USM, Y.Zaharin and his team have produced SaGE, a Macintosh application which allows one to compute on a static grammar. This is not yet an executable specification, but SaGE can automatically produce an analyzer and a generator (in ROBRA) from such a grammar, in simple cases, following the general strategic principles explained above. This work is preliminary (in particular, the transformational systems produced are far from being optimized), but quite encouraging. Finally, the lexical methodology is evolving towards application-independent lexical data bases. We have mentioned B'VITAL's development of BDTAO, which is specific to MT, but system-independent. This need is quite concrete: even now, translators aids integrated with access to MT systems cannot offer coherent MT and MAT dictionaries. We have undertaken several studies on this topic since 1984  ADDIN ENRef [16], thereby prototyping a trilingual base in telecommunications (French-English-Japanese) in 1986 and participating in the Multilex Esprit project in 91-93. In  ADDIN ENRef [3, 46], we have proposed and prototyped solutions to the problems remaining at the level of the definition of the linguistic content of such bases, of their logical structure, and of their implementation. Evolution towards personal networking communication: LIDIA and UNL Since 1989, we have turned to the investigation of DBMT (Dialogue-Based MT), a new architecture for MT systems enabling monolingual users to generate high-quality translations into several languages. The quality should be good enough to require no postediting or a minimal postediting in the case of very important documents. Fully automatic MT systems can achieve this goal only for very specific kinds of texts, such as weather bulletins. In our approach, the document is first interactively "cleaned" and "tagged" (for special terms or idioms, utterance styles, etc.). Each unit of translation is then sent to a state-of-the art all-paths analyzer, which returns a structure factorizing all ambiguities which cannot be reliably solved with the knowledge available. A question mark appears next to each ambiguous unit of translation. The user clicks on it to activate a disambiguation dialogue which doesn't assume any particular expertise in linguistics, computer science, or any of the target languages. This research is now pursued in the context of the UNL project, where input is planned to be either (1) directly constructed in the intermediate UNL pivot language with some specialized editor, or (2) written normally and then interactively disambiguated into UNL structures as in LIDIA. We first describe where we were at the beginning of the UNL project, after several years of building and experimenting with our LIDIA mockup, both in the design of this new paradigm and in the extension of Ariane-G5 to Ariane-G5/LIDIA. In the last section, we show how this evolution continues in the framework of the UNL project. The LIDIA project After explaining the motivations and the main principles of our DBMT approach, we illustrate the concept with an example, and detail the main evolution of the basic software which has been motivated by this new MT paradigm. Motivations and principles of the DBMT paradigm for "MT-A" Historical background and motivations The idea of DBMT has been proposed and tested in various forms during the last 20 years  ADDIN ENRef [19, 20, 22, 25, 32, 33, 38, 39, 43, 45, 47, 53-55]. However, it has always been taken for granted that the user should be a specialist, linguist or translator, or at least a professional, and that, consequently, the system could and should be specialized. In contrast, we think that DBMT systems should be designed for the general public, and be used on PCs. Consequently, the design of the user interface in general, and of the disambiguation dialogues in particular, becomes extremely important. The main idea of our concept is that pieces of the text under creation or modification are sent to an analyzer running in the background. If there are ambiguities, be they proper to the source language or relative to the translation into one or several target languages, questions are posed to the author, in the source language. The resulting ambiguity-free structures are sent to transfers and generators into all target languages, producing high quality translations needing no postediting. During the last few years, we have designed and implemented LIDIA-1  ADDIN ENRef [4, 5, 8, 9, 11-13] as a series of mockups to experiment with this concept of DBMT for (non-specialist) individual authors. In LIDIA-1.2, there is only one source language, French, and three target languages, German, English and Russian, but this is only due to limitations in manpower. The addition of Chinese as a fourth target language is under way, and should be included in LIDIA-1.3, hopefully the last mockup before a full-size prototype. Main principles of the approach Here are the essential principles which, if taken together, lead to a new paradigm, although almost all of them have already been proposed or used in other combinations: distributed processing. The document is created and interactively disambiguated on a middle-range Macintosh, while the various processes of MT proper are performed by a remote server. application to hypertexts. The documents are in effect hyperdocuments, in the form of HyperCard stacks. Units of translation are HyperCard textual fields. asynchronous and non-preemptive processing. Units of translation are released by the author, and then autonomously travel to the MT server, come back after analysis in a multiple-multilevel-concrete form (MMC structure), announce the presence of ambiguities by letting a button appear next to them, react to the click by engaging in a disambiguation dialogue, and then, once disambiguated, travel again autonomously to the MT server to be translated, and to finally be inserted in the appropriate field in the target stack. e-mail communication between component processes. We have switched from a specialized connection to the use of standard e-mail for all communications between the author workstations and the MT server, which can now be located anywhere in the world. deeper multilevel approach. We have added a level of interlingual acceptions (or word senses) to the classical lexical levels of B.Vauquois multilevel transfer approach (occurrence or wordform, lemma or citation form, and lexical unit or derivational family). guided language approach. Rather than to force users into a single controlled language, we associate a document kind to the whole document, a texte genre to large parts (possibly defined as an SGML document structure, with linguistic attributes), and an utterance style to each utterance. In an orthogonal way, the lexicon may be specialized by adapting weights (lexical preferences) on arcs and nodes of the graph representing the lexical data base. disambiguation strategy. We have developed a generator of disambiguation dialogues which non-specialists can easily understand, and which does not rely on excessively sophisticated linguistic processing, so that the disambiguator can run in real time on the authors personal computer. control by reverse translation. On demand, the system translates back from the target UMA structures (unambiguous, multilevel, abstract), providing feed-back through a paraphrase in the source language of the translation. homogeneity of knowledge sources. In the current state of implementation, this concerns only lexical knowledge: both lexical disambiguation messages and MT dictionaries are obtained from the same multilingual lexical data base, PARAX  ADDIN ENRef [3], itself implemented in HyperCard. In real usage, the source texts could be in any format. We are working on tools to transform them into the same kind of HyperCard stacks as the above demo stacks, thereby structuring and segmenting them, identifying the utterance styles (typing) and indirectly preediting text-specific formulas or idioms in a semi-automatic fashion. Concrete vs abstract linguistic structures Let us clarify our notions of concrete and abstract linguistic structures. A concrete representation of a text is such that the corresponding text can be recovered from it by using a standard traversal algorithm and simple morphological and graphemic generation rules. Familiar examples are textbook constituent structures and dependency structures (with left-to-right traversal of the leaves or infix traversal of all nodes). Otherwise, the representation is abstract. Note that the information contained in both kinds of structures (on labels and other more or less complex annotations) may be of the same linguistic depth: there may be deep concrete structures and surface abstract structures, in this sense, although the opposite is of course more frequent. They may also be multilevel, which is our preferred strategy. Take for example the sentence: The customers were not given their money back by the cashier, but by the waiter. A multilevel head-driven concrete structure could be: S[type=assertive, time=past, aspect=perfective, tense=c-past, voice=passive] (NP[semrel=dest, logrel=arg2, synfunc=subj, sem=human, num=plur] (Art[lex=the, semrel=deict, synfunc=det, number=plur, deter=definite] Noun[lex=customer, synfunc=head, sem=human, number=plur]) aux[lex=be, tense=pret, pers=3, number=plur] neg[lex=not] vrb[lex=give, synfunc=head, voice=passive, tense=ppart, vbpart=back] NP[semrel=patient, logrel=arg1, synfunc=obj1, number=sing] (adjposs[lex=his, semrel=poss, synfunc=det, number=plur, deter=definite] Noun[lex=money, synfunc=head, number=sing]) vbpart[lex=back] NP[semrel=agent, logrel=arg0, synfunc=agcomp, number=sing, neg=not-but] (prep[lex=by, synfunc=reg] art[lex=the, semrel=deict, synfunc=det, number=sing, deter=definite] Noun[lex=cashier, synfunc=head, sem=human, number=sing, neg=not] NP[semrel=id, logrel=arg0, synfunc=coord, number=sing] (conj[lex=but, synfunc=reg] prep[lex=by, synfunc=reg] art[lex=the, semrel=deict, synfunc=det, number=sing, deter=definite] Noun[lex=waiter, synfunc=head, sem=human, number=sing])) punct[lex=.]) Syntactic categories have been used here as the main labels, with phrases (syntagmas) in capitals and preterminals in small letters. Acronyms should be self-explanatory. In an abstract structure, some lexical information would be featurized, and order could be normalized, leading to: S[type=assertive, time=past, aspect=perfective, tense=c-past, voice=passive] (vrb[lex=give.back, synfunc=head, voice=passive, tense=c-past] NP[semrel=agent, logrel=arg0, synfunc=agcomp, num=sing, neg=not-but] (neg[lex=not] Noun[lex=cashier, synfunc=head, sem=human, number=sing, deter=definite] NP[semrel=id, logrel=arg0, synfunc=coord, num=sing] (conj[lex=but, synfunc=reg] Noun[lex=waiter, synfunc=head, sem=human, number=sing, deter=definite])) NP[semrel=patient, logrel=arg1, synfunc=obj1, num=sing] (adjposs[lex=his, semrel=poss, synfunc=det, number=plur, deter=definite] Noun[lex=money, synfunc=head, number=sing]) NP[semrel=dest, logrel=arg2, synfunc=subj, sem=human, number=plur] (Noun[lex=customer, synfunc=head, sem=human, number=plur, deter=definite])) Abstract representations of utterances are far superior to concrete representations as input and output structures of transfers in semantic transfer MT or as lexical-conceptual structures  ADDIN ENRef [43] in interlingual MT, especially between distant languages. But their relation to the corresponding utterances is not as clear, a natural consequence of abstraction. This remoteness is even more apparent with other types of structures, such as conceptual graphs, logical formulae or interlingual representations la KBMT-89  ADDIN ENRef [42]. By contrast, concrete structures are clearly more adequate for interactive disambiguation. They are also superior for a variety of future applications. For example, no text processor today is able to replace give-back by return in the preceding example, not to speak of changing the modality, the tense, the voice, or the discourse type (say, from direct to indirect or affirmative to negative). Self-explaining documents would make such changes possible. Presentation on an example The LIDIA-1.2 mockup demonstrates the concept on a HyperCard stack showing typical kinds of ambiguities in French. The target languages are Russian, German and English. The MT server runs on an IBM-9221 minicomputer accessed in the background through a standard e-mail facility. Ariane-G5 itself has remained stable, but has been extended by a translation server accessible by e-mail and http (Ariane-G5/LIDIA), and by a tool allowing one to develop Ariane-G5 MT systems from a Macintosh running Hypercard and Eudora, a simple e-mail utility. All-paths analysis and interactive disambiguation Here is a card of a demonstration HyperCard stack.  Fig. 1: A demo LIDIA stack Fig. 2: LIDIA Palette Let us open a card in the demo stack and click on the second field, which contains the sentence: Louvrier creuse la chausse et lasphalte. [The worker bores a hole into the roadway and asphalts it / The worker bores a hole into the roadway and the asphalt.] A button (bulb-shaped here) appears next to the field to show that the sentence has been sent to the remote server to be analyzed. When the analysis comes back, another button bearing a question mark appears. Clicking on it with the LIDIA cursor triggers a disambiguation dialogue. Note that the interactive disambiguation step is not meant to replace robust automatic disambiguation. It comes after it to guarantee correct disambiguation of the remaining ambiguities. The analysis used here produces what we call an MMC-structure, that is, a multiple, multilevel, concrete structure, actually a large decorated tree containing subtrees, each corresponding to possibly more than one proper analysis (disjunctions can appear in the node decorations, which are complex attribute structures). The analysis dictionaries of LIDIA-1.2 are quite large (about 20,000 lemmas). In particular, they contain all of the verbs in the famous Bescherelle dictionary. However, to date only about 2,000 have been indexed to enable transfer into other languages through interlingual acceptions. The grammatical coverage is not as large, but not at all limited to the small corpus used in the mockup. The ambiguities produced are of two types, those relative to the source language, and those which appear relative to at least one of the target languages. In our current strategy, we begin with questions on structural ambiguities, continue with functional ambiguities (subject/object, argument/circumstancial, semantic roles -- none in this example), and finish with the lexical ambiguities.  Fig. 3: A structural disambiguation dialogue Here, asphalte can be a noun or a verb. This lexical ambiguity is also manifested by a structural ambiguity of attachment. According to our strategy, structural ambiguity schemata are activated first, so that we get the following dialogue.  Fig. 4: A lexical disambiguation dialogue (creuser) The two meanings here are to bore a hole through something and to make something hollow by boring matter out of it.  Fig. 5: A lexical disambiguation dialogue (chausse) Chausse might be a road, a dam, an underwater reef, or a row of basaltic columns. After disambiguation is finished, the resulting UMC-structure (unique, multilevel, concrete) is automatically sent to the server, where it is submitted to an abstraction process, the last phase of analysis, and transformed into a UMA-structure (unique, multilevel, abstract), which is better suited to translation into various languages (see below for more details). Abstraction consists of simplifying and normalizing the geometry of the tree by suppressing nodes corresponding to articles and auxiliaries and coding the corresponding information in the decorations, in regrouping discontinuous constituents, and possibly in changing the linear ordering into a standard one. Transfer and generation German The lexical transfer of this mockup has only 250 French lexical units (UL), i.e., about 750 lemmas, and 550 German UL (H" 1,600 lemmas). The structural generation has been developed specifically for this project, to obtain a clear division into two phases.  Fig. 6: Translation into GermanFirst, the target  GMA structure (generating, multilevel, abstract) produced by the transfer is transformed into a UMA structure, by recomputing or confirming the surface-level attributes from the interlingual ones. Second, a UMC structure is obtained via the following syntactic generation phase. The morphological generation has 1,755 UL (about 5,000 lemmas) and has been obtained by inverting the morphological analysis of a previous project on German-French. When the result of the translation comes back from the server, it is automatically inserted in the same place in the image German stack (created by LIDIA the first time it is needed). English  Fig. 7: Translation into EnglishThe transfer is an adaptation of the French-German transfer. The generation adapts that of a previous feasibility study on French-English. The figures concerning dictionaries are the same as for German, except that the morphological genaration has less ULs (850 UL, or about 2,500 lemmas). Here is the result of the translation corresponding to the same answers in the disambiguation dialogue. Again, it is automatically placed in the image English target stack. Russian  Fig. 8: Translation into RussianTransfer and generation have been obtained by inversing the transfer and analysis phases of the large Russian-French system developed between 1972 and 1987. As for the other languages, transfer dictionaries (using interlingual acceptions, which are difficult to code) have been limited to what is necessary for the mockup. By contrast, the morphological generation has 12,000 UL (about 30,000 lemmas corresponding to 440,000 inflected and accentuated forms). As Russian is produced in a special Roman translitteration on the MT server, it is transcribed into cyrillic script when received by LIDIA on the Macintosh.Perspectives for DBMT Discussion of alternatives Is DBMT really a better approach than other alternatives? In our opinion, yes, because: (1) very often, these alternatives are not really feasible; (2) the results can be intrinsically better, if presented as self-explaining documents. First, machine aids for translators  ADDIN ENRef [2, 39, 40, 48] are usable only if there are available and affordable translators, and if they have enough time to do the job. But, in many situations, there are simply no such translators, especially if translations are required in several languages. For example, multinational firms, banks, etc., have many unmet translation needs. In Europe, scientists and engineers are engaged in many projects where communication is hampered by the language barrier. Even if competent translators are available, the delays are often such that translation is impossible. This is for example the case in European institutions, which are theoretically required to issue all important documents in all official languages, but are unable to do so, although they employ more than 1,200 full-time translators, and translate more than 1.2M pages a year. Further, the final versions of documents are too often ready at the last moment. Here, it would make more sense to analyze and disambiguate their parts as soon as they are ready, and to translate them at the last moment. Another possibility, often advocated, is to write in controlled languages, designed to be unambiguous, and use black box MT. This can be very successful, in restricted situations, as in the case of the TITUS system  ADDIN ENRef [25]. But it is very difficult to force people to write in a controlled language. Controlled languages are also difficult to design, and very task- and domain-specific. Finally, controlled languages are unambiguous for the analyzer designed to process them, but not for humans. While this may be convenient for man-machine communication, it may be counterproductive, or even dangerous, for human communication. If, for example, to replace (a mechanical part) is meant to mean only to replace with a new part (remplacer), and not to put back in place (replacer), a mechanic may well understand the second, unintended meaning, and put back into place an airplane part which should be replaced by a new one, leading to an accident. If the concept of self-explaining documents (see below) can be made to work in broad contexts, texts could be written without any restrictions beyond the usual ones, which concern style and terminology, and at the same time actually be less ambiguous than texts written in controlled languages. Even if translation is not an issue, the availability of text explainers could prove to be a major advance in document processing technology. A concept for the future: self-explaining documents Problems with reverse translations In the course of our experimentation, we have (again) observed that translation introduces ambiguities which are not present in the source text. (Traduttore, traditore !) It also happens that all disambiguated analyses of a sentence produce the same translation, which is as ambiguous as the original. One example was the translation from French into Russian of the famous sentence The man sees the girl in the park with a telescope. It also happens that reverse translations seem as ambiguous as the original. In the case where they are the same as the original, the author is even more confused, because it is not clear whether the system has done anything! In this case, goes the objection, what is the use of disambiguating the source text if ambiguities reappear in the translation(s), or -- even worse -- if new ones are created, and if reverse translation does not help to detect these problems? Would it not be better to try to produce translations which preserve the ambiguities, and dispense with interactive disambiguation altogether? Unfortunately, the experience of human translation shows that ambiguities can be exactly preserved only in some cases, and that to preserve ambiguities purposefully is quite difficult and often leads to unnatural expressions in the translation. It is also quite clear that the transferable ambiguities vary with the target language. Finally, although some texts may be intentionnally ambiguous, especially in poetry and politics, we take it that the vast majority of ambiguities are not intentional, but are rather due to the intrinsic nature of natural languages. Of course, some authors write more clearly than others, yet all authors write unambiguously only in programming languages, unambiguous by construction, but ambiguously in natural languages, ambiguous by nature! The concept of self-explaining documents This observation has led to the idea of self-explaining documents: if the target documents are accompanied by their (unambiguous) linguistic structure, with indications of potentially ambiguous parts, so that if the reader in the target language can obtain a clarification of unclear parts in a user-friendly way, the objection disappears. As human users are notably insensitive to ambiguities, however, we should find a way to warn the reader that the target text is ambiguous. In a multilingual DBMT setting, there is a very simple way to perform this task. The system analyzes the target text using the target language analyzer, and gets the corresponding MMC-structures. It then runs the disambiguation dialogue on the target side in automatic mute mode -- by having the system itself answer each question so that the accompanying structure is contained in the selected subset at each point, and records questions and answers. It is then possible to show the presence of ambiguities by any convenient means, e.g. by creating buttons which the reader may click to obtain the clarification which would have been given by the author himself, had the text been written in the target language! To simplify this process, the accompanying structure should then be unambiguous and concrete. Overall schema of an architecture for producing parallel self-explaining documents Here is a functional diagram of the processes we have discussed above. In GMA-structures (generating, multilevel and abstract), non-interlingual linguistic levels are underspecified, and (if present) are used only as reflections of corresponding surface levels in the source language, and are recomputed in the first generation phase, which we call paraphrase choice.  Fig.9: Diagram for producing parallel self-explaining documents with DBMT Potential and upscaling problems Full-scale, general DBMT systems for everyone will require extremely large grammatical and lexical knowledge bases. To cover a whole language, a lexical data base should contain on the order of 3 million terms, corresponding to 4 to 5 million monolingual acceptions, perhaps twice as many interlingual acceptions for systems designed to handle 10 to 20 languages. The development costs are staggering, and probably out of reach if conventional lingware engineering techniques are used. For instance, it has cost EDR (Tokyo) about 1,200 man years to develop 300K terms in 2 languages (200K terminological and 100K general), with the associated 640K interlingual concepts (200K terminological and 2*300K general, minus 60K common). At least 100 times more (1.2M man years!) would be needed for 3 million terms in 20 languages. This is why we advocate a step-by-step approach, along with the development of new groupware techniques for developing very large lexical data bases. Even if cost were not a problem, developing extremely large lexical data bases and keeping them up to date would be impossible using only professional teams of lexicographers. The quantity is too huge, changes and innovations are too fast, and only specialists can be competent in specific domains. It is a major challenge to design groupware lexical data base development techniques based on the contribution of lexical information by users of existing text explainers or DBMT systems. A distributed architecture would be very advantageous for this purpose, because lexical information created by users on their personal computers might transparently and automatically be sent to servers. For example, authors might add new senses to existing terms, add new terms, and propose translations in the languages they know. Professional teams would then process and refine this raw lexical material on server sites. This idea is not so far-fetched, and very similar to that used in Eurolang Optimizer"!  ADDIN ENRef [1], a distributed environment designed for professional translators. Evolution: Ariane-G5/LIDIA Our basic software has been considerably extended for this project. While Ariane-G5 itself has remained stable, an Ariane-G5 server has been developed by P.Guillaume. A LIDIA user simply sends messages to Ariane-G5 by e-mail. Here is an example, for the sentence Le vtrinaire prend la patte de loiseau et la bague [the veterinarian takes the leg of the bird and the ring/and rings it]. /*--SEPARATEUR--*/ stack_name Demo_LIDIA card_id 8446 object_id 2 object_type cdfl visible T treatment analysis language franais /*--SEPARATEUR--*/ LGS = FVX TLS = TY0 LLC = () TYTR = A /*--SEPARATEUR--*/ *LE VE!1TE!1RINAIRE PREND LA PATTE DE L' OISEAU ET LA BAGUE . /*--SEPARATEUR--*/ Here is the message returned with the MMC-structure. /*--SEPARATEUR--*/ ========================================================================= Received: from imag.imag.fr by durian.imag.fr (IBM VM SMTP V2R2) with TCP; Fri, 31 Mar 95 18:23:49 WDT To: lidia17@durian.imag.fr From: lidia@warna.imag.fr (lidia) Subject: ana_C8446_O2_Tcdfl /*--SEPARATEUR--*/ stack_name Demo_LIDIA card_id 8446 object_id 2 object_type cdfl visible T treatment analysis language franais /*--SEPARATEUR--*/ LGS = FVX TLS = TY0 LLC = () TYTR = I /*--SEPARATEUR--*/ *LE VE!1TE!1RINAIRE PREND LA PATTE DE L' OISEAU ET LA BAGUE . /*--SEPARATEUR--*/ 1: 'ULTXT' (2: 'ULFRA' (3: 'ULSOL' (4: 'PHVB' (5: 'DGN' (6: 'LE', 7: 'VE!1TE!1RINAIRE'), 8: 'NV' (9: 'PRENDRE'), 10: 'DGN' (11: 'LE', 12: 'PATTE', 13: 'GP' (14: 'DE', 15: 'LE', 16: 'OISEAU'), 17: 'DGN' (18: 'ET', 19: 'LE', 20: 'BAGUE')), 21: '.')), 22: 'ULSOL' (23: 'PHVB' (24: 'DGN' (25: 'LE', 26: 'VE!1TE!1RINAIRE'), 27: 'NV' (28: 'PRENDRE'), 29: 'DGN' (30: 'LE', 31: 'PATTE', 32: 'GP' (33: 'DE', 34: 'LE', 35: 'OISEAU')), 36: 'PHVB' (37: 'ET', 38: 'GPRON' (39: 'PATTE'), 40: 'NV' (41: 'BAGUER')), 42: '.')))) end of the geometric part, beginning of algebraic part (content of decorations) 1 '': UL('ULTXT'). 2 '': UL('ULFRA'). 3 '': UL('ULSOL'),MODIF(NON). 4 'PREND': UL('PHVB'),LINKS(OUI),RECHTS(OUI),ENONCP(DECL),K(PHVB),SUBV(VF),VALET(Q),VOIX(ACT), ARGS(A0,A1),CAT(V),MT(IPR),NBR(SING),PERS(3),PHASE(NONACC). 5 'VE!1TE!1RINAIRE': UL('DGN'),FS(SUJ),K(GN),RL(ARG0),SUBN(NC),VALET(N),CAT(N,D),GNR(MAS), NBR(SING),PERS(3). 6 '*LE': UL('LE'),FS(DES),CAT(D),GNR(MAS),NBR(SING),TYPOG(PCAP). 7 'VE!1TE!1RINAIRE': UL('VE!1TE!1RINAIRE'),FLAG(CPRED)*,FS(GOV),CAT(N),GNR(MAS),NBR(SING),PERS(3),SEMN(ANIME),SENS(1),SSANIM(HUM). 8 'PREND': UL('NV'),LINKS(OUI),RECHTS(OUI),ENONCP(DECL),K(PHVB),SUBV(VF),VALET(Q),VOIX(ACT),ARGS(A0,A1),CAT(V),MT(IPR),NBR(SING),PERS(3),PHASE(NONACC). 9 'PREND': UL('PRENDRE'),FLAG(CPRED),AUX(AVOIR),FS(GOV),VAL0(N),VAL1(N),CAT(V),NBR(SING),PERS(3),SEM1(CONCRET),SEMZ(ANIME),SENS(1,2,4),SSCONC1(MAT). 10 'PATTE': UL('DGN'),RECHTS(OUI),VCOOR(OUI),FS(OBJ),K(GN),RL(ARG1),SUBN(NC),VALET(N),CAT(N,D),GNR(FEM),NBR(SING),PERS(3). 11 'LA': UL('LE'),FS(DES),CAT(D),GNR(FEM),NBR(SING). 12 'PATTE': UL('PATTE'),FLAG(CPRED),FS(GOV),CAT(N),GNR(FEM),NBR(SING),SEMN(ANIME,CONCRET),SENS(1,2),SSANIM(ANIMAL). 13 'OISEAU': UL('GP'),FS(COMP),K(GN),SUBN(NC),VALET(DEN),CAT(N,D,S),GNR(MAS),NBR(SING),PERS(3). 14 'DE': UL('DE'),FS(REG),CAT(S). 15 'L''': UL('LE'),FS(DES),CAT(D),GNR(MAS),NBR(SING). 16 'OISEAU': UL('OISEAU'),FLAG(CPRED),FS(GOV),CAT(N),GNR(MAS),NBR(SING),SEMN(ANIME),SENS(1), SSANIM(ANIMAL). 17 'BAGUE': UL('DGN'),FS(COORD),K(GN),RL(ID),SUBN(NC),VALET(N),CAT(N,D),GNR(FEM),NBR(SING),PERS(3). 18 'ET': UL('ET'),FS(REG),CAT(C). 19 'LA': UL('LE'),FS(DES),CAT(D),GNR(FEM),NBR(SING). 20 'BAGUE': UL('BAGUE'),FLAG(CPRED),FS(GOV),CAT(N),GNR(FEM),NBR(SING),SEMN(CONCRET),SENS(1,2). 21 '.': UL('.'),CAT(P),PONC(DR). and so on for the second geometrical structure (dominated by ULSOL). /*--SEPARATEUR--*/ On the Ariane-G5 side, however, things are more complex. A whole network of virtual machines takes care of the various parts of the processing (analysis into MMC-structure, abstraction from UMC-structure into UMA-structure, transfers and generations into various target languages). More recently, P.Guillaume has also developed a WWW front end for Ariane-G5: knowing the language codes and using the appropriate character set and transcription, it is possible to run an MT application on a text from any machine connected to the Web. Using Ariane-G5/LIDIA within UNL UNL Our LIDIA-1.2 mockup has shown that Dialogue-Based MT is a technically feasible and promising paradigm for many translation situations. Its distributed architecture has been successfully tested from distant locations. However, it is necessary to build and experiment with full-size prototypes to be sure that upscaling this technology is economically and technically viable. This is one of the reasons why we have welcomed the opportunity to participate in the UNL project. Other motivations are the very international and highly multilingual character of the project, its emphasis on producing a working system, and its linguistic architecture. UNL is a project of multilingual personal networking communication initiated by the University of United Nations based in Tokyo. The pivot paradigm is used: the representation of an utterance in the UNL interlingua (UNL stands for "Universal Networking Language") is a hypergraph where nodes bear UWs ("Universal Words", or interlingual acceptions) with semantic attributes, and arcs bear semantic relations (deep cases, such as agt, obj, goal, etc:). Going from a text to the corresponding "UNL text" or interactivley constructing a UNL text is called "enconversion", while producing a text from a sequence of UNL graphs is called "deconversion". This departure from the standard terms of analysis and generation is used to stress that this is not a classical MT project, but that UNL is planned to be the source format preferred for representing textual information in the envisaged multilingual network environment. The schedule of the project, beginning with deconversion rather than enconversion, also reflects that difference. 13 languages are tackled during the first 3-year phase of the project, while many more are to be added in the second phase. Each group is free to reuse its own software tools and/or lingware resources, or to develop directly with UNL-provided tools. Emphasis is on a very large lexical coverage, so that all groups will presumably spend most of their time on the UNL-NL lexicons, and develop tools and methods for efficient lexical development. By contrast, grammars can be initially limited to those necessary for deconversion, and then gradually expanded to allow for more naturalness in formultating text to be enconverted. Architecture of deconversion and enconversion Deconversion using Ariane-G5 occurs in three steps: 1) Transformation of UNL graphs into Ariane-G5 UNL trees. A parametrizable tool has been implemented in MCL and a direct one in HyperCard (with integration into CASH). 2) UNL-French transfer. (Actually, the current implementation does a kind of very simple "post-analysis" to prepare the trees for the lexical transfer). 3) French generation. Symmetrically, enconversion using Ariane-G5/LIDIA will occur in 3 steps: 1) French analysis and interactive disambiguation. 2) French-UNL transfer. 3) Transformation of Ariane-G5 UNL trees into UNL graphs. Ariane-G5 UNL trees are UMA-structures with their usual geometry, and nodes containing UNL information in known variables, such as UNLRS for the UNL deep case, UL for the UW, UNLREF for the references (coindexing), and UNLATTR for the attributes. Lexical engineering for UNL-FR The lexical work is determined by the content of the central UNL database. At the moment, it contains about 95765 English "headwords", with nearly 220000 associated UWs. The task is to produce: 1) the corresponding French-UNL data. 2) the corresponding Ariane-G5 dictionaries for French analysis and generation, and transfers between UNL and French. 3) the dictionary for interactive disambiguation (when enconversion is tackled). The method used to attain this goal is as follows: 1) transform the UNL files into a collection of CLOS objects corresponding to the headwords. 2) enrich these objects by French equivalents and associated information found in available dictionaries such as the USM-MAE-GETA French-English-Malay dictionary, BDTAO, and various MT-oriented dictionaries developed under Ariane-G5 or by other cooperating groups. 3) transform them into a collection of Word files, where each paragraph corresponds to a particular field and has a corresponding style, and each entry contains dummy paragraphs for all obligatory fields. 4) distribute the Word files to lexicographs. The disquettes come with macros which provide online help in the form of menus for all fixed lists (categories, domains, possible next styles, etc.) and of verification utilities. 5) transform the resulting files back into CLOS objects, and store them in a CLOS-based multilingual database organized as PARAX  ADDIN ENRef [3], i.e., as a central structured collection of UWs and linked with monolingual bases (at least English and French). 6) enrich the CLOS base by generating the Ariane-G5 related information. 7) mirror this CLOS base using a commercial DBMS system such as 4D, to be used for server functions. 8) produce all necessary dictionaries. 9) iterate the process, ideally in an incremental way: while the CLOS base should be the center of the lexicologic work, the server should be the source of distribution of all lexicographic work, but no lexicographic work should be directly performed on it. Steps 1-4 have been completed. Steps 5-8 are under way. At the time of writing, about 15,000 UWs have been completely processed. Evolution towards speech translation: integration within CSTARII Task and general methodology In Speech Translation (ST) as in text translation, there are several possible kinds of translation situations which lead to very different requirements. High-quality output might be required for the dissemination of crucial information, but would be obtainable only through severe restrictions on the input and possibly require a high degree of user interaction. On the other hand, on-line aids for human interpreters might be built with simple word-spotting techniques coupled with dictionary access and user-adaptative filtering. We have recently started to investigate ST in the context of the CSTAR project, which lies somewhere between these two extremes. The task In the context of CSTARII, the task is to translate human-to-human tourism-related dialogues (booking a room, buying seats for a show, etc.). As in human interpretation, translation need not be perfect by any means. Because the two interlocutors know about the subject matter and share a common goal, it is enough to produce approximate and possibly incomplete translations, provided that some feedback is given about what has been or will be translated. The main task of our CLIPS++ group within CSTARII is to integrate French in the architecture and experiments of the consortium. This implies building a translation system from spoken French into at least one target language or into the task-specific interchange format (IF), building or integrating a speech syntheziser for French, and generating French from the IF, because no partner plans to develop translations into French. We intend to produce IF representations as well as full translations into German, Italian, and perhaps English, so that the partners for these languages will also be able to generate them from our IF structure. The demonstrators under construction will conform to a scenario where a client converses with his travel agent and 2 or 3 foreign travel agents speaking different languages, each dialogue being translated so that all interlocutors can follow all dialogues. An interesting aspect due to the constraints of the project is that it will be possible to compare different approaches to MT for exactly the same task, namely an interlingua approach (IF) and two transfer approaches, a GB-based transfer approach using concrete trees at LATL, and a multilevel transfer approach using abstract trees at GETA. The approach taken The language at hand is quite restricted and can be handled as a sublanguage, with heuristic techniques. However, the speech recognition phase may deliver several linguistically plausible utterance candidates. Hence, the approach to analysis is to produce one representation for each such utterance candidate. Although there is almost no room for interactive disambiguation in the Machine Interpretation of Human Dialogues, it seems both necessary and possible to follow the CMU technique and ask the user one question before sending a translation: "Which is the meaning you want me to translate"? Hence, the UMA-structures produced by the analyzer for one utterance should be generated as standard text and proposed to the user in a menu. In order to better integrate speech recognition and language analysis, we want to start from a lexical lattice (see  ADDIN ENRef [17] for a more detailed discussion). If we can develop at some point a speech recognizer incorporating a powerful language model, the lattice will probably contain full or partial trees. But all MT systems, including Ariane-G5, expect a string of characters as input. How can we solve this problem? In the first prototype, the output lattice contains only phonetic words, and we simply transform it into the list of its possible traversals. In the future, we plan to develop a GCFG (Generalized Context-Free) tool for more complex lattices. The input to Ariane-G5 is thus a normal text, where each sentence corresponds to one possible traversal of the lattice, and is a sequence of phonetic words. After morphological analysis, the utterance is represented by a tree dominated by a 'ULTEXT' node, and subtrees dominated by 'ULFRA' nodes corresponding to each traversal. From then on, analysis is done in parallel on these subtrees, leading to subtrees coding UMA-structures. In the process, some subtrees may disappear because the corresponding sequence of phonetic words cannot be analyzed as a full utterance. It is also possible to erase only the "incorrect" parts and keep the "correct" parts. A first prototype We have developed an end-to-end first prototype in a few months. The goals were to: 1) integrate the components developed by the various members, 2) produce a complete prototype showing 2 target languages (German and English), 3) demonstrate French synthesis, without having yet developed generators from the IF, 4) use telecommunication links in at least a part of the demo, 5) use lattices as interfaces between speech recognition and machine translation. Architecture The hardware architecture of the demonstrator is shown in the figure below.  Shared speech recognition The speech recognizer used in this prototype is an adaptation of the ECHO (Environnement et Communication Homme-Ordinateur) system built by the GEOD group. ECHO is a connected speech recognition system which uses the Hidden Markov Models approach. The system has been orignally implemented on UNIX platforms and then adapted for PC computers. It has a C/C++ language interface (as Dynamic Link Libraries) for developers and an high level interface for end users. From the speech signal, the new ECHO/CSTAR version outputs a phonetic word lattice. At this point, two paths are followed, the first one to English and the second one to German. The first path is executed on the PC, while the second goes to a Macintosh which calls a remote server. In each case, the MT lingware produces one or more French orthographic renderings of each possible trajectory in the lattice, by a kind of reverse translation (phonetic French into written French), and the user can choose "what will be translated". Path to English The ITS-II French analyzer has been considerably reconfigured to accept the phonetic output. It has then been connected to the existing generator of French and to the existing transfer and English generator. Path to German The lattice produced by the speech recognition component is sent by ftp (file transfer protocol) to a Macintosh which handles the data and schedules the production of the expected results. HTTP requests are sent from the Macintosh to the translation server to get: the speech to text translation of the phonetized input, and the German translation of the French Phonetic input. Translation into German and into French text are adaptations of existing Ariane-G5 lingware. Note that the interface presented below requires that the two resulting texts are strictly parallel. Work done to adapt the components Data collection 1) We have created about 400 dialogues, each of about 10 turns, in the domain of hotel reservation. Writers were instructed to follow the general pattern given by 4 example dialogues, and to stick to some negotiation concerning the number and category of the room(s), the dates, the prices, and the location of the hotel. 2) These dialogues have been processed to extract the relevant vocabulary (about 800 lemmas) and the most frequent expressions (such as Bonjour Madame!). Speech recognition 1) A restricted sublanguage has then been built, with restricted syntax and vocabulary. For reasons of speed on a PC, only 180 lemmas (900 wordforms) have been retained, and expressions quite natural in speech. 2) This vocabulary has then been learned from several speakers with a Markov model of words. 3) ECHO has then been adapted to this sublanguage. ECHO is a markovian system with word models, controlled by a finite-state automaton language model. 4) In order to prepare for the extension to speaker independence, the 400 dialogues have been read by several speakers, recorded with two microphones, and acquired on machine in stereo. 5) Labelling of this data has begun, in order to automatically learn optimal acoustic units (semi-syllables). Machine translation with Ariane-G5 1) We have first built a specific morphological analyzer using the phonetic transcription as input. 2) We have then implemented very quickly a first version of the analyzer, geared towards processing of three dialogues, using the technique of translation memory. This version has been used to integrate the first end-to-end prototype. 3) This analyzer has then been connected to the available French generator and French-German transfer and generator, thereby indexing the necessary vocabulary. 4) We have then built a second version of the analyzer, which uses a memory of short, slightly parametrized fragments (je voudrais, N chambres, pour N nuits, etc.) and a language model expressed as a finite-state automaton on these fragments. This can handle a considerably greater variety of turns. No German speech synthesizer has been integrated for this demo, but it is possible to send the selected German translation to any machine running a German speech synthesizer via the Internet. Orthographic French is pronounced by the LAIPTTS synthesizer. Machine translation with ITS-II The ITS-2 MT system developed at LATL (E. Wehrli) runs on PC machines under Windows 95 or Windows NT. The French-English version is an adaptation of the standard ITS-II F-E lingware. It receives from the speech recognizer a phonetic representation of the spoken sentence (a lattice), where some phonemes may not have been completely disambiguated (archiphonemes). The linguistic engine takes the linearized phonetic representations as input and attempts to parse them, producing abstract syntactic representations for the correct ones and discarding the others. An example of the various levels is given in (1). (1) a. j [-]m^r[-] yn /br av[-]k du/ pur trwa jur. b. [TP [DP j'] aimerais [VP [DP une [NP chambre [PP avec [NP douche ]]]] [PP pour [DP trois [NP jours ]]]]] c. [TP [DP I ] would [VP like [DP a [NP room [PP with [NP shower ]]]] [PP for [DP three [DP days ]]]]] d. I would like a room with shower for three days. (1a) corresponds to the phonetic input with unresolved ambiguities noted with square brackets, and alternatives separated with a dash symbol (e.g. [-]). (1b) is the syntactic skeleton of the GB-structure produced by the parser. It is also the structure used by the transfer component. (1c) is the corresponding target GB-structure produced by the translator. Finally, (1d) is the target sentence, which is passed to the DECTalk speech synthesizer. If the output of the speech recognizer is ambiguous, the possible interpretations are regenerated into orthographic French so that the user can choose which one will be translated. Orthographic French was pronounced by the Lernhout & Houspie synthesizer because the PC version of LAIPTTS was not yet available. Speech synthesis with LAIPTSS LAIPTTS  ADDIN ENRef [34, 35] is a high-quality text-to-speech system for French built by LAIP at Lausanne. Currently, it uses the Mons (Belgium) MBROLA diphone output system to produce audible output. The system consists of a 350K application (without interface) and uses a 2 Mb dictionary as well as a 4.8 Mb diphone database. Like most text-to-speech systems, LAIPTTS is structured into four main modules. The first module takes written text and generates an annotated phonetic chain of each sentence on the basis of a dictionary and graphemo-phonetic rules. The chain is parsed into prosodic groups, and various phonological rules (liaison, chaining, schwa-handling, syllabification) are applied. In the next module, durations and F0 values are generated. These values are combined with diphone segments in the subsequent module, after which the entire signal is reproduced. Calculations for the second and following sentences in a text are performed in parallel with sound output of the preceding sentence. This provides real-time synthesis performance for unrestricted text on most high-entry personal computers (PowerPC, Pentium-level). Integration Prolem & approach From the start, it has been clear that a distributed architecture was necessary. We have in fact integrated seven components on three machines using three different OSs: - ECHO (speech recognizer) on a PC, - ITS-II (phonetic French to orthographic French and to orthographic English) on a PC, - Ariane-G5 (phonetic French to orthographic French and German) on an IBM 9221-130, - LAIPTTS (French speech synthesizer) on a Macintosh, - Lernhout & Hauspie (French synthesizer) on a PC, - User interface and components coordinator (on a Macintosh), - Web utilities (in MCL on Macintosh and C on IBM-9221). 1) We have first defined the phonetic transcription input to the MT systems, and the detailed format of the data to be exchanged. This comprises the exact syntax of the lattices, including comments. 2) We have then worked on the communication mechanisms, arriving at a solution in which the PC sends lattices to the Mac by ftp, while the Mac communicates with the IBM through http. 3) We have used the whiteboard architecture to do the integration at the logical level. At the logical level, we do not care where the components run, or under which operating system. The only thing we want is fast and reliable communication methods for exchanging data, be they mailboxes, sockets, http or other. Components may be running in distant locations. The main idea of the whiteboard architecture is that a coordinator maintains a possibly partial image of the essential data structures manipulated by the components, and acts like an orchestra conductor, synchronizing the work of the components according to its private strategy. We have been working on that architecture in cooperation with ATR  ADDIN ENRef [17], and have tested and improved it in two different forms in the LIDIA project. Its main advantage over other architectures (blackboard, communicating agents, etc.) is its simplicity: components never communicate directly, and never have to adapt to changes in a common data structure. Ariane-G5/CSTAR and a demo of the "German path" Let us now detail the components of the "German" path. The scheduling component has been written in Macintosh Common Lisp (MCL). It is made of several processes. Permanent processes fetch-lattice-process: this process regularly scans a CSTAR-in-mailbox where any lattice produced by the speech regognition component is dropped from the PC (by ftp). When a new lattice file is found, it transforms it into an Ariane-G5 text, where a paragraph corresponds to one trajectory, and may contain several sentences if the archiphonemes (such as E/ for or ) present in the input give rise to several possible phonetic sentences, given the current dictionary of phonetic forms prepared from the list of active lemmas. process-lattice-process: this process scans regularly the requests queue, and whenever an object is found, treatment requests (Phonetic French to French Text and German translation) are launched as processes. These processes are called http-ariane-requests.  Temporary processes ariane-http-request: there is one such process per pending request. For each lattice, two http requests are sent to the Ariane server, one to get the French orthographic rendering(s) and one to get the German translation(s). The server answers by sending back a stamp. The process then checks regularly if the result is available, using the stamp to identify its request. cstar-request: when a result is given to one of the two requests involved in the treatment of one turn, a cstar-request process is created. When both results have been delivered by the Ariane-G5 server, a dialogue is proposed to the speaker. This process is ephemeral.  A dialogue is then produced to ask the user to choose the proper French orthographic rendering, if several have been produced by the recognizer or the analyzer.  When an item is selected, the phonetic form of the input and the German translation appear in the lower part of the window. Pushing the Say it button invokes LAIPTTS, which pronounces the selected French orthographic rendering. Further evolutions under way Improving the SR phase ECHO was not designed to handle spontaneous speech and large vocabularies, and can't be extended easily in that direction. We are currently experimenting in two directions. First, we are trying to use the most recent versions of high-quality coommercial SR systems such as IBM Dictation Tool and Dragon Dictate, which now begin to accept continuous input. However, they were not designed for spontaneous speech until a very recent date, and it is not sure they can be used efficiently in our context. Second, we are cooperating with CMU/CLT to implement a French SR under the generic JANUS framework  ADDIN ENRef [52], which is designed exactly for the purposes pursued by CSTARII. Building and passing information between utterances We have studied how to cope with ellipsis and anaphora across turns, and have come up with the following method: store in our whiteboard (on the Mac) the memory of possible candidates, add special markers at the beginning of the text sent to Ariane for each turn (after morphological analysis, this will give rise to a special "sentence" subtree), arrange during analysis that the output French text contains the appropriate record, attached to each possible orthographic rendering of the turn. iterate. More integration between SR and MT If we have time during the project, or perhaps only afterward, we would also like to develop a GCFG-based tool to handle lattices directly. Substantial work has been described in detail in the literature, notably by P. Quinton (1980, KEAL system) and M.Tomita, so that the implementation effort should be reasonable. It would however be necessary to adapt the analyzer to the new tool, usually a heavy task. Conclusion We have described the computer tools and linguistic methods developed at Grenoble during many years for building MT systems for revisors. As they are not embodiments of a particular theory, they are quite easy to adapt to new problems. In the last few years, they have in fact been revised and further developed in the framework of new research on high quality MT for monolingual authors (MT-A), relying on a disambiguation dialogue with the author (DBMT), following an all-paths analysis. The evolution of Ariane-G5/LIDIA and associated linguistic methodologies is now motivated by two projects of different aims and requirements. The most important points of current developments are the construction of a large lexical database from which coherent dictionaries for MT and for interactive disambiguation will be generated, and the development of robust tools for the integration of heterogeneous speech translation systems using the "whiteboard" approach. For the future, it will be important to design and implement specialized languages enabling linguists to work directly on complex lattices, with two complementary aims: (1) to better integrate the SR and MT parts of ST systems; and (2) to make it possible to ignore ambiguities most of the time, but to handle them directly at particular points in the overall process. Acknowledgments The research described here has been supported by several grants of the Ministery in charge of Research, mainly in the context of the Eureka EUROLANG project. It is mainly led by academics and researchers from the University Joseph Fourier (Grenoble 1) and the Centre National de la Recherche Scientifique (CNRS). Inspiration and encouragement to embark on a Speech Translation project have mainly come from ATR, which has led the way in this unchartered territory since 1986. Funding for our research in ST comes from UJF, IMAG, and CLIPS. Our participatation in the UNL project is partially funded by the IAS (UNU, Tokyo). Thanks also go to the Ministery of Foreign Affairs for supporting the cooperative aspect of these projects. Last but not least, thanks to Mark Seligman, who has spent a considerable amount of time improving our English expression. References  ADDIN ENBib [1] Bachut D. (1994) Le projet EUROLANG : une nouvelle perspective pour les outils d'aide la traduction. Proc. TALN-94, journes du PRC-CHM, 78 avril 1994, Univ. de Marseille. [2] Bachut D. & Verastegui N. (1984) Software tools for the environment of a computer-aided translation system. Proc. COLING-84, Stanford, ACL, pp.330334. [3] Blanc ., Srasset G. & Tchou F. (1994) Designing an Acception-Based Multilingual Lexical Data Base under HyperCard: PARAX. Research Report, GETA, IMAG (UJF & CNRS), Aug. 1994, 10p. [4] Blanchon H. (1992) A Solution to the Problem of Interactive Disambiguation. Proc. COLING-92, Nantes, 23-28 July 1992, vol. 4/4, pp.1233-1238. [5] Blanchon H. (1994) Perspectives of DBMT for monolingual authors on the basis of LIDIA-1, an implemented mockup. Proc. 15th International Conference on Computational Linguistics, COLING-94, 5-9 Aug. 1994, vol. 1/2, pp.115119. [6] Boitet C., Rd. (1982) "DSE-1" Le point sur ARIANE-78 dbut 1982. Contrat ADI/CAP-Sogeti/Champollion (3 vol.), GETA, Grenoble, fvrier 1982, 400p. [7] Boitet C. (1986) The French National MT-Project: technical organization and translation results of CALLIOPE-AERO. Computers and Translation, 1, pp.281309. [8] Boitet C. (1989) Motivation and Architecture of the LIDIA Project. Proc. MTS-II (MT Summit), Munich, 16-18 aot 1989, pp.5054. [9] Boitet C. (1990) Towards Personal MT : on some aspects of the LIDIA project. Proc. COLING-90, Helsinki, 20-25 aot 1990, ACL, vol. 3/3, pp.30-35. [10] Boitet C. (1993) La TAO comme technologie scientifique: le cas de la TA fonde sur le dialogue. In "tudes et Recherches en Traductique", A. Clas & P. Bouillon, ed., Presses de l'Universit de Montral, Montral, pp.109148. [11] Boitet C. (1994) Dialogue-Based Machine Translation and Sub-Languages. Proc. ICLA-94, 26-28 July 1994, USM, 14p. [12] Boitet C. & Blanchon H. (1993) Dialogue-Based MT for Monolingual Authors and the LIDIA project. Proc. NLPRS'93 (Natural Language Processing Rim Symposium, 6-7/12/93, Kyushu Institute of Technology, pp.208222. [13] Boitet C. & Blanchon H. (1994) Multilingual Dialogue-Based MT for monolingual authors: the LIDIA project and a first mockup. Machine Translation, 9/2, pp.99132. [14] Boitet C., Guillaume P. & Quzel-Ambrunaz M. (1978) Manipulation d'arborescences et paralllisme: le systme ROBRA. Proc. COLING-78, Bergen, August 1978, 12p. [15] Boitet C. & Ndobejkine N. (1981) Recent developments in Russian-French Machine Translation at Grenoble. Linguistics, Linguistics, 19, pp.199271. [16] Boitet C. & Ndobejkine N. (1986) Toward integrated dictionaries for M(a)T: motivations and linguistic organization. Proc. COLING-86, Bonn, IKS, pp.423428. [17] Boitet C. & Seligman M. (1994) The "Whiteboard" Architecture: a way to integrate heterogeneous components of NLP systems. Proc. COLING-94, 59 August 1994, pp.243246, 7p. [18] Boitet C. & Zaharin Y. (1988) Representation trees and string-tree correspondences. Proc. COLING-88, Budapest, 2227 Aug. 1988, ACL, pp.5964. [19] Brown R. D. (1989) Augmentation. Machine Translation, 4, pp.1299-1347. [20] Brown R. D. & Nirenburg S. (1990) Human-Computer Interaction for Semantic Disambiguation. Proc. COLING-90, Helsinki, 20-25 aot 1990, ACL, vol. 3/3, pp.42-47. [21] Chandioux J. & Gurard M.-F. (1981) METEO: un systme lpreuve du temps. META (Journal des Traducteurs), 1, pp.1722. [22] Chandler B., Holden N., Horsfall H., Pollard E. & McGee Wood M. (1987) N-tran Final Report. Alvey Project, 87/9, CCL/UMIST, Manchester. [23] Chappuy S. (1983) Formalisation de la description des niveaux d'interprtation des langues naturelles. Thse de 3me cycle, UJF, Grenoble, juin 1983, 120p. [24] Chauch J. (1975) Les langages ATEF et CETA. AJCL, AJCL (American Journal of Computational Linguistics), microfiche 17, pp.21-39. [25] Ducrot J.-M. (1988) Le systme TITUS IV. In "Traduction Assiste par Ordinateur. Actes du sminaire international sur la TAO et dossiers complmentaires", A. Abbou, ed., Observatoire des Industries de la Langue (OFIL), Paris, mars 1988, pp.5571. [26] Durand J.-C. (1988) TTEDIT : Un diteur transformationnel d'arbres. Nouvelle Thse, UJF (Grenoble 1), mars 1988, 120p. [27] Gaschler J. & Lafourcade M. (1994) Manipulating human-oriented dictionaries with very simple tools. Proc. 15th International Conference on Computational Linguistics, COLING-94, 5-9 Aug. 1994, 4p. [28] Gerber R. & Boitet C. (1985) On the design of expert systems grafted on MT systems. Proc. TMI-85 (Conf. on Theoretical and Methodological Issues in Machine Translation of natural language), Hamilton, N.Y., Colgate Univ., pp.116-134. [29] Guilbaud J.-P. (1988) Ralisation en ARIANE d'un transfert des structures produites par l'analyseur du franais de B'VITAL vers des structures interfaces IS EUROTRA. Eurotra contract report, GETA, IMAG, juin 1988, 205p. [30] Guillaume P. (1989) Ariane-G5 - Extensions apportes au langage SYGMOR. GETA, IMAG, janvier 1989, 6p. (Ariane-G5 version 3) [31] Guillaume P. (1989) Ariane-G5 - Les langages spcialiss TRACOMPL et EXPANS. GETA, IMAG, septembre 1989, 93p. (Ariane-G5 version 3) [32] Huang X. M. (1990) A Machine Translation System for the Target Language Inexpert. Proc. COLING-90, Helsinki, 20-25 Aug. 1990, ACL, vol. 3/3, pp.364-367. [33] Kay M. (1973) The MIND system. In "Courant Computer Science Symposium 8: Natural Language Processing", R. Rustin, ed., Algorithmics Press, Inc., New York, pp.155-188. [34] Keller E. (1997) Simplification of TTS architecture vs. operational quality. Proc. Eurospeech '97. (in press) [35] Keller . & Zellner B. (1996) Output requirements for a High-Quality Speech Synthesis System: The Case of Disambiguation. Proc. MIDDIM-96 Seminar, Le Col de Porte, 1214 August 1996, pp.300-308. [36] Lepage Y. (1986) A language for transcriptions. Proc. COLING-86, 1986, IKS, vol. 1/1, pp.402404. [37] Lepage Y. (1989) Grammaires Correspondancielles dIdentification. Thse, UJF, Grenoble, juin 1989, 184p. [38] Maruyama H., Watanabe H. & Ogino S. (1990) An Interactive Japanese Parser for Machine Translation. Proc. COLING-90, Helsinki, 20-25 aot 1990, ACL, vol. 2/3, pp.257-262. [39] Melby A. K. (1981) Translators and Machines - Can they cooperate ? META, 26/1, pp.23-34. [40] Melby A. K. (1982) Multi-Level Translation Aids in a Distributed System. Proc. COLING-82, Prague, 5-10 juillet 1982, vol. 1/2, pp.215-220. [41] Moneimne W. (1989) TAO vers l'arabe. Spcification d'une gnration standard de l'arabe. Ralisation d'un prototype anglais-arabe partir d'un analyseur existant. Thse, UJF, Grenoble, juin 1989, 159p. (+ annexes) [42] Nirenburg S. (1989) Knowledge-based Machine Translation. Machine Translation, 4, pp.5-24. [43] Nyberg E. H. & Mitamura T. (1992) The KANT system: Fast, Accurate, High-Quality Translation in Practical Domains. Proc. COLING-92, Nantes, 23-28 July 92, ACL, vol. 3/4, pp.10691073. [44] Quzel-Ambrunaz M. (1990) Ariane-G5 v.3 - Le moniteur. GETA, IMAG, juin 1990, 206p. [45] Sadler V. (1989) Working with analogical semantics : Disambiguation technics in DLT. T. Witkam, ed., Distributed Language Translation (BSO/Research), Floris Publications, Dordrecht, Holland, 256p. [46] Srasset G. (1994) Interlingual Lexical Organisation for Multilingual Lexical Databases. Proc. 15th International Conference on Computational Linguistics, COLING-94, 5-9 Aug. 1994, 6p. [47] Somers H. L., Tsujii J.-I. & Jones D. (1990) Machine Translation without a source text. Proc. COLING-90, 20-25 Aug. 1990, ACL, vol. 3/3, pp.271-276. [48] Tong L. T. (1986) English-Malay Translation System: A Laboratory Prototype. Proc. COLING-86, Aug. 1988, IKS, pp.639642. [49] Vauquois B. (1988) BERNARD VAUQUOIS et la TAO, vingt-cinq ans de Traduction Automatique, ANALECTES. BERNARD VAUQUOIS and MT, twenty-five years of MT. C. Boitet, ed., Ass. Champollion & GETA, Grenoble, 700p. [50] Vauquois B. & Boitet C. (1985) Automated translation at Grenoble University. Computational Linguistics, 11/1, January-March 85, pp.2836. [51] Vauquois B. & Chappuy S. (1985) Static grammars: a formalism for the description of linguistic models. Proc. TMI-85 (Conf. on theoretical and metholodogical issues in the Machine Translation of natural languages), Aug. 1985, pp.298-322. [52] Waibel A. (1996) Translation of Conversational Speech. IEEE Computer, 29/7, pp.41-48. [53] Wehrli E. (1990) STS: An Experimental Sentence Translation System. Proc. COLING-90, Helsinki, 20-25 Aug. 1990, ACL, vol. 1/3, pp.76-78. [54] Whitelock P. J., Wood M. M., Chandler B. J., Holden N. & Horsfall H. J. (1986) Strategies for Interactive Machine translation : the experience and implications of the UMIST Japanese project. Proc. COLING-86, Bonn, 25-29 aot 1986, IKS, pp.25-29. [55] Wood M. M. G. & Chandler B. (1988) Machine Translation For Monolinguals. Proc. COLING-88, Budapest, 22-27 Aug. 1988, pp.760763. [56] Yan Y. F. (1987) Vers une ingnierie de la production de linguiciels. Spcification et ralisation d'un prototype de poste de travail linguistique pour la spcification de correspondances structurales. Thse, UJF, Grenoble, juin 1987, 120p. [57] Yang P. (1981) Un essai sur la gnration du chinois. Rapport de stage, GETA, Grenoble, Dec. 1981, 30p. (+ annexes) [58] Zaharin Y. (1986) Strategies and heuristics in the analysis of a natural language in Machine Translation. Proc. COLING-86, Bonn, Aug. 1986, pp.136139.  -o-o-o-o-o-o-o-o-o-o-o- Contents  TOC \o "1-3" I. Basic software tools and linguistic methodology for multilingual MT-R  GOTOBUTTON _Toc405632602  PAGEREF _Toc405632602 2 A. Ariane-G5, an MT shell for building multilingual MT-R systems  GOTOBUTTON _Toc405632603  PAGEREF _Toc405632603 2 1. General principles  GOTOBUTTON _Toc405632604  PAGEREF _Toc405632604 2 2. The interactive interface  GOTOBUTTON _Toc405632605  PAGEREF _Toc405632605 8 3. The specialized languages  GOTOBUTTON _Toc405632606  PAGEREF _Toc405632606 8 B. Evolution of tools and methodology due to experiments in MT-R  GOTOBUTTON _Toc405632607  PAGEREF _Toc405632607 11 1. MT-R systems developed with Ariane-G5  GOTOBUTTON _Toc405632608  PAGEREF _Toc405632608 11 2. Commented examples of French-English translations  GOTOBUTTON _Toc405632609  PAGEREF _Toc405632609 11 3. Evolution of tools and methodology  GOTOBUTTON _Toc405632610  PAGEREF _Toc405632610 13 II. Evolution towards personal networking communication: LIDIA and UNL  GOTOBUTTON _Toc405632611  PAGEREF _Toc405632611 15 A. The LIDIA project  GOTOBUTTON _Toc405632612  PAGEREF _Toc405632612 15 1. Motivations and principles of the DBMT paradigm for "MT-A"  GOTOBUTTON _Toc405632613  PAGEREF _Toc405632613 15 2. Presentation on an example  GOTOBUTTON _Toc405632614  PAGEREF _Toc405632614 17 3. Perspectives for DBMT  GOTOBUTTON _Toc405632615  PAGEREF _Toc405632615 20 B. Evolution: Ariane-G5/LIDIA  GOTOBUTTON _Toc405632616  PAGEREF _Toc405632616 23 C. Using Ariane-G5/LIDIA within UNL  GOTOBUTTON _Toc405632617  PAGEREF _Toc405632617 24 1. UNL  GOTOBUTTON _Toc405632618  PAGEREF _Toc405632618 24 2. Architecture of deconversion and enconversion  GOTOBUTTON _Toc405632619  PAGEREF _Toc405632619 25 3. Lexical engineering for UNL-FR  GOTOBUTTON _Toc405632620  PAGEREF _Toc405632620 25 III. Evolution towards speech translation: integration within CSTARII  GOTOBUTTON _Toc405632621  PAGEREF _Toc405632621 26 A. Task and general methodology  GOTOBUTTON _Toc405632622  PAGEREF _Toc405632622 26 1. The task  GOTOBUTTON _Toc405632623  PAGEREF _Toc405632623 26 2. The approach taken  GOTOBUTTON _Toc405632624  PAGEREF _Toc405632624 26 B. A first prototype  GOTOBUTTON _Toc405632625  PAGEREF _Toc405632625 27 1. Architecture  GOTOBUTTON _Toc405632626  PAGEREF _Toc405632626 27 2. Work done to adapt the components  GOTOBUTTON _Toc405632627  PAGEREF _Toc405632627 28 3. Integration  GOTOBUTTON _Toc405632628  PAGEREF _Toc405632628 29 C. Further evolutions under way  GOTOBUTTON _Toc405632629  PAGEREF _Toc405632629 31 1. Improving the SR phase  GOTOBUTTON _Toc405632630  PAGEREF _Toc405632630 31 2. Building and passing information between utterances  GOTOBUTTON _Toc405632631  PAGEREF _Toc405632631 32 3. More integration between SR and MT  GOTOBUTTON _Toc405632632  PAGEREF _Toc405632632 32 -o-o-o-o-o-o-o-o-o-o- Ariane-G5 is programmed in a totally multilingual fashion. Only the French and English versions of the messages have been completed at the time of writing. This term is used rather than synthesis", by analogy with that of "generation" in compiler construction. The possibility to produce several geometries or bracketings for a sentence exists and has been used later for the LIDIA project: we will then speak of MMC- or MMA-structures, for multiple, multilevel, concrete/abstract. An example of two concrete and abstract multilevel structures for the same sentence is given in section II.  CLIPS++ consists of GETA and GEOD, two research groups of CLIPS (Grenoble) specializing in Machine Translation, Speech Recognition and Dialogue Processing, LATL (Geneva), also working on MT, and LAIP (Lausanne, speech synthesis). GB for Government and Binding Aspects of GETA's MT methodology applied to high-quality translation Ch. Boitet |! !!!!!!9%:%G%H%I%L%M%&' ( ((((((((*)+)8)9):)>)?)@)A)--113 4 4444%5]5555962:3:@:A:B:F:jU j0JUjUjUj UjUjU jU6CJCJCJ I|% x b o FO ## $%&A)4*V*-0?uF%$|% x b o g  ?uF%$001@3i3334O4x444%5]555596w648::i<T=\>!?@u@"A**F:G:;';<<@<X<)=:=W=k===>>r@s@@@B#B&B8BJJKKpL|L WWYY#Y5YZ [;[<[I[J[K[S[T[[['\(\u\\\\\\\\\\\\\\\\\\\^^ggsqqTsds/vTv^vfvqyy#>*EH>*EH>*>*>* j0JUjF U j"EHU6 jUT"ArAABBCSEIJJKLLPRSVlmopIrtttuxy{{i|A(Bg?~8*$5mƐ`ƕUEm$tѨ*#$%)*ۈ܈HQ*+,01~}~9:GHIMN̻ͻ !%&KLjUCJjUjUjUjUjz Uj U6jo U jUj UDѨ0t{<2ָ Ⱦt?}J| SS$*LYZ[_`{|JKCDQR:;HIJNO]^jEUjUj;UjUj/UjU6j#U jUjUHl JKYG$DEQS$!$$P40n$QRq(,S$!$$P40n$>QYMm iX l  8 ^klmqrwxcdqrswx67DEFMNderst       : Q     6jUjUjUjUjUj`UjUjRU jUjUE8   {{ i h!! %Q')9)Q*Y+++++9$K$/t}}ghuvwz{%%%%%%%,'0'9':'G'H'I'M'N'++++--7383[4\4 5 5::>>>> @ @@@BBCCCCCCCDj@U jU jLeU jU jU jU jU 6OJQJ j(}U jUj UjUjU jU6C+++],---."017393g3[4]44 5 5B5 7888::R$9K $$F4l$$9$K$:;<U=>>>>;>x>>]? @ @ @@@8@|ABBBBBCEHR$ $$F4$$9$DDLHaHHHHIIIIJJGMYMNN_RgRiUUYY\\aaab|d~dddddd)*789<=MN)*+/0jvUjvU j*Uj *U j0JUj)Uj)U j{UjU6 jUFHIKMMMPRUAU!WNZZ\\a\\]T`>b,ebeYf9gLgbgog{ggT90ggggggggg hHh[hhhh8iWiYitiiiiiiiijj#j5jT5jHjRj\jejnjjjjjl)mommnnnEoXooQppq>rrsss$ttTtt,ukuu9vrvvvwxy y{~[?sʃF^t3Tr`Ɖ_ LiђTUJt3J۟AР&eġ,P$NGiyW=tWj>3\ѯqx)cֵEz@wt3tW0۾XTT fxv$=tt3vIJ34:&NP1ybxzp'9u#$D|Or ` Dc65jUj U jU jB@U jU jxU j*wUOJQJQIK356Sj_O FQtK[uv $$F4_%=$$=$=["u^#J?%M  Tpuc*MRI#$9!#SYwJ_a.ACw<P{5EGx XlL^`*?dKdft556cTE)70SG%Fo0N% !p5cSg*Jx$!S_&68-/V45XYgh+,GH_`acz{&'BCZ[\^mH jU65`      !"#$%&'()*+,-./012345MSTUWXYZ[\           !"#$%&'--/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~y [N@NNormal$P( nCJOJQJkH'mH D`D Heading 1$$ & Fd@&5CJD`D Heading 2$$$ & Fd@&5B`B Heading 3$$ & F@& 5B`B Heading 4$$ & F@& n>*F`F Heading 5$$ & F@& n5CJ@`@ Heading 6$ & F@&>*CJ< < Heading 7$ & F@&6CJ@ @ Heading 8$ & F<@&6CJ< < Heading 9 $ & F@&6CJ<A@<Default Paragraph Font6*@6Endnote ReferenceH*8&@8Footnote ReferenceH*88TOC 8X4 n$ 88TOC 7R n#$88TOCD)7' hV2enrf^[Moneimne, 1989 #48] $DN(  S&WordMicrosoft Word&Word   2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. dxpr  " currentpoint ",Times .+%2 ( log ( )()n)), Symbol ()  (-)2(7, )%2 ( Llog ( _()n)) (I)  (;+)2(o-) 1 ([)}]/MTsave save def 40 dict begin currentpoint 3 -1 roll sub neg 3 1 roll sub 4160 div 768 3 -1 roll exch div scale currentpoint translate 64 50 translate /cat { dup length 2 index length add string dup dup 5 -1 roll exch copy length 4 -1 roll putinterval } def /ff { dup FontDirectory exch known not { dup dup length string cvs (|______) exch cat dup FontDirectory exch known {exch} if pop } if findfont } def /fs 0 def /cf 0 def /sf {exch dup /fs exch def dup neg matrix scale makefont setfont} def /f1 {ff dup /cf exch def sf} def /ns {cf sf} def /sh {moveto show} def 160 /Times-Roman f1 (2) 1150 430 sh (2) 2895 430 sh 384 ns (2) 317 462 sh (2) 2062 462 sh (1) 3784 430 sh 384 /Times-Roman f1 (log) 637 328 sh (,) 1700 430 sh (log) 2382 328 sh 224 ns (\() 1255 296 sh (\)) 1477 296 sh (\() 3000 296 sh (\)) 3222 296 sh 224 /Times-Italic f1 (n) 1348 296 sh (n) 3093 296 sh /f3 {ff 3 -1 roll .001 mul 3 -1 roll .001 mul matrix scale makefont dup /cf exch def sf} def 224 1000 1866 /Symbol f3 (\351) 538 417 sh (\371) 1566 417 sh (\351) 2283 417 sh (\371) 3311 417 sh 384 /Symbol f1 (-) 107 462 sh (+) 1852 462 sh (-) 3504 430 sh 384 1000 2093 /Symbol f3 ([) -33 540 sh (]) 3953 540 sh end MTsave restore dMATH  * * 2log (n) -2,* * 2log (n) +2-1[]D)22ZRhV2enrf_')[Vauquois, 1985 #44; Vauquois, 1988 #26] D)2262EhV2enrf_  [Quzel-Ambrunaz, 1990 #49] D)24Q4=hV2enrf_7[Chauch, 1975 #50] D)24&xOzhV2enrf`u[Moneimne, 1989 #48] D)26* ŠhV2enrfa3[Guilbaud, 1988 #59] D)26߯:_hV2enrfa [Gaschler, 1994 #61] D)26V=hV2enrfb4[Chappuy, 1983 #65] D)28>hV2enrfb[Vauquois, 1985 #66] D)28۵>hV2enrfb?[Vauquois, 1988 #26] D)28j9hV2enrfb[Yan, 1987 #67] D)28_YahV2enrfc \8[Zaharin, 1986 #68; Lepage, 1989 #69; Boitet, 1988 #70] D)288+O~2VWVA,,+,.,2V2,V,2WV2W2\V,2+{,2+2,,V,+2{],]{,2\W]WW,+22,2WW1,,2+V,,,1,2]+,V,PV,2+W,VV,,],+,+,V2],W2,]VW2,V2,2W,WV2W]V,,]W2V,W,,1%%++2,2W,+VWV2+],]W+,,W,W]+2+,,{,,+2WV2W,22+{+2,,%%,+{%,2,\2.2VWV/,,+,/,*V2,V,+2WV2W2\V,2+{,2+2,,V,+2{],]{,2\W]WW,+22,2WW1,,2+V,,,1,2]+,V,PV,2+W,VV,,],+,+,V2],W2,]VW2,V2,2W,WV2W](V,%,)]W2V,W),,1)%%3++12,21W,+RVeWV2e+],]fW+,,]UW,WU]+2+U,,{,M,+2UWV2W,U22U+{+2U,,Y%,+{^,2e\2`2VWVV,,+,,V2,V,2WV2W2\V,2+{,2+2,,V,+2{],]{,2\W]WW,+22,2WW1,,2+V,,,1,2]+,V,PV,2+W,VV,,],+,+,V2],W2,]VW2,V2,2W,WV2W]V,,]W2V,W,,1%%++2,2W,+V'WV2+],]'W+,,)'W,W']+2+#,,{,#,+2'WV2W,+22%+{+2#,,*%,+{",2"\22VWV ,,+,,V2,V,2WV2W2\V,2+{,2+2,,V,+2{]=,]{E,2\JW]WJW,+228,2WW1,,2+V,,,1,2]+,V,P$V,2+W,VV,,]",+,+",V2!],"W2,]VW2,V2,2W,%W#V2(W](V,',F]W2V,WY,,1]%%\++J2,2NKSaON  /1A<8#&!T*TT*TT*TT*TT D d S&WordMicrosoft Word&Word   2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. E E E" CHH ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""C     #/1;>@FOC?94'&!#&1<CFPKMIQJA>>&+l-D7 S&WordMicrosoft Word&Word ,  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. ,  " Q HH ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""Q ****U*U*U* U.*U*U:*UW*)UO*'UR*-UO*-UW*-U?* U*U*U*UUUUU =+          "%D=  0"     0" & Yd$^ Y e)b :;  "     ">6  "0     "0), + (((+ , ) H*D7 S&WordMicrosoft Word&Word (  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. (  " Q HH ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""Q ****U*U*U* U.*U*U:*UW*)UO*'UR*-UO*-UW*-U?* U*U*U*UUUUU B0           oy ~  o & PY$U N Z)X]l  f  f  m  RD1  '        ), + (((+ , ) *,D7 S&WordMicrosoft Word&Word *  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. *  " Q 'HH ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""Q ' +****U+*U+*U+*U+'*U*U:*UW*)UO*'UR*-UM*-UW*-U?* U*U*U*UUUUU =+            r0  0 u & PY$U N Z)X  !5:555+ -52/2+(Ytl kt` ,)e/{~  /k  *), + U%((+ , ) RHD}B /% S&WordMicrosoft Word&Word G  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. GU U U" S fHH ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""fS ****U*U*U#*U@***Ub*****Ui*****U***! **Ux***! **U*****U{*** **U*** **Uk***  **U%***U*U*UUUUU ++'''snswwwgp##++#khy ;BHCA W+2 ,2,2 V2, WV 22+2V 2, +,,,$ ],V2,$ 2,W# ,, 2,, +W] ,W+ ,V/ 2,- ]2 W]2 ,,WW1 +2a ,,n + ,PWw ]+n Wm ,,s ,W222w  VWu V+f ]2 V2 W 2W] V,, VW2{ W2+, 2,V+ +PV ,], V +,V, ,2]W 22 ],W %V+ 2V,, ,+, ,, ,2 ,,+W 2,++ 3,2 ,WV, ,,W ,+] , V,+W W]2 22, V22, ,W,W + ,2%, W+2 ,2,2 V2, WV 22+2V 2, +,,, ],V2, 2,W ,, 2,, +W] ,W+ ,V 2, ] W] ,,WW +2 ,, + ,PW ]+ W bGDB /% S&WordMicrosoft Word&Word F  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. FU U U" S e?IHH ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""e?BS ****U*U*U#*U6***UX*****Uh*****U***!**U|***!**U*****U*** **U*** !**Uo***  **U****U*U*UUUUU BBIIE:>C;9,,)441nyuo   QDF27(\ S&WordMicrosoft Word&Word DP  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. PDk k k 2?IHH!ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ff33̙ff33̙̙̙̙ff̙33̙ffffffffffff33ff33333333ff333333ff33ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33ffffffffffff33ffffffff̙ffffff33ffffffffffffff33ffffffffffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffffffffff33ff33333333ff333333333333̙33ff33333333333333ff33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333333333333333ff333333ff33̙ff33ff33ffffffffffff33ff33333333ff333333ff33wwUUDD""wwUUDD""wwUUDD""wwwwwwUUUUUUDDDDDD""""""2?BkUU****UU*UU* UUUU*UU5**UUP***UUh* **UU*! **UUUr*!**UUy***Uq* **U*  **Ue*  **U!**U*U*UUUUUUUUUUUUUUUUU$U%UUUU'  UUU UUUUUU$U+UUUU2U4U)U(UUUUUUUUUUUUUUUUUUUUUOffadg  ]]  f  ^XbbUQUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU!U)UU4U:U5UU3UU(UUUUUUUUUUUUUUU#UU<UUU1U)U(UU!UUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUD)2enhV2enrfd6E[Bachut, 1984 #57; Melby, 1981 #18; Melby, 1982 #19; Tong, 1986 #63] D)2WВ;hV2enrfd[Ducrot, 1988 #9] )DB4% S&WordMicrosoft Word&Word ;(  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. (;~ ~"PqP]#]PPP#] "]###### #  ~  P"q "###### #  ~ ס" נ١٠"""٠נ"#Lq#?)L#?#L'K)J#? "#? #######  ~  d'K".q&.&.+(& "&###### #  ~ "eƠ"k  "})###### ~#)###נ"m  ")##$### ~#)#$#נ"o  ")##$### ~#)#$#נ"r  ")##$### ~#)#$#נ"t  "(##%### ~#(#%#ؠdMDPL 1[ % [ ,  Helvetica .(\ mmc-structuredMDPL ~"q   ")##$### ~#)#$#נdMDPL 1] $ ](^ umc-structuredMDPL ~"uq   "M(##$### ~#(#$#ؠdMDPL 1Z]h $ Z]h(d^ uma-structuredMDPL ~"    " )##$### ~#)#$#נdMDPL 1D $ D+O umc-structuredMDPL / _`{(ieSource Language +$Text ~ 0]\~͠ 2 _{X(iTarget Language 1 +'Text ~0]~Y".fq)d.q)q.f+e)d)q ")q###### #  ~  _+e"qwww "w #######  ~ ""q " #######  ~ ""=q=I#I===#I "I###### #  ~ "*"q## "###### #  ~ "u"-q---- "#######  ~ "[Ҡ"/PqI/PL/P/L/IL "L#######  ~ "]LҠ"q  "(##$### ~#(#$#ؠdMDPL 1] $ ](^ umc-structuredMDPL 2 ^mz+Target Language 2 +'Text ~ 0\l~"/q//// "#######  ~ "\Ӡ"q "###### #  ~ "u">q>JJ>>>J "J###### #  ~ ","RqR__RRR_ "_###### #  ~  R"mqamammma "a #######  ~ ""uquuuu "###### #  ~ "c  ( interactive (disambiguation ~ @"-  "*)##%### ~#)#%#נdMDPL 1N $ N( gma-structuredMDPL ~"t   "K))##$### ~#)#$#נdMDPL 1XfM $ XfM(b uma-structuredMDPL ~"   "*(##$### ~#(#$#ؠdMDPL 1N $ N+P umc-structuredMDPL ~"' q'.+'+.+ "+###### #  ~ "v+"<'q<'K-K*<'<*<-K* "K*#######  ~ ".*"Q'qQ'_._+Q'Q+Q._+ "_+#######  ~  +Q+dMDPL 1)bE  )bE(3mreverse (Ae translationdMDPL ~ @)_G  _{V(iReverse (w translation 1 ~0]~Y   E`(FUser ~P=e A CC HdMDPL 1#?@ + #?@+Qambiguity marks +  and dialogue dMDPL ~" q### "####### #  ~ ס"&נ١٠"""""" ""٠נ"3  "E)###### ~#)###נ"5  "H)##$### ~#)#$#נ"7  "K)##$### ~#)#$#נ":  "M)##$### ~#)#$#נ"<  "P(##%### ~#(#%#ؠdMDPL 1# q % # q( $ mmc-structuredMDPL ~ @HdMDPL 1B , B(simulated "mute" +disambiguation dMDPL ~"0 q)#5#)0/5#) "#)#######  ~ ס"<נ١٠"<"7"3"/٠נ A H  (s.m.d. ~ A$z9 H  (|6(2}a.m.&d. ~ A.mP HdMDPL 11oM̡ + 1oM(;rambiguity marks +  and dialogue dMDPL ~"" q"//"(*/ "/###### #  ~ ס" נ١٠""!"$"'٠נ"!q11!&1 "1 #######  ~ ס"7נ١٠""""""" """"!"%٠נ"q " #### ###  ~ ס"נ١٠"""٠נ"  ")###### ~#)###נ"  ")##$### ~#)#$#נ"  ")##$### ~#)#$#נ"  ")##$### ~#)#$#נ"  "(##%### ~#(#%#ؠdMDPL 1~ ̡ & ~ (  mmc-structuredMDPL ~"s    "J)##$### ~#)#$#נdMDPL 1XfB $ XfB(b uma-structuredMDPL ~"sq   "J)##$### ~#)#$#נdMDPL 1X^f $ X^f)g uma-structuredMDPL ~"*    ")##%### ~#)#%#נdMDPL 1B $ B( gma-structuredMDPL ~"*q   ")##%### ~#)#%#נdMDPL 1^ $ ^)g gma-structuredMDPL ~A. B H 3 0 >(:!paraphrase choice.D)2@<5ţ>=<=>@CPPOt& Db6G] tH``H`p^^p;;p22p__t"o`o______t*}}i}t"66R}6pC^C^pRkRkpbybypqqppppppppp    pp)**)p6996pCIICpPXXPp^gg^pt.evellvd&Wpvo~_o~rsvz}*7AGKQW\^_^\YUPKE>6."tt"t"(((t((p______pp&&taCa6aCat`H`H``t;[>;;>[1J;t&jTa<`M,jp^^pvvpvvpvvpv//vpvvpwwpvvpv;vv;vtb}4l dtxz| }ljd?x de}Xd#ZdjYt:@>:;>@7@: t":*Z?@7:?8Z1R*@7 tCZ1CJZ1R*Ct;J;@CJ;t@R7@@7R*C@tKH,KK,H<KtZ>ZZ>3Zt~"6~"~66"~"t&RZRx$~<[ZRt`=`w=<`______t*T<<<]jqTa<pfNmmN>poR}m}RompAmoomApqppqpCqqCppQGQGppM0M0p||pL||Lp7UgL7UgLpDCuCDCuCpO.4O.4??????p;b;bp[bb[d PPNTdPPNTd PPNT  Pq<L<Lp8H8H______q3K3Kp/G/G??????q&K5K<&5p"G1G8"1??????qNtYtNtYpJpUpJpUqK| Z| |KZ|pGx Vx xGVx______qK |Y| |KY|pG xUx xGUx??????q2YAY|J2pAp.U=UxF.l=______q@|Y|@|Y|p<xUx<xUxqJ|Y|J|Y|pFxUxFxUxQ^Q^Qi____ajnajGmQiQjQv____awnawHl??????qpq______q&kUU_*kp&gQQ[& g q7 _+7 _+p3 ['3 ['______q=f=Zfp9 b 9V b qkCkp g ?g  ??????qllp h  h ??????q&_ p7 _+.!p&[l3['*p"))")"QVhQvQ_rQQic|QRpqf'ff''fpb#bb##bq''''p####______qff'fpbb# b??????qvXvX:vvprTrT6rrq_ \_ , \_ p[X[(X[qF\Z\ZFZpBXVXVBVqr^rrpnZnn______qrrpnn??????qq.q..q.qwps____QuQ}wQea2 aGe\q& X  ;XX; Q/E____QcyQdpQ#Saa1T a51ST\q&1GS1S)FGSG1)?1Q73MQBPQT`QcqQsQQQQQ9GQL\Q^mQrQQQQ______qmmpii??????qXXXp}TT}Tq&wp&sqzPPz\PpvLLvXL______q"NN{NNp"JJwJJp__q\q^$d_bc)d6cDbR_b[qWRNG@83-)&$F_qZ3ZqZ)5CRbq ??pppp__pe#e#ep>%>%>dpxSx______qp??????q,,,p(((q&/p&+q$$0$p  , ______q"""-""p")p)))__q#J#Jq^o &6EUfs~xtqoq//R/qZ(d_acd cb&_6\EWURfMsG?72,()J_??pDD^DD^DD__pR9nR9nR9pQqmQqmQpBBQ8`XQcX??qZs//03?MYgr{{x}uwsnub{RB4/pZo+~+,/;IUcnw{~~w|tyqsojq^wN~>0+??qZpxurprxpZl{tqnlnt{qbQmT&Q0Z[` mi+}ec0|G *Y T&pbMiP"M,VW\ie'y{a}_,xC&UP"  w8  Pp22q33px>x>x>qx?x?x? <a i  PpoNo;N oqpOp;O!pp++Yq++Y,Times p.@@@@(pftp Phon lattice" ?? (http French Phon to French text  Poo}9 8H`o  @@" (ba3 d@D"0& W p `0 ,@B"@ 0T`BD@i&X@ D@C`@ 0x@`B@0`hp 0g00` h !`"0p ?? (0phttp French Phon to German text  PD=D= @`p Pf, ` 1Y' $8@ @À#2<@D(A?tBBb, `0XLFit8H`D@ C`` !qB"8@ 0`"1j8(p @@ BW1@(H0Z(!@d PPNTdPPNTd PPNT E4i48t112p112p))t;`;;``;t;`;;``;t;`";;"`"`;t;'`+;';+`+`';'t;/`3;/;3`3`/;/t;8`<;8;<`<`8;8t;@`D;@;D`D`@;@t;I`M;I;M`M`I;It;Q`V;Q;V`V`Q;Qt;Y`^;Y;^`^`Y;Yt;b`f;b;f`f`b;bt;j`o;j;o`o`j;jt;s`w;s;w`w`s;st;{`;{;``{;{t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t; `; ;`` ; t;`;;``;t;`!;;!`!`;t;$`);$;)`)`$;$t;-`1;-;1`1`-;-t;5`:;5;:`:`5;5t;>`B;>;B`B`>;>t;G`K;G;K`K`G;Gt;O`S;O;S`S`O;Ot;W`\;W;\`\`W;Wt;``d;`;d`d``;`t;h`l;h;l`l`h;ht;q`u;q;u`u`q;qt;y`};y;}`}`y;yt;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t;`;;``;t; ` ; ; ` ` ; t;`;;``;t;`;;``;t;#`';#;'`'`#;#4"}84z"#84!"84"%848484848484844848tttt"%"%%""t),),,))t/2/22//t6969966t<?<??<<tBEBEEBBtIKIKKIItORORROOtVXVXXVVt\_\__\\tbebeebbtililliitororroop"##4H8tXGGYXGpXGGYXGpdadadtbqbbqqbpbqbbqqbtbp^bb^pZpbpbp^bb^pZpbtbqbbqqbpbqbbqqbtbqkbbkqkqbpbqkbbkqkqbtbrbbrrbpbrbbrrbtkxnkkdxnxkpkxnkkdxnxkp~~,~~,p??ppppppp|=|m|=|mpIpIpp.p.ppp$l$lppppccpHHpLLpZZpXqXqp`x`xttPPttgPptPPttgP4P8t\zy\\zzz}ywsoic]UNC:1' ~|yp\zy\\zzz}ywsoic]UNC:1' ~|y W[D jH DFD/VCH <>D>k4H4SY8d PPNTdPPNTd PPNT    Ppxxxqxxx @@@@(ARIANE G5 lingware* French Phon to French Text* French Phon to German Text(PECHO* speech recognition*ITS2*" French Phon to English Text*DECTALK* English synthesis(MCL*$ Phon lattice to HTTP requests* Requests management* User interface*LAIPTTS, MBROLA, MACSOUND* French synthesisD)2@5NhV2enrfey&-%[Keller, 1996 #77; Keller, 1997 #78] D)2@L|v{uKY>Q{v{sBC PV _y     ;Mv{rOT--]--]-] -]-- -]---]---]--]--]--]- OD;2! S&WordMicrosoft Word&Word 2N  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. N2r HHr rhd HH%uff33̙ff33 ff 33ffffffffffff33ff33333333ff3333 ff :^V^ ff33ff33̙ 3333ff ̙̙̙̙ff̙33̙ffffffffffff33ff33 ffff hO 333333ff33ff33 K`A ̙ff33ff33ffffff 1'n 33333333ff333333(ff33ff 33 ff33ffffffff̙ffffff33ffffffffffffff33 7 ffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffff [" 33333333ff333333333333̙33ff33333333 ' 33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333 33ffff 3333ff333333ff33  33ff ( ff33ffffffffffff33ff """""" 33  333333ff33 DDDDDD ff33 aG[ wwUUDD"" ̙ff hhhwwUUDD""wwwwwwUUUUUU ff ̙ hdr r ]]]]U]U]U]U6]UC] UI] U[] UL] U[] %UX] %Ub] %UG] U]U]U]UUUUU #?@ RT<;:;  )  7648                 %%(&&(%" #+0262--/1-+)!  @:P@<==K@@S A[\OTXaS\ .*((MT m } s w{  j-1,*.--]--]-]-]---]---]---]--]--]--]- ]D;2!/. S&WordMicrosoft Word&Word |\  2 @@$Utilisez Word 6.0c (ou ultrieur) 2 @$pour afficher une image Macintosh. \|q HHq qhd HH%t؀ff33̙ff33 ff 33ffffffffffff33ff33333333ff3333 ff :^V^ ff33ff33̙ 3333ff ̙̙̙̙ff̙33̙ffffffffffff33ff33 ffff hO 333333ff33ff33 K`A ̙ff33ff33ffffff 1'n 33333333ff333333(ff33ff 33 ff33ffffffff̙ffffff33ffffffffffffff33 7 ffffffffffffffff33ffffff33ff33ff33ff33ffff3333ff33ffffff [" 33333333ff333333333333̙33ff33333333 ' 33333333ff33ff33ff33ffff33ff3333ff3333333333333333ff333333 33ffff 3333ff333333ff33  33ff ( ff33ffffffffffff33ff """""" 33  333333ff33 DDDDDD ff33 aG[ wwUUDD"" ̙ff hhhwwUUDD""wwwwwwUUUUUU ff ̙ hdq q]]]]U]U]U]U6]UC] UI] U[] UL] U[] %UX] %Ub] %UG] U]U]U]UUUUU #?@ RT<;:;  )  7648                 %%(&&(%" #+0262--/1-+)!  @:P@<==K@@ S A[\OTXaS\ AIO;          .*((MT m } s w{  j-1,*.--]--]-]-]---]---]---]--]--]--]- D)2B5^*F`F Heading 5$$ & F@& n5CJ@`@ Heading 6$ & F@&>*CJ< < Heading 7$ & F@&6CJ@ @ Heading 8$ & F<@&6CJ< < Heading 9 $ & F@&6CJ<A@<Default Paragraph Font6*@6Endnote ReferenceH*8&@8Footnote ReferenceH*88TOC 8X4 n$ 88TOC 7R n#$88TOC 6R n#$88TOC 5R n#$2a2TOC 4(p !CJ>@>TOC 3"$$ n$8@8TOC 2 n$ 8@8TOC 1 ( n$ &&Index 7&&Index 6&&Index 5l& &Index 4QB BIndexy [N@NNormal$P( nCJOJQJkH'mH D`D Heading 1$$ & Fd@&5CJD`D Heading 2$$$ & Fd@&5B`B Heading 3$$ & F@& 5B`B Heading 4$$ & F@& n>*F`F Heading 5$$ & F@& n5CJ@`@ Heading 6$ & F@&>*CJ 6R n#$88TOC 5R n#$2a2TOC 4(p !CJ>@>TOC 3"$$ n$8@8TOC 2 n$ 8@8TOC 1 ( n$ &&Index 7&&Index 6&&Index 5l& &Index 4QB BIndex 3P nCJN NIndex 2.$$dP  H!d#V VIndex 12$$d n H!d#CJ8 @8Footer $ 8!CJD@DHeader!$ n$6CJB@"B Footnote Text"( 0CJ88TOC 9#R& n#$>OB>Titre0$$$ n5CJ$(OAR(Auteur%5CJ\b\ Rfrences2&D n`, \ '(CJRrR Texte indent'$ D$d&d6CJXXProblmes ou maximes(H n6CJ(!(Rsum )PNONliste2*$$,( nH H TTRelief*+l  8<$ @ l+$ OJQJkH'JOJ sous-liste$,$S n H @@Italiques encadrs-$6..Cellule . ntOt Arbre indentG/$$ $n 0\`x   xF@F@$d&d(O(Figure0$8>!>Dfinition - corps1dN"NNormal encadr 2 0d$d&d>2>biblio3$$  OJQJkH'nn DfinitionC4$xd( )n 0 H xH!6NRNDfinition - liste5$4d(^b^ Sous-liste76$\ #n \ H!d#XrX Signatures27 )n \ H!d#R/AR Intertitres8$ & F<@& x 6>*CJ6O6caption 9$(P6CJXX Liste dcale,:`d n H HH Normal dcal;$Hdh 0JJGraphique-cadre<$$dhCJBOB Graphique=$2d nCJ\\Liste-justifie+>$0d( nx4O4Abstract?OCJBBSchma$@$d( n\^^Sous-liste-justifie$A$xd n j"jAdresse (lettre)(B$d n\d#CJOJQJkH'X2X Titre tableau$C$d n`5CJPBPAlgo&D$;,d nCJOJQJkH'NORNAdresse (article)E$d n*OQb*VersionF6@r@CommentG$d 06CJRRTitre-H$dx n`5CJLLAdresses)Ipd n ll Programme7J7d 0  . CJOJQJkH'OEcraneK$$dxPJ Dn\Ld \ H!d#8OJQJkH'TTAuteurs0L$7dx n06XX Affiliation/M$7dx 0NNResum0Nm7d n0`FFCellule dcaleO$ RRCellule centre!P$$( 4JJ A...de...&Q\dxx n4! `O` Ecran+large8R$Hd  \LdH!d#0`FO2FExemples Italiques S$$(6HOBHFichierT$ nCJOJQJkH'jARjRead-MeJUd /,0H`x  \ txNbNMessagesV$P nCJOJQJkH'@ar@Messages CourierW OJQJkH'XXListe numrote'X\\d n H RRAuteurs rapport"Y$  08FFJury,ZdP n 0FqFtoc 2' [$$0(P d#5CJFFAriane\$ nCJOJQJkH'``Liste dcale +/]$$\ <(  H x6A6 Fichier+large ^22Texte_d nHH Texte/num!`V0L< nttCellule-prog.liste:a$$$dP  0n  . CJV"VAriane10$b$ n$d&dCJOJQJkH'(!2(Ariane12cCJ&1B&Centrerd$@BR@ Body Texted<< n:b: TraductionsfCJOJQJkH'(!r(Ariane09gCJ`` Programme LT6h$$$d  0n  . HHBNF_commentaire id( OJQJkH'rr BNF_rgleAj0d *n `  x8 OJQJkH'~~Formule Beam Match;k$$$ n|4 ($d&d OJQJkH'JJPatronl$ nCJOJQJkH'Mthode_DialogueXm$dxx BnH`d   \ tx 8@CJOJQJkH'jjProgramme HB&GS6n$$$d  0n  . CJPPGraphique+large o$d$d&d`O` Bibliography2p$H( n, \ '(CJbb CD-File_lidia%qld< n8CJOJQJkH'T"T Texte encadr(r$$ DP$d&dP2P Auteurs 3+s$$d n h</@B<List!t0 n H 2oR2Titre1u & F<@& F2@AbFList 2(v$8P  H 8`6'@q6Comment ReferenceCJ0@0 Comment TextxCJ)-PQƒ"U>`c#      !"#|UUUUUUUUUUUUUUUUUUUU`````````cl  !"ml'"md49m49m69mU9mV9EpZ4Z#                              ! " #K$z2CP{c?ugۗE2@':-6I)R]m}{͉hF5K %F Do Y  u  3 ! "|&ycp +Z !U%H&j&4),,.-T/|///&0^0000.1f1112=2z266l8W9c:(; <{<&=v==>>?WAC1DKD8E[EKFEHIIJ-KKFL}LLwMyNN|OT#WY"\]/abde:gciijvmonppXqzt/vx0xTxx,yky%zz {o{"|Z}t}~j΃gD7j~"JQX۪[&X/mnH'(6qmn%`!"x/0yNqsb,]0%EBEej|xTtv    BA**2e6    "#%''@'4(6(k((()*,2,9,:-<-]-../////0Q0061111112U33y4z4447;=u???bBCFGH$LwLM7NXNO)RkVV.WX!X7XDXPXaXkX~XXXXXXXXY0YeYxYY Z,Z.ZIZkZZZZZZZZZZ [['[1[:[C[V[[[[]]D^^^V__`-``&aabcaccgdddreef@ffgGggghiiihlnrpmq1rrsHsstttu3umuevvGwnww5xhxxyz||4}[}]~~!>ԁ݁)*͉T:%Wʗٗ#Z>N,?qÞ1TFywNͥ9PqM-֯.*c*<Ƿn{}!   )@%'J!1YK4r|y `#V^* ]w)]xE$pn y1=$$ $$$$!$$$PS$$ $PS$PS$$$PS$PS $PS$PS$PS$PS$PS$PS $PS$PS$!$PS$PS$PS$!$!$PS$PS$PS$!$PS$!$PS$!$PS$!$PS$PS$!$PS$PS$PS$PS$PS$Ď$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS $PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$!$PS $PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PSPSPSm$PS$PSPSPSm$PSPSPSm$PSPSPS`$PSPSPSm$PSPSPS $PSPSPS`$PSPSPSPSPS $PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$2$PS$PS$(+ $PS$PS$PS$PS$PS$PS& -&&! _  ! PS PS PSh+$PS$PS$PS$PS$f%$!$PS$f%$!$PS$)$!$PS$PS$PS$!$PSr;r!HPSHPSHPS^&$!r;r!HPSHPSHPSHPSHPSX $$!rr!HPSHPSHPSX $$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$!$PS $PS$!$PS$!$PS$PS$PS$PS$PS$PS$PS$$$$$$$$$$$$$$$$$PS$$$$$$$$$$$$$$$$$$$$$$$$$$$$PS$$$$$$$$$$$$$$$$$$$$$$$$$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$.,$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$l$$PS$PS$PS$*$PSp%PSPS'81$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$$ $PS$$$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$$!$!$!$!$!$!$!$$|&ycp +Zc  !#U%H&j&4),,.-T/|///&0^0000.1f1112=2z27466l8W9c:(; <{<&=v==>>?WAC1DKD8E[EKFEHIIJ-KKFL}LLwMyNN|OOT#WY"\]/abde:gciijvmonppXqzt/vx0xTxx,yky%zz {o{"||Z}t}}~j΃gD7jj~"JQȠRX۪R[&X/mnH'(6qmn%`!"x/0yNqs_b#,]0%EB1Eej|xTtS v    BA**2e6    "#%''@'4(6(k((()*,2,9,:-<-]-../////0Q0061111112U33y4z444579;=u???bBCFGH$LwLMM7NXNO)RTkVV.WX!X7XDXPXaXkX~XXXXXXXXY0YeYxYY Z,Z.ZIZkZZZZZZZZZZ [['[1[:[C[V[[[[]]D^^^V__`-``&aabcaccgdddreef@ffgGggghiiihlnrpmq1rrsHsstttu3umuevvGwnww5xhxxyz}{||4}[}]~~!>ԁ݁)*͉|T:%Wʗٗ#Z>N,?qÞ1TFywNͥ9PqMk-֯.*c*<NǷn{}!   )@5%'J!1YK4r|y `#V^* ]w)]xE$pnk $.:5c*-7oTFey1<=8h$%Fu??uu  (  8  H&H&8  H ,,,,*,*,*,*,,*,*,*,*,,*,*,*,*,,,H ,,666*6*6*6*6,6,6,66666*6*66H ,,8E*8E*8E*8E*8E*8E8E8E*8E*8E*8E8E8  yNH yNyN|O|O|O|O|O|O|O|O|O|O|OH yNyNciciciciH yNyNpppp( x*x*x*x*x*x*x*x*x*xx( 8 Z}Z}t}t}t}t}*t}*t}*t}*t}t}t}t}8 Z}Z}7777777778 Z}Z}QQ8 Z}Z}8 Z}Z}** ۪۪( ۪ 3P nCJN NIndex 2.$$dP  H!d#V VIndex 12$$d n H!d#CJ8 @8Footer $ 8!CJD@DHeader!$ n$6CJB@"B Footnote Text"( 0CJ88TOC 9#R& n#$>OB>Titre0$$$ n5CJ$(OAR(Auteur%5CJ\b\ Rfrences2&D n`, \ '(CJRrR Texte indent'$ D$d&d6CJXXProblmes ou maximes(H n6CJ(!(Rsum )PNONliste2*$$,( nH H TTRelief*+l  8<$ @ l+$ OJQJkH'JOJ sous-liste$,$S n H @@Italiques encadrs-$6..Cellule . ntOt Arbre indentG/$$ $n 0\`x   xF@F@$d&d(O(Figure0$8>!>Dfinition - corps1dN"NNormal encadr 2 0d$d&d>2>biblio3$$  OJQJkH'nn DfinitionC4$xd( )n 0 H xH!6NRNDfinition - liste5$4d(^b^ Sous-liste76$\ #n \ H!d#XrX Signatures27 )n \ H!d#R/AR Intertitres8$ & F<@& x 6>*CJ6O6caption 9$(P6CJXX Liste dcale,:`d n H HH Normal dcal;$Hdh 0JJGraphique-cadre<$$dhCJBOB Graphique=$2d nCJ\\Liste-justifie+>$0d( nx4O4Abstract?OCJBBSchma$@$d( n\^^Sous-liste-justifie$A$xd n j"jAdresse (lettre)(B$d n\d#CJOJQJkH'X2X Titre tableau$C$d n`5CJPBPAlgo&D$;,d nCJOJQJkH'NORNAdresse (article)E$d n*OQb*VersionF6@r@CommentG$d 06CJRRTitre-H$dx n`5CJLLAdresses)Ipd n ll Programme7J7d 0  . CJOJQJkH'OEcraneK$$dxPJ Dn\Ld \ H!d#8OJQJkH'TTAuteurs0L$7dx n06XX Affiliation/M$7dx 0NNResum0Nm7d n0`FFCellule dcaleO$ RRCellule centre!P$$( 4JJ A...de...&Q\dxx n4! `O` Ecran+large8R$Hd  \LdH!d#0`FO2FExemples Italiques S$$(6HOBHFichierT$ nCJOJQJkH'jARjRead-MeJUd /,0H`x  \ txNbNMessagesV$P nCJOJQJkH'@ar@Messages CourierW OJQJkH'XXListe numrote'X\\d n H RRAuteurs rapport"Y$  08FFJury,ZdP n 0FqFtoc 2' [$$0(P d#5CJFFAriane\$ nCJOJQJkH'``Liste dcale +/]$$\ <(  H x6A6 Fichier+large ^22Texte_d nHH Texte/num!`V0L< nttCellule-prog.liste:a$$$dP  0n  . CJV"VAriane10$b$ n$d&dCJOJQJkH'(!2(Ariane12cCJ&1B&Centrerd$@BR@ Body Texted<< n:b: TraductionsfCJOJQJkH'(!r(Ariane09gCJ`` Programme LT6h$$$d  0n  . HHBNF_commentaire id( OJQJkH'rr BNF_rgleAj0d *n `  x8 OJQJkH'~~Formule Beam Match;k$$$ n|4 ($d&d OJQJkH'JJPatronl$ nCJOJQJkH'Mthode_DialogueXm$dxx BnH`d   \ tx 8@CJOJQJkH'jjProgramme HB&GS6n$$$d  0n  . CJPPGraphique+large o$d$d&d`O` Bibliography2p$H( n, \ '(CJbb CD-File_lidia%qld< n8CJOJQJkH'T"T Texte encadr(r$$ DP$d&dP2P Auteurs 3+s$$d n h</@B<List!t0 n H 2oR2Titre1u & F<@& F2@AbFList 2(v$8P  H 8`6'@q6Comment ReferenceCJ0@0 Comment TextxCJ)-PQƒ"U>`c#      !"#|UUUUUUUUUUUUUUUUUUUU`````````cl  !"ml'"md49m49m69mU9mV9EpZ4Z#                              ! " #K$z2CP{c?ugۗE2@':-6I)R]      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~m}{͉hF5G !F Do Y  u  3 ! "|&ycp +Z !U%H&j&4),,.-T/|///&0^0000.1f1112=2z266l8W9c:(; <{<&=v==>>?WAC1DKD8E[EKFEH      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~۪8 8 8 ( ۪۪&S&S&&&&S&S&&&S&S&&&S&S&&&S&IIJ-KKFL}LLwMyNN|OT#WY"\]/abde:gciijvmonppXqzt/vx0xTxx,yky%zz {o{"|Z}t}~j΃gD7j~"JQX۪[&X/mnH'(6qmn%`!"x/0yNqsb,]0%EBEej|xTtv    BA**2e6    "#%''@'4(6(k((()*,2,9,:-<-]-../////0Q0061111112U33y4z4447;=u???bBCFGH$LwLM7NXNO)RkVV.WX!X7XDXPXaXkX~XXXXXXXXY0YeYxYY Z,Z.ZIZkZZZZZZZZZZ [['[1[:[C[V[[[[]]D^^^V__`-``&aabcaccgdddreef@ffgGggghiiihlnrpmq1rrsHsstttu3umuevvGwnww5xhxxyz||4}[}]~~!>ԁ݁)*͉T:%Wʗٗ#Z>N,?qÞ1TFywNͥ9PqM-ׯ/+d+=ȷo|~ "   *A%'J!1UG0nxu\RZ&~ Ys%YtA ~lju-9$$ $$$$!$$$PS$$ $PS$PS$$$PS$PS $PS$PS$PS$PS$PS$PS $PS$PS$!$PS$PS$PS$!$!$PS$PS$PS$S&&&S&S&&&S&S&&&S&S&&S&S&&&( ۪۪8 NNqH qqX ssX ssX ssbbX ssH qqX X X 8 NN]]]  ( 8 8 EtEtEtEtEtEtEtEtEtEE8    /   /   ( 8  2K292K29222222222K2922K2922K292228 H ,,2,R2,92,2,2,2,2,H ,,R/9///////H ,,R1911111( 8 z4z44444448 z4z4H u?u????H u?u?FFH u?u?$L0$L9$L8 z4z47N7N7N7N kVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVkV ( iiiiiiii( iirtrtrtrrtrtrtrr( iievtevtev!$PS$!$PS$!$PS$!$PS$PS$!$PS$PS$PS$PS$PS$Ď$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS $PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$!$PS $PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PSPSPSm$PS$PSPSPSm$PSPSPSm$PSPSPS`$PSPSPSm$PSPSPS $PSPSPS`$PSPSPSPSPS $PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$2$PS$PS$(+ $PS$PS$PS$PS$PS$PS& -&&! _  ! PS PS PSh+$PS$PS$PS$PS$f%$!$PS$f%$!$PS$)$!$PS$PS$PS$!$PSr;r!HPSHPSHPS^&$!r;r!HPSHPSHPSHPSHPSX $$!rr!HPSHPSHPSX $$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$!$PS $PS$!$PS$!$PS$PS$PS$PS$PS$PS$PS$$$$$$$$$$$$$$$$$PS$$$$$$$$$$$$$$$$$$$$$$$$$$$$PS$$$$$$$$$$$$$$$$$$$$$$$$$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$.,$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$l$$PS$PS$PS$*$PSp%PSPS'81$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$$ $PS$$$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$$!$!$!$!$!$!$!$$|&ycp +Zc  !#U%H&j&4),,.-T/|///&0^0000.1f1112=2z27466l8W9c:(; <{<&=v==>>?WAC1DKD8E[EKFEHIIJ-KKFL}LLwMyNN|OOT#WY"\]/abde:gciijvmonppXqzt/vx0xTxx,yky%zz {o{"||Z}t}}~j΃gD7jj~"JQȠRX۪R[&X/mnH'(6qmn%`!"x/0yNqs_b#,]0%EB1Eej|xTtS v    BA**2e6    "#%''@'4(6(k((()*,2,9,:-<-]-../////0Q0061111112U33y4z444579;=u???bBCFGH$LwLMM7NXNO)RTkVV.WX!X7XDXPXaXkX~XXXXXXXXY0YeYxYY Z,Z.ZIZkZZZZZZZZZZ [['[1[:[C[V[[[[]]D^^^V__`-``&aabcaccgdddreef@ffgGggghiiihlnrpmq1rrsHsstttu3umuevvGwnww5xhxxyz}{||4}[}]~~!>ԁ݁)*͉|T:%Wʗٗ#Z>N,?qÞ1TFywNͥ9PqMk-ׯ/+d+=Oȷo|~ "   *A5%'J!1UG0nxu\RZ&~ Ys%YtA ~ljg *61~_&~)3kPBau-894d$%Fu??uu  (  8  H&H&8  H ,,,,*,*,*,*,,*,*,*,*,,*,*,*,*,,,H ,,666*6*6*6*6,6,6,66666*6*66H ,,8E*8E*8E*8E*8E*8E8E8E*8E*8E*8E8E8  yNH yNyN|O|O|O|O|O|O|O|O|O|O|OH yNyNciciciciH yNyNpppp( x*x*x*x*x*x*x*x*x*xx( 8 Z}Z}t}t}t}t}*t}*t}*t}*t}t}t}t}8 Z}Z}7777777778 Z}Z}QQ8 Z}Z}8 Z}Z}** ۪۪( ۪۪8 8 8 ( ۪۪&S&S&&&&S&S&&&S&S&&&S&S&&&S&S&&&S&S&&&S&S&&&S&S&&S&S&&&( ۪۪8 NNqH qqX ssX ssX ssbbX ssH qqX X X 8 NN]]]  ( 8 8 EtEtEtEtEtEtEtEtEtEE8    /   /   ( 8 2K292K29222222222K2922K2922K292228 H ,,2,R2,92,2,2,2,2,H ,,R/9///////H ,,R1911111( 8 z4z44444448 z4z4H u?u????H u?u?FFH u?u?$L0$L9$L8 z4z47N7N7N7N kVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVkV ( iiiiiiii( iirtrtrtrrtrtrtrr( iievtevtevtevevtevtevtevtevtevtevtevtevtevev  ~~!( !!ԁԁԁԁ( !! ~~ttttt( =8 8 8 ʗʗtʗtʗʗ( 8 t>t>8 t,t,t,t,t,8 t1t1t1t118 wwwtwtwtwtwtwtwwwwww8 MMM( 8 vvvvvvvttt8 tvv=vv=== ~~(   ***(   vvvv(   'u''''u''u'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p' 'u'''''''''''''''''''''''''''''''' '""""""! xxxxxRRUUX[F:#L^Dc5 ev "%')*,30"A0bѨQ8 +:Hg5jtJW[T!/>]v     !#$&(+/+0K!Z!^!$,$1$>%M%R%56D6I6-Pt>8 t,t,t,t,t,8 t1t1t1t118 wwwtwtwtwtwtwtwwwwww8 MMM( 8 vvvvvvvttt8 tvv=vv=== ~~(   )))(   vvvv(   'u''''u''u'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p' 'u'''''''''''''''''''''''''''''''' '""""""! xxxxxRRUUX[F:#L^Dc5 et "%')*,30"A0bѨQ8 +:Hg5jtJW[T!/>]t     !#$&(+/+0K!Z!^!$,$1$>%M%R%56D6I6-P@ACBDEFGHIJKMLNOPQRSTUWVXYZ[\]^_j`abcdegfhiklmnpoqrstuvwxyz{|}~*+     -, !"#$%&'().0/2143oo           /x/x/x/x/x/x/x/x/x/xs}s}s}s}s}s}s}s}}}iiǠǠQQWWWWWWWWWWppppppppp /////////U d1,44444444?7N7NVVVVVVVVVVViiiiiiiiiiiiiiiiisssssssssvvvvvvvvv~~           ========܁܁܁܁܁܁܁܁͉͉=======   ))))@@@@$$$$$$IIIIII00)) d494969U9V9"'" '&'  %,9BM\hjsu} (2=CFGOUXYbeqs *6@COQ\cijs|+7CFRT]_jls} "$/1?LWZfhqs~  +-:<CQ]lz|"$,489ADO[fiuw *6@COQ\fq!X+X,X6X7X>XDXMXPX[X\X`XXXdZiZZZZZZZZZZZZZ[ [  +./347JRpt  #49IRY_eo /8KS4:?BxrxGKhl "&FRV^`h} W[z!'-826agmu")ko W[x| 17<Dnr ?CW^jmnv"'138<Ekz #.3_gmw7=$3>NWgpu,59@U\ae '3MQil #$78HJO`d*/&6:;BDQRWXbovx^dmu,KSaey%.FNo{ `dU_`cr} +%)qz15NR 2=?LP[ns &ls  $'(/S\]_ls{-347AEFKZacefjkopu 7?HKRUV^z  *+./69NYZaeq,3OVZcWWXi4h/ `|A]$`| 'i1qMi2N|$@~C_"OVdBoitetHSyrinx:USERS.Syrinx:CB/Syrinx:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet7Linos3400:Temporary Items:Fichier temporaire Word A 878BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet7Linos3400:Temporary Items:Fichier temporaire Word A 310Boitet7Linos3400:Temporary Items:Fichier temporaire Word A 310BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet8Linos3400:Temporary Items:Fichier temporaire Word A 1974BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiamliSihir:Users:Mathieu Documents:ML articles:ML OOPCON-97:Editing/Reviewing OOPCON:OOPCON-CB.doc (rev ml v1) @<.@<.@n<.@<.@<.n<@\<()@ <()@<()EN_Doc_Font_List_Name[HEN_Lib_Name_List_Name[`EN_Main_Body_Style_Name[ӐTimes18Pacling.CBinv.NLibStyleCB@`[xmH q|  9 P '(JN OTtu"!!y""""" #'-',,--...w/{/////00%00000000$1'1-1111111252<2o2y2339: <<1<H<P<s<w<z<=!="=%===?@@@WACCC#C;CUCCCC0DFHHIJLLOO UU8WVWde[gnghhooppssPxSxr$5arՍ uvېbkґݑ ϔ?Qœ˟QWȰy ,6&V^_jHRV@D#,GV7;<@JR     +-01?2H244@4H4XEeEsP|PR'RUVannn|n~nrr݄LSUY ׶׷:E׹׺3=owyQ^23-.  y{Z\!#y{$&.0 fhKM=?\^893459KMNOcdei{}~0@1\1 @1\1 @1\1 @1P\1@1R\0@1h\0B@1x\0@1`1!@1`1!@1`1R`1z"@1`0($@1`0t&@1`01@1b1<@1b0<@1b1B@1b1B@1b0 F@1,b0K@1L@14b1M@1:b1M@0M@1d0B@1Rd0@1h0$@1h1@14h0D@1Nh0@1`h0@1xh0@1h0@1j1.@1"j0@1Dj1@1hj0@1j1@1j0:@1j0@1j0!@1j06"@1j1*@1j0p+@11@1j1b2@03@1j0`6@1j1*7@1j1 8@1k09@1k19@1,k0d:@14k00>@1Nk1?@1k0B@1k1vN@1k0O@1k0U@1l0f@1l1l1w@1"l0w@1n0{@1n0@1"n1R@1@n0r@1Nn0z@1dn04@1vn0l@1<@1n1N@0R@1n0L@1n1~@1n0@1n0@1n0@1$o1@12o1@01@1Do0@1To0 @1jo1B@1o1@0@1o0@1o1@1o0<@1o0D@1p0@1"@1 p1"@0"@1"p0&@12p0t*@1Bp00@1r0fV@080x@1r0\~@1&r0ހ@18r1~@1Vr0@1fr0@1r1L@1r0@0d0@1r12@1r0P@1r0@1r0&(@1r1r1s1E@1s1F@1s0G@1s0a@1v0H|@01@1v1ܐ@00@1$v0΢@18v0B@1Hv1X@1Xv1@1rv0ֽ@1d0 @1d0 @1d0` @1d0 @1d0@1d0@1d0t@1d0R@1d0@1d0@1d0@1d0@1d0R@1d0@1d0@1d0d@1d0@1d0@1d0t@1d0x@1d0,@1d0@1d0X@1d0@1d0@1d0H@1d0@1d0@1d06 @1d0!@1d0!@0)@0 "@0(@0(@0~)@1\1\1\1\1\1\1\1\1\1\1\1`0\1\1\1\1]1]1]1]1&]1(]1*]0<]1`1`1`1`1`1`1`0$a1e1e1 e1.e12e14e16e0^e1`e1be1je1e1e1e1e0e0>]0)@GTimes New Roman5Symbol3 Arial7Courier9New York3Times;Helvetica5 Geneva" s%,*&l &J4##!+0d~=Linos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Article OOPCON-LidiaOOPCON workshop, BangkokBoitetmlSymbol3 Arial7Courier9New York3Times;Helvetica5 Geneva" s,*&l &J4# FMicrosoft Word DocumentNB6WWord.Document.8FFT  ՜.+,D՜.+,< hp  'lirmmL~:  OOPCON-Lidia Title 6> _PID_GUID'AN{401B9580-59E8-11D2-87C6-DF7B042A4760}&&{00030002-0000-0000-C000-0000000 Oh+'0  8 D P \hpx' OOPCON-LidiaWoOOPCON workshop, Bangkok.0Boitetwoit Articlerksmlt18tMicrosoft Word 8.0n@N<;@#o_Toc405612184 _Toc405612900 _Toc405632270 _Toc405632606B_Toc394686869B_Toc394405792B_Toc394686870B_Toc394405793B_Toc394686871B_Toc394405794B_Toc394686872B_Toc394405795B_Toc394686873B_Toc394767769B_Toc394833101B_Toc394832719 _Toc394910597 _Toc405612185 _Toc405612901 _Toc405632271 _Toc405632607B_Toc394405800B_Toc394686874B_Toc394767770B_Toc394833102B_Toc394832720 _Toc394910598 _Toc405612186 _Toc405612902 _Toc405632272 _Toc405632608B_Toc394405801B_Toc394686875B_Toc394767771B_Toc394833103B_Toc394832721 _Toc394910599 _Toc405612187 _Toc405612903 _Toc405632273 _Toc405632609B_Toc394686876B_Toc394767772B_Toc394832722B_Toc394405802B_Toc394833104 _Toc394910600 _Toc405612188 _Toc405612904 _Toc405632274 _Toc405632610B_Toc394405933B_Toc394405796B_Toc394405797B_Toc394405798B_Toc394405803B_Toc394405935B_Toc394686877B_Toc394767773B_Toc394833105B_Toc394832723 _Toc394910601 _Toc405612189 _Toc405612905 _Toc405632275 _Toc405632611B_Toc394686878B_Toc394767774B_Toc394832724B_Toc394405804B_Toc394405936B_Toc394833106 _Toc394910602 _Toc405612190 _Toc405612906 _Toc405632276 _Toc405632612B_Toc394686879B_Toc394686880B_Toc394767775B_Toc394833107B_Toc394832725 _Toc394910603 _Toc405612191 _Toc405612907 _Toc405632277 _Toc405632613B_Toc394405808B_Toc394405809B_Toc394405810B_Toc394767776B_Toc394833108B_Toc394832726 _Toc394910604 _Toc405612192 _Toc405612908 _Toc405632278 _Toc405632614B_Toc394405805B_Toc394405806B_Toc394405815B_Toc394686881B_Toc394405939B_Toc394767777B_Toc394833109B_Toc394832727 _Toc394910605 _Toc405612193 _Toc405612909 _Toc405632279 _Toc405632615B_Toc394686887B_Toc394405940B_Toc394405819B_Toc394767778B_Toc394833110B_Toc394832728 _Toc394910606 _Toc405612194 _Toc405612910 _Toc405632280 _Toc405632616B_Toc394686884B_Toc394767779B_Toc394833111B_Toc394832729 _Toc394910607 _Toc405612195 _Toc405612911 _Toc405632281 _Toc405632617B_Toc394767780B_Toc394833112B_Toc394832730 _Toc394910608 _Toc405612196 _Toc405612912 _Toc405632282 _Toc405632618B_Toc394686885B_Toc394767781B_Toc394833113B_Toc394832731 _Toc394910609 _Toc405612197 _Toc405612913 _Toc405632283 _Toc405632619B_Toc394686886B_Toc394767782B_Toc394833114B_Toc394832732 _Toc394910610 _Toc405612198 _Toc405612914 _Toc405632284 _Toc405632620B_Toc394405820B_Toc394405941B_Toc394686888B_Toc394767783B_Toc394833115B_Toc394832733 _Toc394910611 _Toc405612199 _Toc405612915 _Toc405632285 _Toc405632621B_Toc394767784B_Toc394832734B_Toc394833116B_Toc394405833B_Toc394405945B_Toc394686890 _Toc394910612 _Toc405612200 _Toc405612916 _Toc405632286 _Toc405632622B_Toc394767785B_Toc394833117B_Toc394832735 _Toc394910613 _Toc405612201 _Toc405612917 _Toc405632287 _Toc405632623B_Toc394767786B_Toc394833118B_Toc394832736 _Toc394910614 _Toc405612202 _Toc405612918 _Toc405632288 _Toc405632624B_Toc394686891B_Toc394767791B_Toc394833119B_Toc394832737 _Toc394910615 _Toc405612203 _Toc405612919 _Toc405632289 _Toc405632625B_Toc394833120B_Toc394832738 _Toc394910616 _Toc405612204 _Toc405612920 _Toc405632290 _Toc405632626B_Toc394833121B_Toc394832739 _Toc394910617 _Toc405612205 _Toc405612921 _Toc405632291 _Toc405632627B_Toc394833122B_Toc394832740 _Toc394910618 _Toc405612206 _Toc405612922 _Toc405632292 _Toc405632628B_Toc394767793B_Toc394686893B_Toc394833123B_Toc394832741 _Toc394910619 _Toc405612207 _Toc405612923 _Toc405632293 _Toc405632629 _Toc405612208 _Toc405612924 _Toc405632294 _Toc405632630B_Toc394833124 _Toc394910620 _Toc405612209 _Toc405612925 _Toc405632295 _Toc405632631B_Toc394833125 _Toc394910621 _Toc405612210 _Toc405612926 _Toc405632296 _Toc405632632B_Toc394832742B_Toc394405946B_Toc394405834B_Toc394405947B_Toc394405835B_Toc394405948B_Toc394405836yyccpp xxxxxxxxxxZ}Z}Z}Z}Z}Z}Z}Z}Z}Z}77QQ۪۪۪۪۪۪۪۪۪&&&&&&&&&&NNNNNNNNNNqqsE ,z4z4z4z4z4z4z4z4z4z4z4u???kVkVkVkVkVkVkVkViiiiiiiiiiiiiiiii1r1r1r1rrrrrrevevevevevevevevev~~~~~~~~~~~!!!!!!!!!!!ԁԁԁԁԁԁԁԁ*<<       ))))''''''!!%%   !"#$%&(')*+,-./6701234598;:=<?>@ACBDEFGHIJKMLNOPQRSTUWVXYZ[\]^_j`abcdegfhiklmnpoqrstuvwxyz{|}~*+     -, !"#$%&'().0/2143oo           /x/x/x/x/x/x/x/x/x/xs}s}s}s}s}s}s}s}}}iiǠǠQQWWWWWWWWWWppppppppp /////////U d1,44444444?7N7NVVVVVVVVVVViiiiiiiiiiiiiiiiisssssssssvvvvvvvvv~~           ========܁܁܁܁܁܁܁܁͉͉=======((((????$$$$$$IIIIII00-- d494969U9V9"'" '&'  %,9BM\hjsu} (2=CFGOUXYbeqs *6@COQ\cijs|+7CFRT]_jls} "$/1?LWZfhqs~  +-:<CQ]lz|"$,489ADO[fiuw *6@COQ\fq!X+X,X6X7X>XDXMXPX[X\X`XXXdZiZZZZZZZZZZZZZ[ [  +./347JRptѪ٪AJðưͰ9DӺٺnsؼݼ2=}%,8@owy"*6<LUVbRa19'8=MV]cis3< OW8>CF|v|KOlp &*JVZbdl[_~%+1<6:ekqy &-os[_|5;@Hrv $9ACG[bnqrz&+57<@Io~  '27>Fckq{;A (7BR[kty09=DY`ei$+7QUmp '(;<LNSZbdh.3"*:>?FHUV[\fsz| bhqy!0OWei}< < Heading 7$ & F@&6CJ@ @ Heading 8$ & F<@&6CJ< < Heading 9 $ & F@&6CJ<A@<Default Paragraph Font6*@6Endnote ReferenceH*8&@8Footnote ReferenceH*88TOC 8X4 n$ 88TOC 7R n#$88TOC 6R n#$88TOC 5R n#$2a2TOC 4(p !CJ>@>TOC 3"$$ n$8@8TOC 2 n$ 8@8TOC 1 ( n$ &&Index 7&&Index 6&&Index 5l& &Index 4QB BIndex 3P nCJN NIndex 2.$$dP  H!d#V VIndex 12$$d n H!d#CJ8 @8Footer $ 8!CJD@DHeader!$ n$6CJB@"B Footnote Text"( 0CJ88TOC 9#R& n#$>OB>Titre0$$$ n5CJ$(OAR(Auteur%5CJ\b\ Rfrences2&D n`, \ '(CJRrR Texte indent'$ D$d&d6CJXXProblmes ou maximes(H n6CJ(!(Rsum )PNONliste2*$$,( nH H TTRelief*+l  8<$ @ l+$ OJQJkH'JOJ sous-liste$,$S n H @@Italiques encadrs-$6..Cellule . ntOt Arbre indentG/$$ $n 0\`x   xF@F@$d&d(O(Figure0$8>!>Dfinition - corps1dN"NNormal encadr 2 0d$d&d>2>biblio3$$  OJQJkH'nn DfinitionC4$xd( )n 0 H xH!6NRNDfinition - liste5$4d(^b^ Sous-liste76$\ #n \ H!d#XrX Signatures27 )n \ H!d#R/AR Intertitres8$ & F<@& x 6>*CJ6O6caption 9$(P6CJXX Liste dcale,:`d n H HH Normal dcal;$Hdh 0JJGraphique-cadre<$$dhCJBOB Graphique=$2d nCJ\\Liste-justifie+>$0d( nx4O4Abstract?OCJBBSchma$@$d( n\^^Sous-liste-justifie$A$xd n j"jAdresse (lettre)(B$d n\d#CJOJQJkH'X2X Titre tableau$C$d n`5CJPBPAlgo&D$;,d nCJOJQJkH'NORNAdresse (article)E$d n*OQb*VersionF6@r@CommentG$d 06CJRRTitre-H$dx n`5CJLLAdresses)Ipd n ll Programme7J7d 0  . CJOJQJkH'OEcraneK$$dxPJ Dn\Ld \ H!d#8OJQJkH'TTAuteurs0L$7dx n06XX Affiliation/M$7dx 0NNResum0Nm7d n0`FFCellule dcaleO$ RRCellule centre!P$$( 4JJ A...de...&Q\dxx n4! `O` Ecran+large8R$Hd  \LdH!d#0`FO2FExemples Italiques S$$(6HOBHFichierT$ nCJOJQJkH'jARjRead-MeJUd /,0H`x  \ txNbNMessagesV$P nCJOJQJkH'@ar@Messages CourierW OJQJkH'XXListe numrote'X\\d n H RRAuteurs rapport"Y$  08FFJury,ZdP n 0FqFtoc 2' [$$0(P d#5CJFFAriane\$ nCJOJQJkH'``Liste dcale +/]$$\ <(  H x6A6 Fichier+large ^22Texte_d nHH Texte/num!`V0L< nttCellule-prog.liste:a$$$dP  0n  . CJV"VAriane10$b$ n$d&dCJOJQJkH'(!2(Ariane12cCJ&1B&Centrerd$@BR@ Body Texted<< n:b: TraductionsfCJOJQJkH'(!r(Ariane09gCJ`` Programme LT6h$$$d  0n  . HHBNF_commentaire id( OJQJkH'rr BNF_rgleAj0d *n `  x8 OJQJkH'~~Formule Beam Match;k$$$ n|4 ($d&d OJQJkH'JJPatronl$ nCJOJQJkH'Mthode_DialogueXm$dxx BnH`d   \ tx 8@CJOJQJkH'jjProgramme HB&GS6n$$$d  0n  . CJPPGraphique+large o$d$d&d`O` Bibliography2p$H( n, \ '(CJbb CD-File_lidia%qld< n8CJOJQJkH'T"T Texte encadr(r$$ DP$d&dP2P Auteurs 3+s$$d n h</@B<List!t0 n H 2oR2Titre1u & F<@& F2@AbFList 2(v$8P  H 8`6'@q6Comment ReferenceCJ0@0 Comment TextxCJ)-PQƒ"U>`c#      !"#|UUUUUUUUUUUUUUUUUUUU`````````cl  !"ml'"md49m49m69mU9mV9EpZ4Z#                              ! " #K$z2CP{c?ugۗE2@':-6I)R]m}{͉hF5K %F Do Y  u  3 ! "|&ycp +Z !U%H&j&4),,.-T/|///&0^0000.1f1112=2z266l8W9c:(; <{<&=v==>>?WAC1DKD8E[EKFEHIIJ-KKFL}LLwMyNN|OT#WY"\]/abde:gciijvmonppXqzt/vx0xTxx,yky%zz {o{"|Z}t}~j΃gD7j~"JQX۪[&X/mnH'(6qmn%`!"x/0yNqs)2JRs dhYcdgv9A !/)-u~59RV!6ACPT_rw #*DLpw(+,3W`acpwb,]0%EBEej|xTtv    BA**2e6    "#%''@'4(6(k((()*,2,9,:-<-]-../////0Q0061111112U33y4z4447;=u???bBCFGH$LwLM7NXNO)RkVV.WX!X7XDXPXaXkX~XX ?    "#&'()*+,./0123456789:;<=>$@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~!178;EIJO^egijnosty !;CLOVYZb~ $./23:=R]^eiu07SZ^gWWXi8l3dEa (d+m5uQm6R(DGc"&SZhBoitetHSyrinx:USERS.Syrinx:CB/Syrinx:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet7Linos3400:Temporary Items:Fichier temporaire Word A 878BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet7Linos3400:Temporary Items:Fichier temporaire Word A 310Boitet7Linos3400:Temporary Items:Fichier temporaire Word A 310BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet8Linos3400:Temporary Items:Fichier temporaire Word A 1974BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiamliSihir:Users:Mathieu Documents:ML articles:ML OOPCON-97:Editing/Reviewing OOPCON:OOPCON-CB.doc (rev ml v1) @<.@<.@n<.@<.@<.n<@\<()@ <()@<()EN_Doc_Font_List_Name[HEN_Lib_Name_List_Name[`EN_Main_Body_Style_Name[ӐTimes18Pacling.CBinv.NLibStyleCB@PP`[PPxmH q|  9 P '(JN OTtu"!!y""""" #'-',,--...w/{/////00%00000000$1'1-1111111252<2o2y2339: <<1<H<P<s<w<z<=!="=%===?@@@WACCC#C;CUCCCC0DFHHIJLLOO UU8WVWde[gnghhooppssPxSxr$5arՍ uvېbkґݑ ϔ?Qœ˟QWȰy ,6&V^_jHRV@D#,GV7;<@JR     +-01?2H244@4H4XEeEsP|PR'RUVannn|n~nrr݄LSUY ֶַֹֺ6712}^`%'}(*24jlOQAC`b<=  !789=OQRSghim0@1\1 @1\1 @1\1 @1P\1@1R\0@1h\0B@1x\0@1`1!@1`1!@1`1R`1z"@1`0($@1`0t&@1`01@1b1<@1b0<@1b1B@1b1B@1b0 F@1,b0K@1L@14b1M@1:b1M@0M@1d0B@1Rd0@1h0$@1h1@14h0D@1Nh0@1`h0@1xh0@1h0@1j1.@1"j0@1Dj1@1hj0@1j1@1j0:@1j0@1j0!@1j06"@1j1*@1j0p+@11@1j1b2@03@1j0`6@1j1*7@1j1 8@1k09@1k19@1,k0d:@14k00>@1Nk1?@1k0B@1k1vN@1k0O@1k0U@1l0f@1l1l1w@1"l0w@1n0{@1n0@1"n1R@1@n0r@1Nn0z@1dn04@1vn0l@1<@1n1N@0R@1n0L@1n1~@1n0@1n0@1n0@1$o1@12o1@01@1Do0@1To0 @1jo1B@1o1@0@1o0@1o1@1o0<@1o0D@1p0@1"@1 p1"@0"@1"p0&@12p0t*@1Bp00@1r0fV@080x@1r0\~@1&r0ހ@18r1~@1Vr0@1fr0@1r1L@1r0@0d0@1r12@1r0P@1r0@1r0&(@1r1r1s1E@1s1F@1s0G@1s0a@01@00@1d0 @1d0 @1d0` @1d0 @1d0@1d0@1d0t@1d0R@1d0@1d0@1d0@1d0@1d0R@1d0@1d0@1d0d@1d0@1d0@1d0t@1d0x@1d0,@1d0@1d0X@1d0@1d0@1d0H@1d0@1d0@1d06 @1d0!@1d0!@0)@0 "@0(@0(@0~)@1\1\1\1\1\1\1\1\1\1\1\1`0\1\1\1\1]1]1]1]1&]1(]1*]0<]1`1`1`1`1`1`1`0$a1e1e1 e1.e12e14e16e0^e1`e1be1je1e1e1e1e0e0>]0)@GTimes New Roman5Symbol3 Arial7Courier9New York3Times;Helvetica5 Geneva" s ,*&l &J4##!+0d~=Linos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Article OOPCON-LidiaOOPCON workshop, BangkokBoitetmlev~t{ FMicrosoft Word DocumentNB6WWord.Document.8FFT  ՜.+,D՜.+,< hp  'lirmmL~:  OOPCON-Lidia Title 6> _PID_GUID'AN{401B9580-59E8-11D2-87C6-DF7B042A4760}&&{00030002-0000-0000-C000-0000000 Oh+'0  8 D P \hpx' OOPCON-LidiaWoOOPCON workshop, Bangkok.0Boitetwoit Articlerksmlt17tMicrosoft Word 8.0n@y;@#o@H@rl#J4ExcelMacrosheet\A\ AutoconvertTo&&{00020820-0000-0000-C000-000000000046}hBh&&{00020820-0000-0000-C000-000000000046}Microsoft Excel WorksheetVCVTypelib&&{00020813-0000-0000-C000-000000000046}4D2  Insertable4E2  Printable4F4  MiscStatus c jbjbSS v11aY]N"N"(v" `%&*&)%\\\8tNʑʑʑ@ # ,Z%B ,Z%Z% Z% Z% >&b'b"b#bZ%Z%B@Z%Z%܊ >N:\Aspects of GETA's MT methodology applied to high-quality personal networking communication and pragmatic speech translation Christian BOITET GETA, CLIPS, IMAG-campus F-38041 GRENOBLE cedex 9 Christian.Boitet@imag.fr OOPCON-97, Bangkok, 714 December 1997 Abstract Ariane-G5 is an integrated environment initially designed to facilitate the development of multilingual MT systems for revisors (MT-R), where output quality is obtained by using the heuristic programming facilities of its 5 rule-based languages to specialize the lingware components to the sublanguage at hand. It can support many MT architectures and linguistic methodologies and accepts whole paragraphs or pages as units of translation rather than separate sentences. For MT-R, B.Vauquois' mutltilevel transfer approach has given excellent results on a large number of MT-R mockups and prototypes, as well as two large scale operational systems. As both the computer tools and the linguistic methodology are not embodiments of a particular theory, they are quite easy to adapt to new problems. In the last few years, they have actually been revised and further developed in the framework of new research on high quality MT for monolingual authors (MT-A), relying on a disambiguation dialogue with the author (DBMT), following an all-paths analysis. The evolution of Ariane-G5/LIDIA and associated linguistic methodologies is now motivated by two projects of different aims and requirements. The UNL project of personal multilingual high-quality communication over the Internet requires the construction of a large lexical database from which coherent dictionaries for MT and for interactive disambiguation will be generated. For the CSTAR Speech Translation (ST) project, it becomes necessary to start from phonetic lattices output by a speech recognizer, and to transmit some linguistically useful memory from one dialogue turn to the next. Keywords Machine Translation for Revisors, MT-R, Dialogue-Based Machine Translation, DBMT, Speech Translation, Machine Interpretation, Ariane-G5 MT shell, Multilevel Structures, Specialized Languages for Linguistic Programming, SLLP. Introduction From 1970 to 1988, GETA developed a linguistic methodology for building multilingual MT systems for revisors (MT-R), specialized to sublanguages, and relying on heuristic analysis. A comprehensive MT shell, Ariane-G5, has been programmed and used to develop a large number of MT-R mockups and prototypes, as well as two large-scale operational systems. Since 1988, the methodology and the computer tools have been revised and further developed in the framework of new research on high quality MT for monolingual authors, relying on a disambiguation dialogue with the author (DBMT), following an all-paths analysis. The software architecture has become distributed, with the author using a middle-range Macintosh, and Ariane-G5 running as a remote server and accessed through the Internet. This new basic software is now being used in two projects with different aims and requirements. First, in the UNL project o!6NXd _=   T   W   a  ?   /u p 78:<rs    S T o p               6 7 N O Q S r s                 9 : Q R T V { |               ' ( C D [ \ ^ `    mH jUb        ! " 9 : < > _ ` { |               )*,.DE`axy{}  !"$&67RSjkmoUVqrmH jUb/~'p[DfgZ\>]x 1$!1$"1$ [\DEZ\\P\R\\\\\\\\\]]]]@]B]``````````&a(abb:b]@]B]&a(a`eeeh2lJp:stx  long-termwe of CSTARII demonstrators. Its purpose is to show HTTPreviser (changed thereafter)PAGE \# "'Page: '#' '"  long sentence splited Ministryit inareviserTongarehypervisor, whichorganization :analyseare:ATEF;EXPANS;in EXPANS;are:in EXPANS;EXPANS;in ROBRA;are:EXPANS;in ROBRA;EXPANS;in SYGMOR.lingwareand lexicalhmetical variable V defined by non-nullin:set consistingof:); write:-EXC- ** (key optionallydictionariesanconstitute variable, for  relation logic222881111111315151517202324242525262626262727282931313232PAGE \# "'Page: '#' '" instead of Ministery PAGE \# "'Page: '#' '"  instead of be eeehll2lnoJp:st6mH CJmH mH  revisergeneration consistsstep consistsnon-fixedOrganizationusually consiststo: with backtrackinganalysis consistscondition consistswith backtrackingaction:to:in backtracking););now noare no.containsastructure:containedGT consistsmodedecidability:schemas, which appear in left-hand sides of rules,possibly differentanneighborsdictionariessteps:man-yearsRussian reviserPortugueseFrench consistshalf iscategories,argumentsor circumstantials. IMPORTANT:fully automated, standardparameterizedhoc transformationsreviserMacintoshCyrillicstructured:transcriptor consistsparameterithatdatabasessystems cannotambiguities, whichsoftware, which databasefeedbackvs. HyperCardgenerationinvertingtransliterationCyrillicintentionallyman-yearsdatabasesinteractivelyanformulatingsynthesizerEnvironnementoriginallyaparameterized XXXXXXY0YeYxYY Z,Z.ZIZkZZZZZZZZZZ [['[1[:[C[V[[[[]]D^^^V__`-``&aabcaccgdddreef@ffgGggghiiihlnrpmq1rrsHsstttu3umuevvGwnww5xhxxyz||4}[}]~~!>ԁ݁)*͉T:%Wʗٗ#Z>N,?qÞ1TFywNͥ9PqM-֯.*c*<Ƿn{}!   )@%'J!1YK4r|y `#V^* ]w)]xE$pn y1=$$ $$$$!$$$PS$$ $PS$PS$$$PS$PS $PS$PS$PS$PS$PS$PS $PS$PS$!$PS$PS$PS$!$!$PS$PS$PS$!$PS$!$PS$!$PS$!$PS$PS$!$PS$PS$PS$PS$PS$Ď$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS $PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$!$PS $PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PSPSPSm$PS$PSPSPSm$PSPSPSm$PSPSPS`$PSPSPSm$PSPSPS $PSPSPS`$PSPSPSPSPS $PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$2$PS$PS$(+ $PS$PS$PS$PS$PS$PS& -&&! _  ! PS PS PSh+$PS$PS$PS$PS$f%$!$PS$f%$!$PS$)$!$PS$PS$PS$!$PSr;r!HPSHPSHPS^&$!r;r!HPSHPSHPSHPSHPSX $$!rr!HPSHPSHPSX $$PS$PS$PS$PS$PS$PS$PS$!$PS$PS$PS$!$PS $PS$!$PS$!$PS$PS$PS$PS$PS$PS$PS$$$$$$$$$$$$$$$$$PS$$$$$$$$$$$$$$$$$$$$$$$$$$$$PS$$$$$$$$$$$$$$$$$$$$$$$$$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$.,$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$l$$PS$PS$PS$*$PSp%PSPS'81$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$PS$$$PS$PS$PS$$ $PS$$$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$!$$!$!$!$!$!$!$!$$|&ycp +Zc  !#U%H&j&4),,.-T/|///&0^0000.1f1112=2z27466l8W9c:(; <{<&=v==>>?WAC1DKD8E[EKFEHIIJ-KKFL}LLwMyNN|OOT#WY"\]/abde:gciijvmonppXqzt/vx0xTxx,yky%zz {o{"||Z}t}}~j΃gD7jj~"JQȠRX۪R[&X/mnH'(6qmn%`!"x/0yNqs_b#,]0%EB1Eej|xTtS v    BA**2e6    "#%''@'4(6(k((()*,2,9,:-<-]-../////0Q0061111112U33y4z444579;=u???bBCFGH$LwLMM7NXNO)RTkVV.WX!X7XDXPXaXkX~XXXXXXXXY0YeYxYY Z,Z.ZIZkZZZZZZZZZZ [['[1[:[C[V[[[[]]D^^^V__`-``&aabcaccgdddreef@ffgGggghiiihlnrpmq1rrsHsstttu3umuevvGwnww5xhxxyz}{||4}[}]~~!>ԁ݁)*͉|T:%Wʗٗ#Z>N,?qÞ1TFywNͥ9PqMk-֯.*c*<NǷn{}!   )@5%'J!1YK4r|y `#V^* ]w)]xE$pnk $.:5c*-7oTFey1<=8h$%Fu??uu  (  8  H&H&8  H ,,,,*,*,*,*,,*,*,*,*,,*,*,*,*,,,H ,,666*6*6*6*6,6,6,66666*6*66H ,,8E*8E*8E*8E*8E*8E8E8E*8E*8E*8E8E8  yNH yNyN|O|O|O|O|O|O|O|O|O|O|OH yNyNciciciciH yNyNpppp( x*x*x*x*x*x*x*x*x*xx( 8 Z}Z}t}t}t}t}*t}*t}*t}*t}t}t}t}8 Z}Z}7777777778 Z}Z}QQ8 Z}Z}8 Z}Z}** ۪۪( ۪۪8 8 8 ( ۪۪&S&S&&&&S&S&&&S&S&&&S&S&&&S&S&&&S&S&&&S&S&&&S&S&&S&S&&&( ۪۪8 NNqH qqX ssX ssX ssbbX ssH qqX X X 8 NN]]]  ( 8 8 EtEtEtEtEtEtEtEtEtEE8    /   /   ( 8 2K292K29222222222K2922K2922K292228 H ,,2,R2,92,2,2,2,2,H ,,R/9///////H ,,R1911111( 8 z4z44444448 z4z4H u?u????H u?u?FFH u?u?$L0$L9$L8 z4z47N7N7N7N kVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVTkVkVkV ( iiiiiiii( iirtrtrtrrtrtrtrr( iievtevtevtevevtevtevtevtevtevtevtevtevtevev  ~~!( !!ԁԁԁԁ( !! ~~ttttt( =8 8 8 ʗʗtʗtʗʗ( 8 t>t>8 t,t,t,t,t,8 t1t1t1t118 wwwtwtwtwtwtwtwwwwww8 MMM( 8 vvvvvvvttt8 tvv=vv=== ~~(   )))(   vvvv(   'u''''u''u'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p'p' 'u'''''''''''''''''''''''''''''''' '""""""! xxxxxRRUUX[F:#L^Dc5 e:s "%')*,30"A0bѨQ8 +:Hg5jtJW[T!/>]:s     !#$&(+/+0K!Z!^!$,$1$>%M%R%56D6I6-P@ACBDEFGHIJKMLNOPQRSTUWVXYZ[\]^_j`abcdegfhiklmnpoqrstuvwxyz{|}~*+     -, !"#$%&'().0/2143oo           /x/x/x/x/x/x/x/x/x/xs}s}s}s}s}s}s}s}}}iiǠǠQQWWWWWWWWWWppppppppp /////////U d1,44444444?7N7NVVVVVVVVVVViiiiiiiiiiiiiiiiisssssssssvvvvvvvvv~~           ========܁܁܁܁܁܁܁܁͉͉=======((((????$$$$$$IIIIII00-- d494969U9V9"'" '&'  %,9BM\hjsu} (2=CFGOUXYbeqs *6@COQ\cijs|+7CFRT]_jls} "$/1?LWZfhqs~  +-:<CQ]lz|"$,489ADO[fiuw *6@COQ\fq!X+X,X6X7X>XDXMXPX[X\X`XXXdZiZZZZZZZZZZZZZ[ [  +./347JRptѪ٪AJðưͰ9DӺٺnsؼݼ2=}%,8@owy"*6<LUVbRa19'8=MV]cis3< OW8>CF|v|KOlp &*JVZbdl[_~%+1<6:ekqy &-os[_|5;@Hrv $9ACG[bnqrz&+57<@Io~  '27>Fckq{;A (7BR[kty09=DY`ei$+7QUmp '(;<LNSZbdh.3"*:>?FHUV[\fsz| bhqy!0OWei})2JRs dhYcdgv9A !/)-u~59RV!6ACPT_rw #*DLpw(+,3W`acpw!178;EIJO^egijnosty !;CLOVYZb~ $./23:=R]^eiu07SZ^g@H@NCm#J4ExcelMacrosheet\A\ AutoconvertTo&&{00020820-0000-0000-C000-000000000046}hBh&&{00020820-0000-0000-C000-000000000046}Microsoft Excel WorksheetVCVTypelib&&{00020813-0000-0000-C000-000000000046}4D2  Insertable4E2  Printable4F4  MiscStatusProblemrecognitioncommercialrevisersMinistryparticipationMinistry c jbjbSS x11aY]N"N"(v" `%&*&)%\\\8tNʑʑʑ@ # ,dXZ%B ,WWXi8l3dEa (d+m5uQm6R(DGc"&SZhBoitetHSyrinx:USERS.Syrinx:CB/Syrinx:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet7Linos3400:Temporary Items:Fichier temporaire Word A 878BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet7Linos3400:Temporary Items:Fichier temporaire Word A 310Boitet7Linos3400:Temporary Items:Fichier temporaire Word A 310BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitet8Linos3400:Temporary Items:Fichier temporaire Word A 1974BoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiaBoitetQLinos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Thailande.12/97:OOPCON-LidiamliSihir:Users:Mathieu Documents:ML articles:ML OOPCON-97:Editing/Reviewing OOPCON:OOPCON-CB.doc (rev ml v1) @<.@<.@n<.@<.@<.n<@\<()@ <()@<()EN_Doc_Font_List_Name[HEN_Lib_Name_List_Name[`EN_Main_Body_Style_Name[ӐTimes18Pacling.CBinv.NLibStyleCB@`[  xmH q|  9 P '(JN OTtu"!!y""""" #'-',,--...w/{/////00%00000000$1'1-1111111252<2o2y2339: <<1<H<P<s<w<z<=!="=%===?@@@WACCC#C;CUCCCC0DFHHIJLLOO UU8WVWde[gnghhooppssPxSxr$5arՍ uvېbkґݑ ϔ?Qœ˟QWȰy ,6&V^_jHRV@D#,GV7;<@JR     +-01?2H244@4H4XEeEsP|PR'RUVannn|n~nrr݄LSUY ֶַֹֺ6712}^`%'}(*24jlOQAC`b<=  !789=OQRSghim0@1\1 @1\1 @1\1 @1P\1@1R\0@1h\0B@1x\0@1`1!@1`1!@1`1R`1z"@1`0($@1`0t&@1`01@1b1<@1b0<@1b1B@1b1B@1b0 F@1,b0K@1L@14b1M@1:b1M@0M@1d0B@1Rd0@1h0$@1h1@14h0D@1Nh0@1`h0@1xh0@1h0@1j1.@1"j0@1Dj1@1hj0@1j1@1j0:@1j0@1j0!@1j06"@1j1*@1j0p+@11@1j1b2@03@1j0`6@1j1*7@1j1 8@1k09@1k19@1,k0d:@14k00>@1Nk1?@1k0B@1k1vN@1k0O@1k0U@1l0f@1l1l1w@1"l0w@1n0{@1n0@1"n1R@1@n0r@1Nn0z@1dn04@1vn0l@1<@1n1N@0R@1n0L@1n1~@1n0@1n0@1n0@1$o1@12o1@01@1Do0@1To0 @1jo1B@1o1@0@1o0@1o1@1o0<@1o0D@1p0@1"@1 p1"@0"@1"p0&@12p0t*@1Bp00@1r0fV@080x@1r0\~@1&r0ހ@18r1~@1Vr0@1fr0@1r1L@1r0@0d0@1r12@1r0P@1r0@1r0&(@1r1r1s1E@1s1F@1s0G@1s0a@01@00@1d0 @1d0 @1d0` @1d0 @1d0@1d0@1d0t@1d0R@1d0@1d0@1d0@1d0@1d0R@1d0@1d0@1d0d@1d0@1d0@1d0t@1d0x@1d0,@1d0@1d0X@1d0@1d0@1d0H@1d0@1d0@1d06 @1d0!@1d0!@0)@0 "@0(@0(@0~)@1\1\1\1\1\1\1\1\1\1\1\1`0\1\1\1\1]1]1]1]1&]1(]1*]0<]1`1`1`1`1`1`1`0$a1e1e1 e1.e12e14e16e0^e1`e1be1je1e1e1e1e0e0>]0)@GTimes New Roman5Symbol3 Arial7Courier9New York3Times;Helvetica5 Geneva" s,*&l &J4##!+0d~=Linos3400:X.Linos:USERS.Linos:CB/Linos:ArticlesCB-97:Article OOPCON-LidiaOOPCON workshop, BangkokBoitetml.lR=oZ%Z% Z% Z% >&b'b"b#bZ%Z%B0Z%Z%܊ 8>N:\Aspects of GETA's MT methodology applied to high-quality personal networking communication and pragmatic speech translation Christian BOITET GETA, CLIPS, IMAG-campus F-38041 GRENOBLE cedex 9 Christian.Boitet@imag.fr OOPCON-97, Bangkok, 714 December 1997 Abstract Ariane-G5 is an integrated environment initially designed to facilitate the development of multilingual MT systems for revisors (MT-R), where output quality is obtained by using the heuristic programming facilities of its 5 rule-based languages to specialize the lingware components to the sublanguage at hand. It can support many MT architectures and linguistic methodologies and accepts whole paragraphs or pages as units of translation rather than separate sentences. For MT-R, B.Vauquois' mutltilevel transfer approach has given excellent results on a large number of MT-R mockups and prototypes, as well as two large scale operational systems. As both the computer tools and the linguistic methodology are not embodiments of a particular theory, they are quite easy to adapt to new problems. In the last few years, they have actually been revised and further developed in the framework of new research on high quality MT for monolingual authors (MT-A), relying on a disambiguation dialogue with the author (DBMT), following an all-paths analysis. The evolution of Ariane-G5/LIDIA and associated linguistic methodologies is now motivated by two projects of different aims and requirements. The UNL project of personal multilingual high-quality communication over the Internet requires the construction of a large lexical database from which coherent dictionaries for MT and for interactive disambiguation will be generated. For the CSTAR Speech Translation (ST) project, it becomes necessary to start from phonetic lattices output by a speech recognizer, and to transmit some linguistically useful memory from one dialogue turn to the next. Keywords Machine Translation for Revisors, MT-R, Dialogue-Based Machine Translation, DBMT, Speech Translation, Machine Interpretation, Ariane-G5 MT shell, Multilevel Structures, Specialized Languages for Linguistic Programming, SLLP. Introduction From 1970 to 1988, GETA developed a linguistic methodology for building multilingual MT systems for revisors (MT-R), specialized to sublanguages, and relying on heuristic analysis. A comprehensive MT shell, Ariane-G5, has been programmed and used to develop a large number of MT-R mockups and prototypes, as well as two large-scale operational systems. Since 1988, the methodology and the computer tools have been revised and further developed in the framework of new research on high quality MT for monolingual authors, relying on a disambiguation dialogue with the author (DBMT), following an all-paths analysis. The software architecture has become distributed, with the author using a middle-range Macintosh, and Ariane-G5 running as a remote server and accessed through the Internet. This new basic software is now being used in two projects with different aims and requirements. First, in the UNL project o!6NXd _=   T   W   a  ?   /u p 78:<rs    S T o p               6 7 N O Q S r s                 9 : Q R T V { |               ' ( C D [ \ ^ `    mH jUb        ! " 9 : < > _ ` { |               )*,.DE`axy{}  !"$&67RSjkmoUVqrmH jUb/~'p[DfgZ\>]x 1$!1$"1$ [\DEZ\\P\R\\\\\\\\\]]]]@]B]``````````&a(abb:b]@]B]&a(a`eeeh2lJp:stvx  long-termwe of CSTARII demonstrators. Its purpose is to show HTTPreviser (changed thereafter)PAGE \# "'Page: '#' '"  long sentence splited Ministryit inareviserTongarehypervisor, whichorganization :analyseare:ATEF;EXPANS;in EXPANS;are:in EXPANS;EXPANS;in ROBRA;are:EXPANS;in ROBRA;EXPANS;in SYGMOR.lingwareand lexicalhmetical variable V defined by non-nullin:set consistingof:); write:-EXC- ** (key optionallydictionariesanconstitute variable, for  relation logic222881111111315151517202324242525262626262727282931313232PAGE \# "'Page: '#' '" instead of Ministery PAGE \# "'Page: '#' '"  instead of be eeehll2lnoJp:stv6mH CJmH mH  revisergeneration consistsstep consistsnon-fixedOrganizationusually consiststo: with backtrackinganalysis consistscondition consistswith backtrackingaction:to:in backtracking););now noare no.containsastructure:containedGT consistsmodedecidability:schemas, which appear in left-hand sides of rules,possibly differentanneighborsdictionariessteps:man-yearsRussian reviserPortugueseFrench consistshalf iscategories,argumentsor circumstantials. IMPORTANT:fully automated, standardparameterizedhoc transformationsreviserMacintoshCyrillicstructured:transcriptor consistsparameterithatdatabasessystems cannotambiguities, whichsoftware, which databasefeedbackvs. HyperCardgenerationinvertingtransliterationCyrillicintentionallyman-yearsdatabasesinteractivelyanformulatingsynthesizerEnvironnementoriginallyaparameterized