Re: strategy for dealing with new gettext po/ChangeLog editing

[Owen Taylor <otaylor redhat com>]

Darin Adler <darin bentspoon com> writes:

> So, what's our strategy for dealing with this new version of gettext?
> I see a few options.
> 
> 	1) ignore the problem; people who don't hack their copy of
> gettext just have to be careful not to check in edited po/ChangeLog
> files
> 	2) update all the autogen scripts in our projects with some
> workaround that undoes the po/ChangeLog hack
> 	3) release a patched gettext for people who want to commit to gnome cvs
> 	4) start checking in gettextize'd code as the gettext
> maintainer suggests (there may be many repercussions to this, for
> example, we'd also have to check in xml-i18n-toolized code, since you
> have to re-gettextize to re-xml-i18n-toolize)
> 
> I am asking here, but I'm not just asking about GTK. Perhaps I should
> be asking on gnome-hackers? I'd like to get this squared away; it's
> the kind of thing that really irritates me.

For GLib and GTK+ we are simply avoiding gettextize entirely. The
intl/ directory is useless for us, so, we:

 - Use glib-gettext.m4 which doesn't build libintl
 - Use a custom version of po/Makefile.in.in which doesn't need
   anything in the intl/ directory.

I tend to think this is the approach we should be taking everywhere -
you can't use the intl/ directory for a library, and I don't
think it makes sense to have gnome-libs compiled without internationalization,
but then have nautilus (or whatever) linking to a static version
of libintl/.

That does require checking in po/Makefile.in.in and po/po2tbl.sed
but nothing else.

Regards,
                                        Owen