Could I ask for the timeline to fix this issue?

I mean... Could we fix this bug just before the string freeze or it
should be fixed with Feature & API/ABI freeze?

I could help with this bug but after 10th June.

Cheers.

The release team seems to be ok with this; they seem to not consider
it a feature affected by the feature freeze but rather an important
bug fix.

Attaching a patch as a basis for discussion :-)

Created attachment 17068 [details] [review]
i18n thingy to make stuff localised

Wow :)

-          g_warning ("%s: state change in cllback %d %d", 
+          g_warning (_("%s: state change in cllback %d %d"), 

Prolly you could fix that "callback" typo too while at it. ;-)

If you created this patch using a perl/python script, that's pretty
cool.  However, it gets a few things wrong, like this:

@@ -954,8 +958,8 @@
   g_return_val_if_fail (GST_PAD_PARENT (realsink) != NULL, FALSE);
 
   if (!gst_pad_check_schedulers (realsrc, realsink)) {
-    g_warning ("linking pads with different scheds requires "
-               "exactly one decoupled element (queue)");
+    g_warning (_("Linking pads with different scheds requires ")
+               _("exactly one decoupled element (queue)"));
     return FALSE;
   }
 

Anyway, that's mostly irrelevant, since such cases can be easily fixed
by hand.

Actually commenting on the patch -- GST_INFO() and GST_DEBUG() should
not be translated, since it is entirely internal debugging.

Usage of g_print() in gstreamer and plugins is discouraged.  These
should either be changed to GST_DEBUG(), GST_INFO(), or g_warning().

Of course, g_warning() should be translated.

GStreamer has more of a problem with not having _good_ messages,
compared with actually i18ning them.  There's a discussion on the
gstreamer-devel mailing list currently about error reporting.

What should not be translated:
- Debugging messages (GST_DEBUG and GST_INFO)
- Warnings and error messages (g_warning and stuff)

What needs to be translated are:
- The popt stuff for command line arguments
- Description fields (for elements, plugins, signals, ...). These need
to be made user-understandable, too. (I'm thinking about a user of
gst-editor, not my grandma)

This is consistent with glib and gtk.

Where I'm not sure if it should be translated are gst_element_error
messages.
After discussing error messages at GUADEC we decided to change this to
use a GError instead of a string. We only need to define the
categories. Gst-Player should then construct its error messages
depending on the categories and the elements that emitted them (if a
source can't open something it's probably "file not found", if a sink
can't open it, it's "soundcard in use").
The message in gst_element_error should still be a message directed at
the developer, so it doesn't make sense for me to translate it.
However glib and gtk do translate them, so I have no idea what
solution would be right.

> - Description fields (for elements, plugins, signals, ...). These
> need to be made user-understandable, too. (I'm thinking about a
> user of gst-editor, not my grandma)

At the same time, it would be a good idea to create a glossary in the
gstreamer documentation, so that we can consistently use terms in
plugin descriptions, and also have these terms translated consistently.

We need an editor.  :)

Brian (Sun) suggested to use XML-style formatting for these plugin
descriptions. This probably goes a bit too far, but it'd be nice to
unify all that, so we can change this scriptwise.

And well, gst_element_error() can probably be translated, ***but***
before anyone starts doing that, let's first fix the actual error
messages to be somewhat more helpful and descriptive. Most are just
confusing or plain wrong right now.

what about expanding/improving gst-xmlinspect in tools/?

What should it do extra? Do you mean stuff that gst-inspect has, like
properties, signals, etc.?

just run 'gst-xmlinspect mad', it'll dump the same info as gst-inspect
produces, but then as an xml file. What about shipping this output
along with the plugin and with some stylesheets to produce alternative
outputs (text, docbook, ...)? what about (automatically) generating
html from it to put in on the website so that people can look at the
complete plugin specs before downloading it? Looks like that would
satisfy the requirements (and more), the plugins would still be
selfcontained.

This looks more like a documentation issue than a real
technical/functional requirement/problem.

I just added gettext support to HEAD.  Seems to work installed, but
doesn't work uninstalled.  Only gst/gst.c has been gettextized.

I think most stuff is internationalized now.  Individual issues can be
filed as new bugs.