Unfortunately, even after learning how to create in DITA XML, after learning how to create the formatting instructions, after finding a translation agency that treats your new stuff like it deserves, you’re still not done. There is no time for a victory lap. It’s time to compromise your production strategy.
Even more sadly, if you haven’t done the things you should have done continuously throughout the entire process, your exit strategy will be more of an exit disaster. You need to plan and start your production strategy from the beginning.
Plan, plan and then plan some more
Since you are using a Task, Concept, and Reference format, decide in advance which types of topics will be Concept and which will be Reference. This is not always clear or easy to distinguish. Are all your introductory paragraphs a concept theme? What about explanatory sections that don’t have tables or reference type information, are they concept or reference? Go over these details with the whole team beforehand and make sure everyone is on the same page. Don’t assume that everyone thinks the same way. We definitely don’t.
Are the illustrators on board? Have you developed a style for the calls? Have you planned maintenance instructions that are almost entirely illustrations, and how do you make these themes seem consistent with the themes of the text? Are you using a standard resolution or will you need to use conditional text or another DITA device to provide one illustration for PDF output and one for HTML output? Has anyone considered mobile device outlets?
When writing the online help topic for a child window, for example, a window-level help dialog, does it repeat the section of the parent window or create a subset of information? How do you handle the examples? Is someone in charge of reviewing daily production for style consistency? Is that person clear about what the styles should be? Design all of these types of information before starting the project.
Since you’re using theme-based building, you’ll have a lot of files. Have you determined how to keep track of all these files? Do you have a useful file naming convention or are you using a content management system? If you want to reuse a particular file, will you be able to find it? Have you figured out which bits of information, such as notes, cautions, and warnings, will be used repeatedly?
Meet early and often
Most projects that involve more than a single writer have some kind of kickoff meeting to set up tasks and schedules. Add DITA philosophy to this meeting. Make sure everyone understands how DITA works, how to use theme-based authoring, and how to write in a minimalist style. Minimalism is not required for this process, but it is smart. Hold follow-up meetings, perhaps even daily, to make sure everyone is up to speed and sticking to the styles set for each part of the document or UI instructions. Ask the person who is monitoring the styles to mention the problems from the previous day’s outing.
Set realistic and beneficial translation schedules
Establish a translation schedule at the first meeting and update the schedule constantly. This can be the most difficult adjustment for both your group and the translation agency. Translation agencies are used to receiving most files towards the end of the project with corrections and additions in the last two weeks or so.
Remember that one of the reasons you chose theme-based authoring is that you can submit one set of themes for translation while you write the next set. Yes, changes happen during that time, but if you’ve set up a system to manage your themes, you can mark the themes that need to be updated, attach the information for the updates, and continue with the current set of information. This way, you have a constant stream of topics going to the translation agency without having to submit the same topics over and over again. The savings you get with this approach come from all your planning, consistency of style, and only translating most of your themes once and the rest no more than twice.
Plan your ditamaps in advance, but be prepared to change
Ok, so maybe you’re not using ditamaps, but the same idea applies. Get a solid idea of the layout of your files in the TOC of the online help and the TOC of the printed document. If they are the same, that’s fine. However, your online documentation will most likely follow the user interface structure and your printed document will follow a pattern of daily activities. So, if you have your output structure planned out ahead of time, you can start putting topics where they’re going to go as you write them. And when you’re using ditamaps, this is pretty easy.
The result
If you have run all of these preparations, your output is now clean, translated, and in the right place for conversion to html or printing at the end of the project. You just need those last two (or more) topics that are translated and you’re done.
If you haven’t done this planning and preparation, you probably have partially translated theme sets that have been translated multiple times. You have reviewers pointing out that your topics are obviously written by different people. You know you have cautions and warnings somewhere in all of this, but you’re not sure where they are. It has help panes in many different styles. And at worst, even its main themes don’t have a cohesive style.
So with planning, your production strategy is a natural result of your initial vision. Without planning, your exit strategy is complete chaos. This makes it an easy choice. Do your exit planning first.
