On 7 April 2013 07:57, Tristan Van Berkom <trista...@openismus.com> wrote: > So I have to reiterate my question: How exactly does intltool make > your life difficult maintaining GTK+ ?
I cannot answer for Matthias, but he and I share the same dislike for intltool. intltool is a collection of weird Perl madness that tries to interpret the file formats it parses to remove arbitrary synta extensions to mark strings as translatable ones; it has an inherent cost in terms of maintainership in the form of set up and build-time impact; bit rot of m4 macros and build environment files; and a general opaqueness of the overall thing. intltool also has an history of breakage without previous notification, with repercussions on the entire GNOME stack; and it's not heavily maintained. when it works, it's *almost* opaque enough that you forget that it's there and what it does; when it breaks, it breaks so utterly and so badly that entire releases can be postponed while trying to disentangle the mess. the entire functionality of intltool should be folded into gettext; as much as I personally find gettext already a mess, having two separate tools requiring to be combined to do an half-assed job at marking strings for extraction into localization catalogues is just tempting fate with a volatile, bi-component explosive mix. while I may subject myself to the pain of using intltool for the couple of applications that I occasionally release, I don't want to do that for libraries or large projects, so I completely understand and agree with Matthias: distchecking glib and gtk+ for release is already painful as it is, throwing another variable into the mix is nothing but cause for pain. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list