Re: l10n/i18n issue in gvfs [and glib]

[Alexander Larsson <alexl redhat com>]

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 "s  *@	$$posrcprefix& \\\\@" < $(srcdir)/$  in	\
> > 		| sed -e '$$s/\\$$//') > $ -t \
> > 
> > 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 $ -t $@ \
 	    && (sed -e '/^#/d' 						\
-		    -e "s/^\[.*\] +//" 					\
+		    -e 's/^\[[^]]*\] *//'				\
 		    -e '/^[ 	]*$$/d' 				\
 		    -e "s  *@	$$posrcprefix& \\\\@" < $(srcdir)/$  in	\
 		| sed -e '$$s/\\$$//') > $ -t \
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
   ])