Re: RFP: externalize *all* locale-specific information

From: Paul Rohr (
Date: Mon Apr 29 2002 - 18:21:17 EDT

  • Next message: Paul Rohr: "Re: RFP: externalize *all* locale-specific information"

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


    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.


    This archive was generated by hypermail 2.1.4 : Mon Apr 29 2002 - 18:22:15 EDT