freecats-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freecats-Dev] Re: Bilingual file formats


From: Marc Prior
Subject: [Freecats-Dev] Re: Bilingual file formats
Date: Thu, 15 May 2003 20:15:58 +0200

Hi Charles,

> What can be achieved with bilingual file formats?  I mean,
> what *in*principle* can bilingual file formats represent that
> TMs cannot?  My gut feeling is nothing.

Actually, I have been saying this myself for some time. I have been objecting 
(sometimes quite vociferously) on certain mailing lists to Trados being 
referred to as the "industry standard" since, in my view, the industry 
standard is TMX.

The trouble is that this is only partly true, since customers, such as 
agencies who maintain their own TMs, increasingly don't want the final text 
plus a TM; they want the "uncleaned", i.e. bilingual file. This is one of the 
great strengths of Wordfast, for example: it can emulate Trados' "uncleaned 
(Word) file" format. Whilst I feel it's legitimate to argue that Trados' TM 
memory format is anything but a standard, it's hard to say the same of the 
uncleaned file format, since there is no standard.

You can of course argue that if you supply the *source* file PLUS your TM, 
you've supplied your customer (or the next entity in the supply chain) with 
the same information. Your customer, assuming he has an application (to all 
intents and purposes a TM application) that can handle both the text and the 
TM format, can a) reproduce the final translation, b) edit the final 
translation and c) update the TM accordingly.

There are two problems with this scenario. One is that the next entity in the 
supply chain, an editor for example, will not necessarily have a TM 
application. What happens in that case? Well, if you have Trados, or 
Wordfast, you can send your uncleaned file. The fact that it's an interim 
format used in the translation process is irrelevant as far as the editor is 
concerned. (Not to you, the translator, though; until the very last version 
is produced, arguably the translation process isn't over.) The editor 
receives a Word file with the instruction to hide the "hidden" text. Then he 
can do what he likes with it. When it comes back to you, you can - perhaps 
after making further changes of your own or undoing some of his - update your 
TM and finally clean the file.

The other problem with sending the source file and the TM is that it excludes 
the use of collaboration functions. Your editor in the above example may not 
only make changes to the file: he may also use the collaboration functions 
(revision, notes). In that case, you can review these changes in a word 
processor when you receive the file back from him. THEN you continue 
processing the file in the TM application that produced it. If, though, you 
only sent your editor the monolingual target-text file, you have no easy way 
of updating your TM when you receive his changes back.

The benefit of a bilingual file format only materializes, of course, if 
applications become widely available and accepted which a) support the format 
whilst b) continuing to be as user-friendly as conventional word processors. 
If a bilingual file format becomes an accepted industry standard, though, 
word processor vendors will begin integrating support for it, much as they 
already have for HTML. If they don't (the most obvious scenario being that 
Microsoft could decide not to integrate XLIFF support in Word), the support 
will come about by other means, for example by pseudo-standard formats (i.e. 
a form of XLIFF that can be read by Word, and filters to and from it). That 
is exactly what the Trados uncleaned Word file format is; it is an internal 
Trados format which happens to be readable in Word (thanks to the design of 
Trados), one that probably wasn't even originally conceived as a format for 
data interchange.

Does that answer your question? Then consider this real-case scenario:

Customer wants:
- to send a source file to the translator in MS Word format;
- to receive the source file back in MS Word format, in order then to make 
annotations 
- to return the annotated translation to the translator for implementation or 
rejection of the proposed changes
- to receive the final file in Word format AND a TM in a format that can be 
imported into Wordfast

... and the translator wishes to use OpenOffice.org, which is capable of 
reading Word files with revison marks. What is the translator's TM 
application going to to have to do?

Marc




reply via email to

[Prev in Thread] Current Thread [Next in Thread]