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
