DITA Translation Files
Forum topic: Submitted by Marshall Kult on Wed, 2007-11-14 20:25.
I recently submitted a document for language translations. It is composed of 28 DITA files, (references, tasks, etc.). The LSP commented that it was costly to run 28 individual files agains the translation memory and the expense would be less if a single file were given to them for their process.
Is there a better way to do this?
This is theory...
This is theory, but, I believe it reflects how our translation agency moves our files from DITA topics to something the translators are more familiar with. If you can work with XSL, you can generate a master file for the topics you are sending for translation. Set your output to append the topics in your map or folder together into a single file.
Translation pricing model
This is likely to be an issue for a lot of organizations who are making the transition to topic-oriented authoring, but who are using service bureaus who aren't set up for it.
The per-file cost comes from a per-file tracking model. Each file has to be tracked. If the files are chapters, it's feasible to farm them out one at a time to different translators, and then it makes sense to track them individually.
As you shift to finer granularity, though, you want to find a way to deal with lots of small files so that there is less per-file overhead.
Your service bureau probably already has some common resources in place, such as a centralized vocabulary that they use to serve your account. What is missing is a management paradigm that can handle lots of small files.
One solution would be to implement an end-to-end process that resides in a content management system, including access for both authors and translators.
A second solution is to find a translations vendor who can handle your jobs in a more unitary manner, or at a coarser level of granularity. If their process requires chapters, maybe you can architect the content so that it naturally divides into chapters, plus some shared content that has to be translated centrally. You wouldn't give them fewer files, but you'd give them a few folders of files and ask them to charge by the folder.
A third solution is to give up on having your file structure match the structure of your content. Put all the content that matters into a few huge files and reference those files to assemble your deliverables. That will increase somewhat the time required to process the files, and it will require you to plan who can access the huge files and when, but for small operations, it could work for a while.
Bruce Esrig Information Architect