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.