I'm starting provide i18n/l10n to gvfs programs (gvfs-[cat|copy|
less...]).

Here is the initial work on gvfs-cat. Some comments on changes...

Index: programs/Makefile.am
===================================================================
--- programs/Makefile.am        (revisione 1087)
+++ programs/Makefile.am        (copia locale)
@@ -1,30 +1,31 @@
 NULL =
 
-INCLUDES =                             \
-       -I$(top_srcdir)                 \
-       -I$(top_builddir)               \
-       $(GLIB_CFLAGS)                  \
+INCLUDES =                                     \
+       -I$(top_srcdir)                         \
+       -I$(top_builddir)                       \
+       $(GLIB_CFLAGS)                          \
+       -DGVFS_LOCALEDIR=\""$(localedir)"\"     \
        -DG_DISABLE_DEPRECATED

        Define and use GVFS_LOCALEDIR in order to get translations, of course

Index: programs/gvfs-cat.c
===================================================================
--- programs/gvfs-cat.c (revisione 1087)
+++ programs/gvfs-cat.c (copia locale)
@@ -28,10 +28,14 @@
 #include <errno.h>
 
 #include <glib.h>
+#include <glib/gi18n.h>
 #include <gio/gio.h>
 
+static gchar **locations = NULL;
+
 static GOptionEntry entries[] = 
 {
+       {G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_STRING_ARRAY, &locations, 
"locations", NULL},
        { NULL }
 };
 
        Added a "locations" option entry. Note that gvfs-cat don't use
        any command line option, this is useful below to check if you
        are providing a location to cat an print a warning message.
        
        Note also that, from Glib API refs: "Using G_OPTION_REMAINING
        instead of simply scanning argv for leftover arguments has the
        advantage that GOption takes care of necessary encoding
        conversions for strings or filenames." See below for this too.
        
        I've just a doubt: GOption API provides
        G_OPTION_ARG_STRING_ARRAY and G_OPTION_ARG_FILENAME_ARRAY types.
        Now that GIO is in glib, shouldn't G_OPTION_ARG_FILENAME_ARRAY
        be able to manage URIs?


-  context = g_option_context_new ("- output files at <location>");
+  /* Translators: this message will appear immediately after the */
+  /* usage string - Usage: COMMAND [OPTION]... <THIS_MESSAGE>    */
+  context = g_option_context_new (_("LOCATION... - concatenate LOCATIONS to 
standard output"));
+  
+  /* Translators: this message will appear after the usage string */
+  /* and before the list of options.                              */
+  summary = g_strconcat (_("Concatenate files at locations and print "
+                          "to the standard output. Works just like "
+                          "the traditional cat utility, but using "
+                          "gvfs location instead locale files: for "
+                          "example you can use something like "
+                          "smb://server/resource/file.txt "
+                          "as location to concatenate."),
+                        "\n\n",
+                        _("Note: none of the cat option is supported."),
+                        NULL);
+
+  g_option_context_set_summary (context, summary);

        Changed the usage string to match GNU tools standards and cat(1)
        --help, added a summary explaining more stuff. Please review and
        suggest better phrase (for example is "using gvfs location" a
        proper description? is "concatenate LOCATIONS and print") 


-  
-  if (argc > 1)
+  g_free (summary);
+
+  if (!locations) 
     {
-      int i;
-      
-      for (i = 1; i < argc; i++) {
-       file = g_file_new_for_commandline_arg (argv[i]);
-       cat (file);
-       g_object_unref (file);
-      }
+         g_printerr (_("%s: missing locations"), argv[0]);
+         g_printerr ("\n");
+         g_printerr (_("Try \"%s --help\" for more information."), argv[0]);
+         g_printerr ("\n");
+         return 1;
     }

        Use locations option to check if we have any location to cat.
        
        Of course this breaks the cat(1) behavior, but I think you
        should use cat(1) if you simply need to concatenate stdin to
        stdout...


+  int i = 0;
+
+  do {
+         file = g_file_new_for_commandline_arg (locations[i]);
+         cat (file);
+         g_object_unref (file);
+  } while (locations[++i]!=NULL) ;
+
   return 0;
 }

        Also use the locations option to pass URI to cat; changed the
        previous `for` with a `do..while`
        
        

A final note about error messages: currently gvfs-cat prints something
like:

        $ gvfs-cat smb://server/file.txt
        Error opening file: No such file or directory
        
IMHO could be better prepend the program name and the file name (this is
the behavior of plain cat(1)) 

        $ gvfs-cat smb://server/file.txt
        gvfs-cat: smb://server/file.txt: No such file or directory

PS of course could be interesting add some cat(1) options, such as -n
(number all output lines), -E (display $ at end of each line), -T
(display TAB characters as ^I) and -s (never more than one single blank
line). OK to open a bug and add commented GOptionExtry copying switch
and comments from `cat --help`?

PPS the Italian translation is updated in attached patch, so you can run
`LANG=it LANGUAGE=it gvfs-cat --help` and see the message translated.

Attachment: gvfs-cat-i18n.diff.gz
Description: GNU Zip compressed data

_______________________________________________
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list

Reply via email to