> In my experience, if you are going to use outside translators, you should
> always keep your language data in an external file; either one that is
> always referenced by the app, or one that is "imported" into the app once
> and stored with the app. The reason for this is that outside translators (a)
> shouldn't have access to the internal workings of your stacks (which they
> would if you had to set custom properties for each object), and (b) it is
> more likely that something will get missed and you'll have a nightmare of
> finding what didn't get translated.

I would strongly endorse Ken's suggestion. We recently completed an installer stack that displays content and collects user selections in 15 different languages. Relying on external files made it easier for the translators to do their job. While you could probably develop some simplified stacks for translation folks to enter text, MC/Rev is not a word processor. Translators will probably prefer to use word processing apps anyway, and don't even think about trying to enter double byte text (Japanese, Korean, Chinese) directly within MC/Rev.

BTW, this is important: if you plan to display double byte text, there are a number of issues you will contend with.

1) The only way we found to get double byte text to display correctly within MC/Rev is to save the source text on a localized system as simple text from something like WordPad or NotePad. This displays as garbage characters on non localized systems but this is what you want to read into MC/Rev. NEVER allow use of heavy word processors such as MSWord to generate content since these will introduce all kinds of formatting code that is major chore to parse.

2) Currently, double byte text does not automatically wrap within fields. Ideally, source text should be manually wrapped within the source text file to fit the target display space.

3) In our testing (we had to do a lot), we found that to display text correctly in Chinese (Simplified and Traditional) and Korean, the textFont of stack should be set to Arial, while for Japanese the textFont should be set to MS UI Gothic. This may need to be set on a line by line basis within field after the garbage characters have been read in to maintain line integrity.

4) You MUST proof the display on localized systems. The addition of language kits/fonts to English systems is apparently not enough to faithfully reproduce the display of a true localized system. We observed many strange character problems on systems enabled with language kits that weren't present on localized systems.

Hope this saves a few hours of aggravation.

Posted 6/25/2002 by Scott Rossi to the Use-Revolution List   (See the complete post/thread)