On Sun, 2013-04-07 at 10:13 -0400, Matthias Clasen wrote:
> On Sun, Apr 7, 2013 at 2:57 AM, Tristan Van Berkom
> <trista...@openismus.com> wrote:
> > On Sat, 2013-04-06 at 23:59 -0400, Matthias Clasen wrote:
>
> >
> > I'm afraid that your efforts on writing an intltool-extract
> > replacement are misplaced.
>
> Depends on whether you want your stuff merged or not...
>
> >
> > So I have to reiterate my question: How exactly does intltool make
> > your life difficult maintaining GTK+ ?
> >
> > I don't understand why it causes you problems while every other
> > project containing .ui files get along fine.
>
> I just don't like it, and I don't want stuff that I maintain to depend
> on it. I don't allow myself many unfounded opinions, but this is one
> of them. You'll have to deal with it.
Ok, here's the problem.
intltool (used by hand, by translators) cannot handle the .ui
suffix without the [type gettext/glade] attributes specified
in POTFILES.in.
And GTK+ Makefiles cannot handle the POTFILES.in if the appropriate
attributes are set.
I don't know if you would be happy to tell translators to use
your tool, instead of intltool, in order to update all relevant
translations and merge them into the existing ${LANG}.po files,
but that could be an option (if the program actually did that).
But, as I understand it, a simple escape route would be to
rename all of GTK+'s .ui files to .glade, using the age old
.glade suffix will allow translators to merge translatable
strings into their favorite .po file, without ever needing
the explicit [type gettext/glade] attribute.
Would you be satisfied with this approach, at least until
a day that intltool-merge (used manually by translators)
is able to understand what a .ui file is without the
special attribute ?
Cheers,
-Tristan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
