Subject: language packs (was Re: POW -- which locales Just Work?)
From: Paul Rohr (paul@abisource.com)
Date: Mon Mar 05 2001 - 15:15:56 CST
At 01:39 PM 3/3/01 +0100, Karl Ove Hufthammer wrote:
>> >I think that should work. It's pretty obvious what you should do when
you're
>> >presented with a list of languages anyway (choose the one you prefer).
>>
>> Cool. So could we assume that we could get away with two or three
pieces of
>> unlocalized text in this "locale bootstrap" dialog?
>>
>> - a "Select language:" prompt at the top,
>> - perhaps an optional "More" button next to it, and
>
>If this has the text 'More >>' (note the '>>'), I guess most people will
>understand what it's for.
Good.
>> So far, we only have one locale-specific resource -- the strings file.
>
>And the help files, of course.
Oops. I forgot about those. Sorry. They happened during twin-time, right?
>> For
>> packaging purposes, I'd prefer to minimize the number of locale-specific
>> bits & pieces. And in any event, all modern OSes tend to include fairly
>> complete locale services, so we shouldn't have to do much to augment them.
>
>I guess you're right.
>
>BTW, some day (~AbiWord 2.0?) we'll need to package each localization into
>separate downloadable language packs. Having each localization embedded in
the
>program will take up way to much space (for comparison, the text of one
>localization of MS Word takes up ~1.5 MB -- we have 25 working
localizations).
I'm curious -- how much *do* the various localizations bloat the current
binaries? It'd be interesting to see just how much slimmer an en-US-only
binary would be on each of our platforms. (Slimming down libiconv would be
another option, but let's not go there.)
If we're going to deal with this, then that sounds like the right timeframe.
To de-bloat, we'd need to unbundle the toolbar and menu localizations, some
of which share the same localized toolbar art. This might involve some
clever applications of the (currently unused, AFAIK) XAP_Module code. We
certainly shouldn't hack this, though -- the potential versioning issues
could be a nightmare if we don't get the resource-discovery APIs right the
first time.
Also, while we're on the subject, it sure would be nice if we could ensure
that any such language packs were *entirely* platform-neutral. The
packaging issues for building N >> 25 distributables are bad enough --
multiplying that by the number of supported platforms is a nightmare we
don't need. Off the cuff, it's not clear how much work that'd take though.
Fortunately, we don't need to solve that problem now. :-)
Paul
This archive was generated by hypermail 2b25 : Mon Mar 05 2001 - 19:24:29 CST