On Fri, 14 Jul 2000, Ayers, Mike wrote:
> Thanks. Storing the bitmaps of the entire string might be better
> for a very small number of display strings. My solution was designed for an
> intermediate number of strings where memory would be saved by encding
> multiply-used characters one time each.
Like everythink in I18N, the solution selected "depends" on the situation,
requirements, and so on. RLE is good for some situations (and lousy for
others). Selected bitmaps work sometimes (and not for others). Rebuilding
the device is sometimes an option (and usually isn't).
>
> > 2. I had a printout of Shift-JIS I kept in a drawer with
> > highlighter on it
> > to show what characters we had bitmaps of. The translators never knew
> > which code points they'd assigned: we had to track it all
> > after the fact.
>
> That's bad project management, to be blunt.
Easy for you to say ;-). Actually, the changes were usually minor and the
terminology (glossary) prevented much drift in terms of total characters
mapped... and we could try to limit the translators to what was
mapped. But it is difficult to be absolutely rigorous about it: do you
want a good translation?
>I made a few
> assumptions about a "memory constrained device" - one of those assumptions
> was that it would probably be PROM based, and therefore all of the software
> would be swapped on an upgrade. Then you would only need to keep track of
> the characters you were using for each individual software version. If the
> bitmap array and display strings were to be amanaged independently, I agree
> that this would not be a good way to go.
PROM or no PROM, you still have to keep track of which ones you have and
which ones you don't. Yuck.
> Let's not propose one-size-fits-all solutions. If Michael i porting
> an English app to Japanese and "limited memory" tramslates to "let's cram
> Japanese into the same footprint as English", then I agree with you. If,
> however, he is designing a small footprint, Japanese only, imminent
> obsolosence device (think pagers), then I would tend to disagree.
>
There are no "one-size-fits-all" solutions. However, it is usually a
mistake to generate a one-off single-language version of anything. These
things take root and prevent REAL internationalization later. (The
programmers just say: "you did it somehow last time"). It is *always* (at
the risk of using another absolute) better to consider the global
requirements at original design time and come up with the best solution
then, rather than trying to shoehorn some Japanese into a device never
designed with it in mind.
Actually, we're off making wild assumptions about the nature of Michael's
problems with no data to work with...
Best Regards,
Addison
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:05 EDT