Re: We need a solution about .po files && UTF-8




Carlos Perelló Marín <carlos@gnome-db.org> writes:

>  El dom, 28-04-2002 a las 16:25, Owen Taylor escribió:
> > 
> > Carlos Perelló Marín <carlos@gnome-db.org> writes:
> > 
> > > An introduction for gnome-hackers readers...
> > > 
> > > 
> > > We have a problem with l10n strings for GNOME 2.0. For all systems with
> > > glibc < 2.2 the autorecode feature of glibc is not available so all .po
> > > files should be encoded as UTF-8. We need mantainers opinion about this
> > > problem because it's a critical bug that needs a fix before GNOME 2.0
> > > release.
> > > 
> > > We have several options:
> > > 
> > > 1.- Store all .po files for GNOME 2.0 at cvs.gnome.org as UTF-8
> > > 2.- Recode all .po files as UTF-8 at distribution time.
> > 
> > GTK+ will continue to use plan 1. here, as it does currently (and GLib
> > will be switched over to do the same whenever I get a bit of time to
> > do it.)
> > 
> > Distributing files that are different than that what is in CVS is
> > (in my opionion) a bad idea ... files in a distributed tarball
> > should either one of:
> 
> 
> It seems that we have an option that solves this issue. cvs contents and
> dist tar.gz will have the same .po files, the recode will be only when
> you generate the .gmo file and this file is not at cvs.gnome.org so the
> problem has gone.
> 
> We only need that everyone that wants to install GNOME 2.0 from sources
> will need gettext >= 0.11 because as cactus has remember me, we can
> modify glib-gettextize to recode directly the .gmo files as UTF8.

GTK+ still supports using non-GNU gettext, so I don't think 
the .gmo files are a sufficient solution. Plus, depending on
files not being regenerated for correct operation...

I suppose we could remove all logic for generating non-UTF-8 pofiles
and disable the generation rules for old gettext and require GNU
gettext so that the distted .gmo files get used, but it all strikes
as pretty error prone.

Regards,
                                        Owen


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]