custompropertysets

[Scott Rossi]

> 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.

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & Design
-----
E: scott at tactilemedia.com
W: http://www.tactilemedia.com