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

Luca Ferretti <[email protected]>
Newsgroups gmane.comp.gnome.vfs.general,gmane.comp.gnome.gtk+.devel.general
Message-ID <1199875829.5589.3.camel@redrum>
Il giorno mer, 09/01/2008 alle 10.17 +0100, Alexander Larsson ha
scritto:
> > 
> > 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.

I'll test it.

> > 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?

Good question. I'll test this too.

> > 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?
> 

I'm doing just now: `make distcheck` says it's OK, so I'm going to
commit.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.