1 person found this helpful
First of all, I am in awe that you knew this day would come and set up your project accordingly. The hard work of getting help ready for localization is retrofitting the structure - you're already structured correctly (except for the snippets, which I'll get to).
Second, thanks for the link to the article, because it already has the most important process in it (and it says it better than I can). Communicate with your translators! If you all work for the same company, you can probably set up online meetings where you can walk with them through the help files, pointing out the things that should not change.
Third, except for the sheer bloody number of languages, you're in better shape than some RH writers, because you have kept the crucial checking and generating steps in your own hands. That's a lot of work for you, but if you can handle it, there's a real benefit to centralizing the help build process.
About your questions:
1. To control what your translators do to your tags, find out what they are using to edit the HTML. If they are using Word to edit your source files, either quit or get them the open source editor Notepad++ (http://notepad-plus.sourceforge.net/). It's free and it displays the visible text and the HTML tags in different colors - a good way to help make sure that the visible text is the only thing being edited. (Of course, this doesn't help if you have /DIVs for drop-down/expanding hotspots, but nothing's bulletproof.)
2. There isn't a clearly drawn line in the sand about the number and size of snippets in a project. I think I'd feel safer splitting the languages out and handing off the snippet files in each language for translation (again, using Notepad++, or real Notepad, or any text editor). I would keep the snippet filenames the same between languages/projects, just like the topic filenames.
3. Updates - here's where it gets really hairy. If your total help project is small and doesn't include a lot of pop-up topics off image maps, you can generate Word documents of the old and new help files (in English) and then use File Compare to show the changes. If your company has Word already, this is cheap and relatively painless. If your project is large and/or complex, you are going to have to keep really good records of your changes to the English project - at a minimum, a list of every topic file you add, delete, or change - to hand off to the translators. This is what I have done in the past (thank heavens, I'm not working on a localized project at present).
4. Updates 2 - start lining up your proofreaders now. Bribe them, if necessary. You are going to need to check that every file you changed was at least touched by the translators.
And one final thing - all of the above assumes that the languages you are translating into are more or less European. Right-to-left (Arabic, Hebrew) and double-byte (most Asian) languages have their own issues. I'm sure you know that, and the HTML gurus in the RoboHelp community have come up with some clever workaround for this content, so don't despair.
Sorry to go on so long, but localization has been an issue of interest for me for a long time. Good luck!
Thank you for your lengthy reply =) I'll make good use of all your advice.
There is one point I'm confused about, though: the snippets. If I understood rightly, you are saying I should have 1 snippet file for each language, all with the same name. This implies storing each snippet file in the directory for the relevant language. But then I can't find how to store them elsewhere than in the root folder of the project. There is nothing in the help about that. (They mention the Resource Manager, but if you insert a snippet that is inside the Resource Manager into a topic, RoboHelp copies the snippet file to the root folder.)
Well, I am afraid I cannot help you with the snippets issue as I don't use them in my projects. About the translation issue, the best solution is to get the translators to use Trados (or a similar translation software) to translate the htm files. Trados can tell between code and text and translators will not have to worry about conditional text. Besides, it is the best option in order to track changes in future versions of the project. You will just have to send them the new version of the htm files and Trados will tell the translator what is new and should be translated.
If they cannot use Trados, I would try using a "wysiwyg" editor, rather than notepad, as long as you can handle the conditional text with that. I would try and see if it works well with conditional text as well as with styles before going for the notepad solution. However, even if it respects conditional text code and styles, these kinds of editors will force you to tell the translators what exactly they will have to translate when there is a new updated version of your project. If there is no other solution, what I would do is to create a Word document including the changes you have made to each topic, and send it to the translators. Then when they send that document back to you, it will be your task to make those changes to each of the htm files in your project manually. Of course, to do this in 20 languages can be a tiresome task, specially if changes are many. However, if Trados or a similar translation software is not used, I cannot think of other way of doing this.
Once you have the right version of your translated htm files, you just need to make a copy of your project in english, rename the project accordingly (do it through the File menu in RH) and replace the htm files with the translated version (also the hhc -TOC- file and the hhk -Index- if needed). I would also advice you to use numbers to name your htm files, rather than words. That way, the htm file names will be the same in all languages and it willl be easier for developers to call your topic files in the different languages.