l10n/i18n issue in gvfs



I've added an initial Italian translation for gvfs on svn (plus some
changes to configure.ac, please check) and I've also updated POTFILES.in
in order to list all files with translatable messages (`intltool-update
-m` is your friend), but now here is a problem.

Running `intltool-update <LANG>` in order to update the .po file, I've
this message:

        ERROR: xgettext failed to generate PO template file because
        there is non-ASCII string marked for translation. Please make
        sure that all strings marked for translation are in uniform
        encoding (say UTF-8), then *prepend* the following line to
        POTFILES.in and rerun intltool-update:
        
                   [encoding: UTF-8]
        
(note: non-ASCII strings should come from hal/*.c)

So I've added the suggested line to POTFILES.in and re-run
`intltool-update <LANG>`. This time no error message. Then I've started
to recompile the code, but this time I've:

        Making all in po
        make[2]: Entering directory `/home/luca/svn/gnome2/gvfs/po'
        Makefile:146: *** target pattern contains no `%'.  Stop.
        make[2]: Leaving directory `/home/luca/svn/gnome2/gvfs/po'
        make[1]: *** [all-recursive] Error 1
        make[1]: Leaving directory `/home/luca/svn/gnome2/gvfs'
        make: *** [all] Error 2
        
It seems that the "[encoding: UTF-8]" line is an intltool only
feature :-(

So we should:
     A. remove all non-ASCII strings from source code to make gettext
        happy, or
     B. intltoolize (i.e. make gvfs depends on intltool) gvfs

IF you choose option B, I can do it; meanwhile, I'll search non-ASCII
strings in sources.

PS about i18n/l10n in gvfs: what about mark for translation messages
from gvfs-<program> programs (and maybe adding some beautiful
explanation about feature and usage) too?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]