[Top][All Lists]
[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