Document Localization Process?

[Bill Swallow]

MIF works fine and dandy as well and is a non-binary text format.
Going structured and to XML has its advantages, but if the only
concern is localization and using TM tools, it's a lot easier just to
use MIF than to apply structure and use XML for the sake of TM
effectiveness.

On 11/25/05, David Farbey  wrote:
> One approach to localization problems is to move to an XML-based solution.
> This involves a considerable effort, but in the case of a large volume of
> documentation, such as the 35,000 pages a year and large number of localized
> versions at Mercury mentioned earlier, the eventual savings could be justify
> the costs involved.
>
> As XML files are plain text files rather than compiled files (like .fm or
> .doc), changes to them can be tracked more easily by content management
> systems. XML offers many other advantages for documentation particularly
> when combined with a content management system, but I would imagine that
> this is not the best forum to discuss them.
>
> However, FrameMaker users may like to consider moving to Structured
> FrameMaker as a first step towards an-XML-centric solution.
>
> David Farbey

--
Bill Swallow
HATT List Owner
WWP-Users List Owner
42.8162,-73.7736
http://techcommdood.blogspot.com

I support Char James-Tanny for STC Secretary.

Document Localization Process?

[Lisa M. Bronson]

Hi Sivia,

I am the translation coordinator where I work. Our translation vendor uses
TRADOS to build a translation memory for each language. We version control
at the chapter level, so when we make updates to a manual, I compare each of
the modified chapters (File > Utilities > Compare Documents) to its most
recently translated version. For example, if the current English version is
rev 4, and the most recent translation of that chapter is rev 2, I compare
rev 4 in English to rev 2 in English. I send all of the comparison documents
and summaries to the translator.

The compare documents feature is not perfect. It doesn't seem to compare
text in tables, and many times, it indicates that a graphic has changed, but
I can't see any difference between the graphic that's marked as "inserted"
and the one marked "deleted". Regardless of its quirks, it's still a
beneficial tool! Just last week, this process saved us a good chunk of
money. The translators charge a certain amount (per page or word, I think)
to run documents through the TRADOS translation memory. It turned out that
several of the files had changes that were so minor, it was more efficient
to do the changes manually. If I hadn't done the comparisons, the price
would have been much higher.

I hope this helps.

Warm regards,
Lisa B.



On 11/24/05, Sivia Atar  wrote:
>
>
> I would like to hear how other companies manage the process of localizing
> documentation (workflow, communication, and tools).
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.frameusers.com/pipermail/framers/attachments/20051128/d28f93a7/attachment.html
 

Document Localization Process?

[karyn hunt]

An HTML attachment was scrubbed...
URL: 
http://lists.frameusers.com/pipermail/framers/attachments/20051128/6cfebd43/attachment.html
 

Document Localization Process?

[David Farbey]

One approach to localization problems is to move to an XML-based solution.
This involves a considerable effort, but in the case of a large volume of
documentation, such as the 35,000 pages a year and large number of localized
versions at Mercury mentioned earlier, the eventual savings could be justify
the costs involved.

As XML files are plain text files rather than compiled files (like .fm or
.doc), changes to them can be tracked more easily by content management
systems. XML offers many other advantages for documentation particularly
when combined with a content management system, but I would imagine that
this is not the best forum to discuss them.

However, FrameMaker users may like to consider moving to Structured
FrameMaker as a first step towards an-XML-centric solution.

David Farbey

Document Localization Process?

[Joe Malin]

Hmmm. I'd like to know what the localizers think. Your localization
manager's view isn't shared by most of the localizers and tech writing
firms I know.

I worked for Oracle, which translates much of its documentation from
FrameMaker. They moved to structured FrameMaker, using a variation of
the DocBook DTD as the basis of their EDD. They added some features that
helped localizers detect changed elements. I'm sure that Mercury could
do this as well. You should be able to come up with tools that help you
manage translations even if you stick with unstructured FM.

You may get many responses, but speaking as a former software engineer
AND internationalization engineer AND international product manager AND
technical writer, I'd have to say that the key to any process is senior
management backing. Your senior management has to make the decision that
simultaneous delivery is higher priority than any other issue. Then your
senior management needs to get all the stakeholders in a room to decide
on the compromises that will make that happen.

In the short term, you should go back to your L10N manager and ask him
to ask his localizers what they prefer for a document format. Your
localizers are going to be familiar with a variety of situations, and
since they are the ones who have to do the root work, they need to be
involved.

All major software companies in the US are delivering their major
language sets simultaneously with English.

Joe


TuVox, Inc.


19050 Pruneridge Avenue Suite 150, Cupertino, CA 95014-0715

Joe Malin   
Technical Writer
(408)625.1623   
jmalin at tuvox.com 
www.tuvox.com <http://www.tuvox.com/>   
The views expressed in this document are those of the sender, and do not
necessarily reflect those of TuVox, Inc.





From: framers-bounces+jmalin=tuvox.com at lists.frameusers.com
[mailto:framers-bounces+jmalin=tuvox.com at lists.frameusers.com] On Behalf
Of Sivia Atar
Sent: Thursday, November 24, 2005 12:46 AM
To: 'framers at lists.frameusers.com'
Subject: Document Localization Process?



Hi,



At Mercury we write our source product documentation in
FrameMaker and we produce approximately 35,000 pages of documentation
each year. Most of our documentation is translated into Japanese,
Korean, and Chinese and we're now also starting to translate into some
European languages. Mercury wants to reach the point where it can ship
localized versions of its products at the same time as the English
Versions. 



Our Localization Manager says that his team cannot efficiently
track changes to our FrameMaker files. This results in delays and makes
it difficult to keep translation costs at a reasonable level.



I would like to hear how other companies manage the process of
localizing documentation (workflow, communication, and tools).  



Thanks in advance for any information you can provide.



Sivia Atar, Documentation Infrastructure Leader, 
satar at mercury.com <mailto:satar at mercury.com> 
direct 972.3.539.9288 fax 972.3.553.1617
19 Shabazi Street, Yehud, Israel 56100

MERCURY
Business Technology Optimization
www.mercury.com <http://www.mercury.com> 

  <http://www.mercury.com/signature-promotions/> 





__
This email has been scanned by the MessageLabs Email Security
System.
For more information please visit
http://www.messagelabs.com/email 

__


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.frameusers.com/pipermail/framers/attachments/20051125/e164bbd4/attachment.html
 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 8309 bytes
Desc: image001.gif
Url : 
http://lists.frameusers.com/pipermail/framers/attachments/20051125/e164bbd4/attachment.gif
 

Document Localization Process?

[Sivia Atar]

Hi,



At Mercury we write our source product documentation in FrameMaker and we produce approximately
35,000 pages of documentation each year. Most of our documentation is
translated into Japanese, Korean, and Chinese and we're now also starting to
translate into some European languages. Mercury wants to reach the point where
it can ship localized versions of its products at the same time as the English Versions.




Our Localization Manager says that his team cannot efficiently track changes
to our FrameMaker files. This results in delays and makes it difficult to keep
translation costs at a reasonable level.



I would like to hear how other companies manage the process of localizing
documentation (workflow, communication, and tools). 



Thanks in advance for any information you can provide.



Sivia Atar, Documentation Infrastructure Leader, [EMAIL PROTECTED]
direct 972.3.539.9288fax 972.3.553.1617
19 Shabazi Street, Yehud, Israel56100

MERCURY
Business Technology Optimization
www.mercury.com









__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



___


You are currently subscribed to Framers as [EMAIL PROTECTED]

To unsubscribe send a blank email to 
[EMAIL PROTECTED]
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.

Document Localization Process?

[Sivia Atar]

Hi,



At Mercury we write our source product documentation in FrameMaker and we
produce approximately 35,000 pages of documentation each year. Most of our
documentation is translated into Japanese, Korean, and Chinese and we're now
also starting to translate into some European languages. Mercury wants to
reach the point where it can ship localized versions of its products at the
same time as the English Versions. 



Our Localization Manager says that his team cannot efficiently track changes
to our FrameMaker files. This results in delays and makes it difficult to
keep translation costs at a reasonable level.



I would like to hear how other companies manage the process of localizing
documentation (workflow, communication, and tools).  



Thanks in advance for any information you can provide.



Sivia Atar, Documentation Infrastructure Leader,  
satar at mercury.com
direct 972.3.539.9288 fax 972.3.553.1617
19 Shabazi Street, Yehud, Israel 56100

MERCURY
Business Technology Optimization
  www.mercury.com

   





__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.frameusers.com/pipermail/framers/attachments/20051124/4399b063/attachment.html
 
-- next part --
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 8309 bytes
Desc: not available
Url : 
http://lists.frameusers.com/pipermail/framers/attachments/20051124/4399b063/attachment.gif
 

Document Localization Process?

[John Posada]

> Our Localization Manager says that his team cannot 
> efficiently track changes to our FrameMaker files. 
> This results in delays and makes it difficult to
> keep translation costs at a reasonable level.

Sounds like he wants to use somthing primative, like Word's revision
tracking to keep track of the changes, when when he should be using a
localization application (sich as Trados) made for it. Having done
projects that were translated by companies in that specialty, they
were grateful when I switched my companies from Word to FM.

John Posada
Senior Technical Writer

"The word "genius" isn't applicable 
in football. A genius is a guy like 
Norman Einstein." -
  --Joe Theisman, NFL football 
quarterback & sports analyst.

Some answers: RE: Document Localization Process?

[Diane Gaskill]

Hello Sivia,

Having managed L10N to both Asian and European languages for 10 years, I can
sympathize with your L10N manager. Frame does not offer an in-depth change
tracking facility as Word does, and for his purposes, I think you need more
than just change bars that show only the lines where changes have been made.

To solve  his problem, you need a content management system or at least a
version control system for the FM docs, online help, release notes, etc.
This will allow better trackjing of changes to the docs and help.  A tool
such as MS Visual Source Safe or Rational Clear Case, which may already be
in use at your company by Engineering, allows you to check-in and check out
documents.  If the files are ASCII, these tools can do a diff on the
contents to show what the changes are. Obvioiusly, this does not apply to
the binary FM files, but if you save them to text and do diff on the text
files, you can highlight the actual text changes and provide only the
changed text to the L10n vendor.  This saves considerable time and cost.
Note that your L10N vendor can also do that with the TM.  The only problem
with having the vendor do it is that you have less control and it costs a
lot more.  You can also use Trados to do this, and that actually is probably
the best tool for the jobl but you would have to buy it and learn to use it,
while your company probably alreay has a version contol system in house.

I also understand the needs of your company.  Simultaneous delivery of
localized and source-language documents is desirable, but requires a lot of
advance planning and close cooperation between engineering/development, tech
pubs, and localization.  Localization should begin with the Beta docs and
software, and the L10N vendor should use a TM so that changes can easily be
made.  In addition, Engineering must agree that the scope of any changes
after Beta will not require major changes to the docs and help.  Remember,
L10N is expensive, especially if you are localizing to multiple languages,
and particularly if you are localizing to  Japanese, any scandinavian
language, or any language that uses Cyrillic fonts (Russian, for example)
and similar languages, and possibly cost more if you are starting with
Hebrew.

Your L10N manager may find some useful information in a book called
Localization and Framemaker.  You can find the book on the net at
http://www.bapmf.net/resources/2000_localization_FM/locandfm.pdf.

Hope this helps.

Diane Gaskill



 -Original Message-
From: framers-bounces+dgcaller=earthlink@lists.frameusers.com
[mailto:framers-bounces+dgcaller=earthlink.net at lists.frameusers.com]On
Behalf Of Sivia Atar
Sent: Thursday, November 24, 2005 12:46 AM
To: 'framers at lists.frameusers.com'
Subject: Document Localization Process?


  Hi,



  At Mercury we write our source product documentation in FrameMaker and we
produce approximately 35,000 pages of documentation each year. Most of our
documentation is translated into Japanese, Korean, and Chinese and we're now
also starting to translate into some European languages. Mercury wants to
reach the point where it can ship localized versions of its products at the
same time as the English Versions.



  Our Localization Manager says that his team cannot efficiently track
changes to our FrameMaker files. This results in delays and makes it
difficult to keep translation costs at a reasonable level.



  I would like to hear how other companies manage the process of localizing
documentation (workflow, communication, and tools).



  Thanks in advance for any information you can provide.

  

  Sivia Atar, Documentation Infrastructure Leader, satar at mercury.com
  direct 972.3.539.9288 fax 972.3.553.1617
  19 Shabazi Street, Yehud, Israel 56100


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.frameusers.com/pipermail/framers/attachments/20051124/f17abeaf/attachment.html
 

Document Localization Process?

[Bill Swallow]

> Mercury wants to reach the point where it can ship localized versions of its
> products at the same time as the English Versions.
> Our Localization Manager says that his team cannot efficiently track changes 
> to
> our FrameMaker files. This results in delays and makes it difficult to keep
> translation costs at a reasonable level.

If they have live access to files (using version control?) and they
use translation memory in-house (which you really should be doing),
there's no reason why they can't track changes, stay current, and
translate in parallel with authoring.

--
Bill Swallow
HATT List Owner
WWP-Users List Owner
42.8162,-73.7736
http://techcommdood.blogspot.com

I support Char James-Tanny for STC Secretary.