From: Paul Rohr (paul@abisource.com)
Date: Mon Apr 29 2002 - 18:21:17 EDT
At 11:46 PM 4/29/02 +0200, Christian Biesinger wrote:
>On Mon, Apr 29, 2002 at 02:36:37PM -0700, Paul Rohr wrote:
>> Ideally, we'd ship a hardwired en-US (yes, I'm a chauvinist, sorry) binary
>> which could be easily packaged up with a collection of zero or more
>> locale-specific resources.
>[...]
>> To be clear. AFAICT switching to gettext does nothing to advance this
goal.
>> It merely switches the mechanism we use for the strings we've managed to
>> externalize so far.
>
>No, gettext can be used _exactly_ for that.
>1) With gettext, the en-US translation is always built in (well, needs not
>be en-US, but usually is)
>2) on startup of a gettextized app, gettext is initialized with the
>language from an environment variable (note that I don't know how this is
>done on windows - ie. maybe another approach is used there for apps like
>the gimp). If a translation is available (this is determined by checking
>if the .mo file (compiled .po) exists in the correct directory), it is
>used, else english is used.
>
>So this is exactly what you want - or?
Sorry. I guess my original post wasn't clear enough. My claim is that, as
far as AbiWord is concerned, the following should be functionally equivalent:
fr-FR.strings
fr-FR.mo
Switching resource formats doesn't gain us anything at runtime (and
shouldn't lose anything either). No better, no worse. It should should
help *translators*, though, or it's not worth doing at all.
That's what I meant about "switching the mechanism".
The main point of my post was in section #3. For valid historical reasons,
there are *other* locale-specific resources still embedded inside AbiWord.
We need good ways to move those out of the binary, too.
It's always been easier for me to envision moving *that* information out by
augmenting an XML file. AFAICT, gettext doesn't move us any closer to
solving that problem.
Paul
This archive was generated by hypermail 2.1.4 : Mon Apr 29 2002 - 18:22:15 EDT