Localization Testbenches, Part IV (Online Help)
What are you using to test your localized products? If you're handing them to your domestic QA team and expecting that they'll intuitively test them with correct language locale settings, you may be in for an unpleasant surprise.
3) Help files
Your online documentation also deserves some testing. After its contents (usually HTML pages or XML documents) have been translated - in the correct encoding for the target language - the help project will be compiled, in the same way that software applications are compiled. This compilation step needs to account for the correct language, locale and encoding, and this doesn't happen by itself, no matter how lucky you may feel today.
Again, it's important to test the help file in an environment that closely matches your customers' environment. Run your Greek help file on a native Greek operating system. Be sure to test the main window, the contents pane and the index for properly displayed characters. Above all, perform a few searches using native characters in the Find field to ensure that your help file's index was properly created and encoded; if your searches are successful, then your customers' searches will probably be successful as well.
Note: HTML Help under Windows has some idiosyncrasies when it comes to the table of contents (TOC) pane and the main window. Most tools like RoboHelp will properly encode the TOC and main pane content for, say Japanese, when all of the content resides in the same project. However, if you're building your HTML help files with your own tools (e.g., Perl scripts and hh.exe), you may find that encoding sauce for the goose is not encoding sauce for the gander. We've found, for example, that the HTML pages displayed in the main window are happy with UTF-8, whereas the TOC pane won't support UTF-8 but will support Shift-JIS.
3) Help files
Your online documentation also deserves some testing. After its contents (usually HTML pages or XML documents) have been translated - in the correct encoding for the target language - the help project will be compiled, in the same way that software applications are compiled. This compilation step needs to account for the correct language, locale and encoding, and this doesn't happen by itself, no matter how lucky you may feel today.
Again, it's important to test the help file in an environment that closely matches your customers' environment. Run your Greek help file on a native Greek operating system. Be sure to test the main window, the contents pane and the index for properly displayed characters. Above all, perform a few searches using native characters in the Find field to ensure that your help file's index was properly created and encoded; if your searches are successful, then your customers' searches will probably be successful as well.
Note: HTML Help under Windows has some idiosyncrasies when it comes to the table of contents (TOC) pane and the main window. Most tools like RoboHelp will properly encode the TOC and main pane content for, say Japanese, when all of the content resides in the same project. However, if you're building your HTML help files with your own tools (e.g., Perl scripts and hh.exe), you may find that encoding sauce for the goose is not encoding sauce for the gander. We've found, for example, that the HTML pages displayed in the main window are happy with UTF-8, whereas the TOC pane won't support UTF-8 but will support Shift-JIS.
Labels: CHM localization, Localization, RoboHelp localization, translation Robohelp
posted by John White, Localization Guy at
16:38
2 Comments:
Your note at the end of this post caught my attention because I'm having trouble with RoboHelp 6.0's TOC, index, and glossary, which are not UTF-8 encoded. There is one XML file (wfres.xml) that is UTF-8 encoded, so Japanese shows up properly in some places. How do you change the encoding of files like the TOC (*.hhc) to UTF-8 or Shift-JIS as you indicated you have done and have RoboHelp recognize the encoding? I have tried a few different things, including a Save As and setting the encoding to UTF-8--no dice. Advice from the guy who has made it work would be great. Thanks!
By
btminson@gmail.com, at 08:04
BT: Actually, I wasn't using Robohelp on this CHM; I was using hhc.exe to compile the CHM with a manufactured .hhp, .hhc and .hhk, each of which I could encode separately. It's a non-RoboHelp project I inherited from a tech writer.
If I were you I would do this on a native Ja system to ensure that RoboHelp is the only variable. If that didn't take care of it, I'd look into the versions of RoboHelp specifically designed for handling Asian chars. (I've always thought it daft of eHelp to segment their products that way, but perhaps life under Adobe/Macromedia will be different.)
By
John White, Localization Guy, at 09:38
Post a Comment
<< Home