Making a service out of MT

This was the year when our company first involved itself with MT, at that time purchasing the Siemens METAL system, which, then ran on a Symbolics computer with a Siemens MX 300 front-end system. Since then S&D has done a range of large scale but limited term projects using METAL for companies such as Dornier, Volkswagen and Thyssen. Then as now, we, as a company, are quite convinced that machine translation has a future which goes beyond its current limited range of use. Most of the references in this talk relate to Germany and the German market; this is no coincidence, since Germany is very much our "home turf.


Introduction
This paper is neither intended to be one of those "definitive" reports on the state of MT today nor is it "my favourite MT failures" in the past 10 years. It is more the result of a firm's practical and pragmatic experience with MT' since 1988. This was the year when our company first involved itself with MT, at that time purchasing the Siemens METAL system, which, then ran on a Symbolics computer with a Siemens MX 300 front-end system. Since then S&D has done a range of large scale but limited term projects using METAL for companies such as Dornier, Volkswagen and Thyssen. Then as now, we, as a company, are quite convinced that machine translation has a future which goes beyond its current limited range of use. Most of the references in this talk relate to Germany and the German market; this is no coincidence, since Germany is very much our "home turf 1 .

Lessons from the past
Looking then at the situation in Germany, up to the end of 1995, there were really two machine translation systems competing for the so-called "high-end market"". These were METAL from Siemens, through its subsidiary Sietec, and Logos, produced by the firm of the same name. Since this year, the METAL system is no longer being sold -leaving Logos as really the only highend MT product being sold actively. What happened to METAL? The story is indicative of the situation that machine translation seems to be in the 1990's.
Since I had been involved on the sales and product development side of the METAL system from 1992 onwards, it seemed sensible to do a post-mortem on the demised patient. First of all, what did the patient die of? This, in itself, is a very hard question. It is rather like finding a man who has been run over by a train, shot full of arrows, with his breath smelling of arsenic and trying to decide what got him first! There may have been many contributing reasons,poor management, firm politics, bad sales people... This list is potentially endless.
The most important problem was, however, probably that this expensive machine translation system, costing many tens of thousands of pounds, was, like many others, seen as not having "delivered" what it set out to do. In German this is the difference between the "Soll" and the "Ist"; i.e. the gap between expectation and reality in various areas was too large. This was the case as regards: 1. MT software manufacturer expectations. In a nut-shell, the sales and marketing scenarios for high-end MT products run something like this: "every day, many millions of documents are produced -many of these need to be translated. Of these, xx % are in electronic form and may well be suitable for machine translation. Since we are a (or the) leading MT software manufacturer, we can rightly claim an xx % share of the MT market. This, in turn, means xx million pounds turnover per year." I don't think I need to say much more other than the fact that this form of argumentation is a little wobbly to say the least! 2. Customer expectations: Since a lot of decisions regarding MT in German companies (and probably elsewhere) were and are top-down decisions, the logic would run something like this: we will give this company xxx thousand Deutsche Marks for their MT black box and our translation problems are solved. The fact that the MT company rep. mumbled a few things about "raw" quality and that the machine can't translate the company's ad texts goes unnoticed in the general first flush of enthusiasm for the system. Management statements along the lines of, "If we install on Monday, train on Tuesday, Wednesday and Thursday, we can start producing good translations on Friday" are and were quite familiar.
3. Coupled with this seems to be the belief, somewhat ill-founded, that MT manufacturers always know what the customer needs better than the customers themselves. Asking customers always seems to be a problem among machine translation vendors, since they invariably seem to contradict the R&D work that the vendor is engaged in.

Selling MT
If we try and look at the activity of selling high-end MT systems in terms of a flow chart, it could then look something like this. Starting with a good potential MT customer lead, i.e., the firm in question exports a lot, has a high turnover and is producing high-tech, products with short release cycles in a competitive time-to-market type market. With this customer lead we reach a series of decision branches (our hurdles). Let's see what the chances are of riding the tiger through to the end of the flow chart. Some pitfalls in the race to the next new customer. MT service providers may open up new perspectives for both end user and MT software vendors.

Motivated
The decision hurdles: i. the customer has already heard about MT. He bought a software package for his PC for $ 500,-, he used it once and didn't use it again. ii. Murphy's law states that a customer always has the MT language pair that you don't have for your system. iii. The customer uses a proprietary text software that has no equivalent converter in the system. iv. The customer has no terminology base that the MT system could absorb.
This could make start-up costs for the customer prohibitively expensive, if his terminology area is not suitably covered by the MT system already. This is almost never the case. v. He has no UNIX experience or his firm are only prepared to support a certain make of UNIX platform, or he has the right UNIX experience but the wrong UNIX version for your program. vi. The wrong kind of documents. By this I mean documents which, due to their structure, sentence length, clause complexity, standard of grammar etc., simply do not parse at all well in an MT system. vii. With all previous hurdles successfully overcome, the MT vendor may well stumble at the vexing question of personnel. It then becomes clear that this lead has no chance of getting personnel to operate the system in-house. viii. Finally, the management decision. The management hardly ever see translation as belonging to core business in a firm. If an MT provider has run the gauntlet successfully up to now, it is often here that the sales attempt fails. It is hardly ever the initial cost, however high, of an MT system that causes management headaches, but rather the ensuing personnel costs required to train and maintain the system, and the hiatus which normally occurs between system commissioning and full production using it.
It seems quite easy to estimate the average kind of success rate in finding the particular customer to match these criteria. It is rather like trying to find a three-legged man, and once having found him, asking him if he is prepared to undergo a few minor operations because he still does not quite fit the clothes you are selling.
Looking back at our flow chart it would seem logical that alternatives for decisions and branches need to be found, which would otherwise be not applicable or available, thus eliminating any chance of using MT. The question that poses itself is could such problems as the missing infrastructure at a customer be solved by providing some form of MT service?
MT software vendors have seemed to be rather unsure in the past as how to approach this. One option would be that they themselves provide an MT service. The down side of this is, of course, that a poor quality service, for whatever reason, reflects on the product itself.
An alternative would be to encourage suitable translation bureaus to undertake this kind of operation as a joint venture with the MT vendors themselves. This has interesting synergies for both sides. For the MT vendor, it may be possible to obtain indirect revenue for the product via the provider who shares turnover with the manufacturer. It also means that a potential MT customer is not lost to the MT community simply because of such factors as unavailable in-house UNIX support or lack of personnel as would otherwise be the case. Theoretically, a transition from provider to in-house use of the same technology would be possible if the customer is pleased with the results of the MT system over a period of time. For the translation bureau, which is prepared to make the jump to becoming an MT provider, it means an interesting add-on service for selected key customers.

System requirements
The next aspect I should like to look at are the system requirements that such an MT system might call for. For the sake of argument, I should like to generalise, and suggest that an MT system has the following basic structure: 1. A module for inputting and converting text and text format. 2. A module for segmenting and preprocessing the text. Here the input text is "cleaned up". This means replacing known and frequent spelling mistakes, protecting program code and other untranslatable areas from the translation parser itself, handling proper names, and modifying phrases that the MT system literally "gets wrong". This module is one of the most pragmatic parts of the MT system, reflecting probably better than any other the difference between theory and practice in machine translation. In theory, in the best of all possible worlds, the grammar of the translation engine might be tuned or manipulated to correct this fault or even better, that it learns "on the fly" through human post-editing what it's doing wrong. Pragmatically speaking, we need a module before the translation engine to take out the phrases the translation engine does not like. This module also includes a translation memory element. Since I do not wish to go into the pros and cons of fuzzy logic, multiple choice, on-or offline translation systems, I should just like to make these points: • There seemed little point as a service provider in giving a monolingual non-linguist, who is trying to have his German e-mail translated into English, a choice of translation possibilities. • There may well be a place for 100 % match translations or, translations which are a 100 % match, apart from accepted variables. This, again, is a purely pragmatical approach. Since the majority of MT systems are not able to learn from their own mistakes, the only possibility of preventing repeated parsing mistakes in the short-term is to avoid the parser in the first place.
3. The next module is really the heart of the system, the look-up and translation engine and the dictionaries that support it. The dictionaries are another area which require a very pragmatic view. Looking at some of the MT systems available in Europe, the question which always seems to arise is how on earth was anyone ever expected to get more than a few additional words into the dictionary? The few successful European MT users with corporate environments have been struggling with this problem for a very long time. Since, in the case of the Logos and METAL systems, for example, both are capable of producing a terminological text preanalysis or new word search, the result could be fed into a utility for mass coding (entering) of new terminology.
As an example, the German software company SAP AG, with a very pragmatic approach to machine translation, has produced a Microsoft Word macro for just this purpose. Using this tool, SAP claim coding speeds of up to 120 noun pairs per hour using the system.
4. The module following the translation look-up process is really module 2 in reverse, with a final possibility in the case of the METAL system of cleaning up the text before it is finally reformatted. 5. The 5 th module has very little to do with machine translation and a lot more to do with providing a service. Of course, all work done by the machine will have to be paid for and logging and tracking procedures for billing individual customers or cost units within customer sites must be made available.
Since no MT system seems to offer all the solutions, situations will certainly arise where more than one MT system could be used by a service provider. In this case, it would make sense not to have to duplicate all aspects in of both system but to have various common features, "cherry picking", the best modules for the job. Accompanying this, will be a necessity for MT manufacturers to be more open in the specification of their interfaces to various modules. It is quite likely that a system provider may wish to build his own front-end for certain clients to enable certain features to be used automatically.

Approaching MT as a service: options
If we look at MT as the proverbial sausage machine, one thing becomes immediately very clear. The quality of the raw materials going in to the machine determine to a great extent the quality of the output result. Imagine trying to make sausages when you have no idea of the ingredients you are using! The same applies to machine translation; the more of the process you control, the better the result. Below are two possible approaches for MT service providers which differ in the level of control which they over texts submitted to the system: A. The "spider in the (word-wide) web" approach. Here, the provider is waiting for unwary, monolingual flies. In the short term, there may be a lot to eat, but, like the spider, the provider cannot be selective in what he gets. There will be a large amount of material which, in terms of MT input, can only be termed rubbish. Processing rubbish cannot be the intention of the MT provider nor of the serious MT vendor whose software is being used.
B. This approach follows the doctrine that the more MT variables you can control, the better your MT output. In this approach, the one that we have adopted, there is no interest in obtaining translations from casual MT users via the Internet, for example. The idea is to provide existing translation bureau customers with additional translation services and new customers seeking MT services with a complete MT infrastructure. Here, the procedure with all customers has been fairly similar: 1. In the initial phase, after discussions with management, one or more MT workshops within the company have been started where the concept of MT has been discussed.
2. Moving on from this, representative documents from various corporate sectors have been processed and commented on with regard to the quality-time-cost triangle, i.e. what is the purpose of trying to use MT with this text; are we trying to improve speed of information, consistency of translation or trying to cut costs? Are the goals realistic for this text type? This process aims to define suitable text-type candidates for MT-based translation services.
3. Organisation of so-called MT "awareness" workshops with groups of selected client users. Working with the end users of the service, (possibly engineers, technicians, managers -in nearly all cases nonlinguists) simple rules for writing suitable texts are discussed along with limitations and time constraints this might impose.
4. In the pilot translation phases for the various text/document areas already identified with the customer as being suitable for MT, nearly all translations are not only translated but also preanalysed to determine the level of missing terminology, for example. This terminology is coded for the customer, and the customer is invoiced for it. Each time the customer is provided with a list of new terms coded along with the invoice. These terms are the property of the MT provider and the customer.
5. Feedback meetings with the customer's users of the service are convened regularly to review and discuss unresolved issues of form, grammar, terminology etc.
6. The results of such a meeting may well be to extend the area of reference for the machine translation system within the customer's firm. Each new step will certainly pose new difficulties of terminology, style, formatting etc. This makes it all the more important to proceed in very small controlled steps. Our experience is that we, the provider, are normally trying to slow down the customer, to prevent too much from being tackled at once.
In the initial phases, there may well be a very few texts which are successful after simply "pushing them through the machine". However, to help build confidence and acceptance at least 2 other processing options are required. Apart from "raw" or "gist" machine translation there must be a selectable level which is called communication translation; a level suitable for e-mails, internal communication, memos etc. where a human translator has quickly checked the output of the MT system. Above that would be a publication quality translation which, depending on language and other variables, might or might not involve the MT system itself.
Advice: My advice to any would-be MT translation provider is to really consider what the pros and cons of such a step: ■ It will probably mean "getting your hands dirty", since no MT system seems to work well and flexibly enough that it does not require some form of adaptation by you, the provider. ■ MT has more to do with efficient processing of information than the accepted "art" of translation. Some of your translators will feel their position threatened by such a machine, or are not able to accept or correctly evaluate the level of advantage (or disadvantage) gained by the machine's output as a basis for their own translation. ■ Be very pragmatic -you will have to be. You will have to find work-arounds, trace bugs and do your own troubleshooting. MT as a service is still pioneering work in many cases!

Current status and future plans
This system is now being piloted with our German customers firstly for the language direction German / English, with English / German set to follow in the Spring. Access to this system is at present via e-mail, where every job to be translated is accompanied by a parameter file listing the order of processes and options, customer-specific memory units and specialist terminology to be implemented during the translation run. Additional MT projects involving the Baltic region are planned in conjunction with the Fachhochschule Flensburg which has already integrated both the METAL and Logos systems into its training courses for technical translators. ' MT or machine translation. The translating of electronic documents in batch mode using a computer according to a predefined set of parameters.