On Tue, 2008-01-08 at 18:19 +0100, Luca Ferretti wrote:
> Il giorno mar, 08/01/2008 alle 09.12 +0100, Alexander Larsson ha
> scritto:
> > I tried to understand it before, but i just couldn't. There is this sed
> > call in the Makefile:
> > && (sed -e '/^#/d' \
> > -e "s/^\[.*\] +//" \
> > -e '/^[ ]*$$/d' \
> > -e "[EMAIL PROTECTED]@ $$posrcprefix& \\\\@" <
> > $(srcdir)/[EMAIL PROTECTED] \
> > | sed -e '$$s/\\$$//') > [EMAIL PROTECTED] \
> >
> > The way I read it that should strip out the [] part. But it just doesn't
> > seem to work, and I was unable to figure out why.
>
>
> I've a working solution, but I'm sure it's correct or the best one.
>
> The idea is: if the sed rule is able to remove comment lines (^#), then
> use a similar rule to remove the line with "[encoding: UTF-8]".
>
> The fix (attached as patch) should be applied to _glib_ and is a simple:
> - -e "s/^\[.*\] +//" \
> + -e "/^\[.*\]/d" \
I don't think that is quite right. A better rule is probably :
's/^\[[^]]*\] *//' as that strips any trailing newlines.
Full patch attached.
> Now, applying this patch to glib, reverting changes in gvfs (re-add call
> to glib-gettextize in autogen.sh, delete mkinstalldirs and
> po/Makefile.in.in from svn), everything works file: you can delete and
> recreate a working POTFILES and you can run intltool-update <LANG> with
> no errors.
But does the --from-code=UTF-8 thing get added to the xgettext call?
> This is no more than a solution I found changing sed rules and checking
> results: but I think the issue is related to rules currently available
> in glib: we are seeing it in gvf 'cause it's the only GNOME module not
> using intltool but providing UTF-8 strings.
>
> I suggest contact glib developers (alex?), check sed rules. maybe
> verifying the intltool behavior, fix the rule used to remove "[encoding:
> UTF-8]" and release a new glib (stable and devel) version.
I'm not an expert on this gettext stuff, so I'm not sure if this is
right. CC:in gtk-devel list for input.
> Waiting for this release, OK to use intltool in gvf? Just as workaround
> solution: gvfs don't need intltool 'cause all translations come from
> plain C source files (no .desktop, no .schemas, no .glade...)
Yeah. Can you hack that up?
Index: po/Makefile.in.in
===================================================================
--- po/Makefile.in.in (revision 6280)
+++ po/Makefile.in.in (working copy)
@@ -254,7 +254,7 @@
fi; \
rm -f [EMAIL PROTECTED] $@ \
&& (sed -e '/^#/d' \
- -e "s/^\[.*\] +//" \
+ -e 's/^\[[^]]*\] *//' \
-e '/^[ ]*$$/d' \
-e "[EMAIL PROTECTED]@ $$posrcprefix& \\\\@" < $(srcdir)/[EMAIL PROTECTED] \
| sed -e '$$s/\\$$//') > [EMAIL PROTECTED] \
Index: m4macros/glib-gettext.m4
===================================================================
--- m4macros/glib-gettext.m4 (revision 6280)
+++ m4macros/glib-gettext.m4 (working copy)
@@ -379,7 +379,7 @@
posrcprefix="../"
fi
rm -f po/POTFILES
- sed -e "/^#/d" -e "/^\$/d" -e "s,.*, $posrcprefix& \\\\," -e "\$s/\(.*\) \\\\/\1/" \
+ sed -e "/^#/d" -e "s/^\[[^@:>@]*\] *//" -e "/^\$/d" -e "s,.*, $posrcprefix& \\\\," -e "\$s/\(.*\) \\\\/\1/" \
< $srcdir/po/POTFILES.in > po/POTFILES
])
_______________________________________________
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
