Ken Ray kray at
Tue Jun 25 18:45:01 EDT 2002


Those are very important insights on developing for multiple languages; I
have never developed for double-byte languages, so I'm glad someone else has
already gone down that road... :-)

In any event, I put this tip on my site for later reference:

(Click on link "lang001" under Localization/Languages.)

Ken Ray
Sons of Thunder Software
Email: kray at
Web Site:

----- Original Message -----
From: "Scott Rossi" <scott at>
To: <use-revolution at>
Sent: Tuesday, June 25, 2002 4:36 PM
Subject: Re: custompropertysets

> > In my experience, if you are going to use outside translators, you
> > 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
> > and stored with the app. The reason for this is that outside translators
> > shouldn't have access to the internal workings of your stacks (which
> > would if you had to set custom properties for each object), and (b) it
> > more likely that something will get missed and you'll have a nightmare
> > 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
> 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
> number of issues you will contend with.
> 1) The only way we found to get double byte text to display correctly
> MC/Rev is to save the source text on a localized system as simple text
> 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.
> allow use of heavy word processors such as MSWord to generate content
> 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
> 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
> 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
> W:
> _______________________________________________
> use-revolution mailing list
> use-revolution at

More information about the use-livecode mailing list