After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638860 - encoding profiles i18n support
encoding profiles i18n support
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2011-01-06 20:25 UTC by Tim-Philipp Müller
Modified: 2011-04-09 20:49 UTC
See Also:
GNOME target: ---
GNOME version: ---

some profile loading/saving fixes (3.37 KB, patch)
2011-01-16 17:00 UTC, Tim-Philipp Müller
committed Details | Review

Description Tim-Philipp Müller 2011-01-06 20:25:53 UTC
It just occured to me that encoding profiles and encoding targets contain user-facing description strings, but we haven't really thought about i18n support as far as I can tell.

I believe what's required is basically:

 - pass translation_domain string arguments with
   every description in some way (e.g. add a new
   argument which can be NULL or a _full() function
   or a separate setter func)

 - save/load the translation domain along with
   the description

 - add function to return a translated description for
   our pre-defined encoding categories? (here things
   get messy because it's not clear how to deal with
   user-defined categories then, though maybe that's
   not so important).
Comment 1 Edward Hervey 2011-01-07 10:07:16 UTC
There actually is locale support for targets, but not for profiles. That being said, it's not really well detailed.

I'll extend the docs to explain current behaviour and add {set|get}_description_locale variants where one can specify the locale.
Comment 2 Edward Hervey 2011-01-07 10:35:59 UTC
apparently locale isn't what I want... /me confused.
Comment 3 Tim-Philipp Müller 2011-01-16 17:00:56 UTC
Created attachment 178448 [details] [review]
some profile loading/saving fixes
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2011-01-18 08:27:09 UTC
Review of attachment 178448 [details] [review]:

::: gst-libs/gst/pbutils/encoding-target.c
@@ +412,3 @@
+static gchar *
+get_locale (void)

what about making the return a const gchar* and only determining it on the first invocation (turning the "gchar *ret" below into static gchar *ret=NULL?
Comment 5 Tim-Philipp Müller 2011-01-18 08:45:04 UTC
> what about making the return a const gchar* and only determining it on the
> first invocation (turning the "gchar *ret" below into static gchar *ret=NULL?

Thought about that, but depending on the use case the app might need to do a setlocale() before calling save_to_file() if it wants the description saved as the to-be-translated name rather than as desc[xy]. So it seemed more flexible this way, but we can still change it in future. It's not like this is particularly performance sensitive.
Comment 6 Tim-Philipp Müller 2011-04-09 20:49:53 UTC
Going to WONTFIX this. I think the implicitness makes it all a bit screwy, but it should work fine for the main use cases, which are:

 1. app creates profiles, strings+translations come from app

 2. ready-made profile files from some profile repository,
     strings + translations come from the profile file

A case that doesn't work well is e.g. creating a profile file/template for distribution from an app running in a non-C/en locale (afaict you can't easily write out strings to be translated in English then, nor could you write out the translations if they're available already application-side).

If someone ever needs this, they'll likely ask for new API.