Frame's File Comparison Feature

[Reng, Dr. Winfried]

Hi Steve,

I do not use XML yet. Therefore I may be wrong. Please
correct me, if this is not correct! My understanding is 
this:

o Of course the translation memory system can import
  XML as easily as FrameMaker. Some systems charge
  additionally for a FrameMaker filter. Or XML (depending
  on the EDD/DTT) might need a special definition in the
  translation memory system to identify the part which
  needs to be translated (e.g. attributes).

o When you give XML files to a translation agency, the
  resulting translation memory could be re-used with
  other translation memory systems (via TMX) better
  than when you use FrameMaker files. FrameMaker files
  contains lots of information which is handled differently
  than XML.
  Therefore the number of pretranslated segments and fuzzy-
  matches would increase, _if_ you switch the system.
  (That's just an assumption. This could be wrong.)

o Translation cost saving calculations with XML are mostly 
  based on chunking.
  That means only those chunks are translated which are
  actually changed. As DITA is supposed to split a FrameMaker
  file into more XML files as compared to a regular FM file,
  the files to be translated are smaller. This might save 
  money.
  However, I could also use FrameMaker insets to have
  smaller files.
  Additionally, make sure that you will be notified of
  terminology changes. Such changes must also be done
  in already translated files.

o When you use XML as your primary storage format, infos
  like table column widths or graphics scaling get lost.
  I want to have this information present after translation.
  Therefore I would prefer to use structured FrameMaker and 
  not XML. But that's my oppinion.
  (Possibly FrameMaker does store such information in
  processing instructions. Or someone wrote a plug-in
  for this. I do not know.)

Best regards

Winfried

> -----Original Message-----
> From: Steve Johnson [mailto:chinaski69 at gmail.com] 
> Sent: Thursday, May 06, 2010 4:27 AM
> To: Reng, Dr. Winfried
> Cc: FrameMaker Forum
> Subject: Re: Frame's File Comparison Feature
> 
> Can't translation vendors do memory diffs just as easily on Frame
> files vs. XML files?
> 
> I don't see the advantage there.
> 
> On Wed, May 5, 2010 at 3:04 AM, Reng, Dr. Winfried 
> <wreng at tycoint.com> wrote:
> > Hi,
> >
> >> What you're considering is (or should be) neither necessary
> >> nor desirable. Your translation vendor should be using a
> >> translation memory (and you should request a copy of it,
> >> since you've paid for it, so that you're not locked into this
> >> vendor because it's holding your translation memory hostage).
> >>
> >> When you send an updated set of files for a book that's
> >> already been translated once, the unchanged paragraphs will
> >> match the translation memory. Only the portions that are new
> >> or changed need to be translated.
> >>
> >> If your vendor isn't using translation memory, find a new
> >> one. If it is using translation memory, there's no point in
> >> you trying to dissect files and reassemble them -- you'd gain
> >> nothing and risk all kinds of problems.
> >
> > Of course almost all translation agencies use a translation memory
> > system nowadays.
> >
> > If the vendor uses a translation memory system, such a system can
> > easily check the number of non-translated segments (a segment is a
> > translation unit) and segments which can be pretranslated or
> > translated with the help of fuzzy-matches.
> > However, the vendor will still charge for pretranslated segments.
> > The reason is that often the terminology must be changed with
> > new text. Or references to a previous segment will not be correct
> > any longer, because e.g. you inserted another segment. The reference
> > may still be correct in English but not in a foreign language.
> > The costs per pretranslated segment depend on your vendor, mostly
> > around 25 % of non-translated segments.
> >
> > Best regards
> >
> > Winfried