GNOME Bugzilla – Bug 154054
elementfactory: add support for translated names
Last modified: 2018-11-03 12:12:06 UTC
gnome-volume-control has unlocalized labels with ALSA drivers. To reproduce: 1. Enable alsa driver for the sound. 2. Invoke gnome-volume-control Then several labels are not localized. I could find the labels in alsa module but it is not internationalized. So I hacked the strings and attach the patch.
Created attachment 32068 [details] [review] patch for mixer.c Added the patch for gnome-volume-control.
Created attachment 32069 [details] [review] patch for POTFILES.in Added the patch for potfiles.
No, the patch should be to the gstalsamixer code, not to gnome-volume-control.
I couldn't find the module. # rpm -qa | grep alsa alsa-1.0.3-41.3
gst-plugins/ext/alsa/gstalsamixer.c Have a look at how the ossmixer (gst-plugins/sys/oss/gstossmixer.c) or the sun audio mixer (gst-plugins/sys/sunaudio/gstsunaudiomixer.c) do it, they are i18n'ed just fine.
I understood you mean the similar patch should be applied to gst-plugin not to gnome-volume-control. I'll create the patch again.
That's what I mean. ;). Gnome-volume-control should not be patched. Instead, the alsamixer plugin in gst-plugins should be internationalized. Otherwise, we would end up adding the same code to each app using the GStreamer mixer interface.
Created attachment 32160 [details] [review] patch for gstalsamixer.c, gstalsamixertrack.c and gstosselement.c I created the patches for gst-plugin.
Created attachment 32161 [details] [review] patch for POTFILES.in Attached the patch for POTFILES.in
My second patch is created for gst-plugin not gnome-volume-control. So I transfer the category to gst-plugin.
This looks good, we should probably apply this. The i18n patches for the title field in the element definition are probably a good idea. Thomas, should we do that for all elements?
I applied the track label internationalization patch. I didn't touch the elementfactory information yet. It's not that I don't like it, but I'd like to do it for all elements at once. I'll keep that pending for a while longer.
Should the elementfactory information be internationalized? I mean its not 'user information' in my view. Its meant for developers and it is being used programatically by people to choose which plugins to display/show where etc.
Hi, I'm changing the topic. The patch for elementfactories will not be committed in its current form, since it makes the global registry i18n'ed in one language, which may not be correct. We don't know how to solve it correctly right now, but we are interested in solving it correctly. It *is* end user data, so it should be i18n'ed. (Sorry for the patch spam, it's to make the bugzilla patch tracker happy.)
I attached a snapshot as the expected result. The element name is shown as the tab name of gnome-volume-control. The visibility is high so I hope it will be also fixed in GNOME community. I have integrated my patch into our build since four months and it has been tested by each locale.
Created attachment 36958 [details] snapshot of the patched result. snapshot for gnome-volume-control
Right, the visibility in 2.10 will be less because I've moved soundcard selection from the main window to the menu (where you select the soundcard to be displayed). The problem with an i18n'ed registry, according to some of our core people, is that you get i18n'ed data in a system XML file. This is not wanted for several reasons: * since it's system data, it should be in system (C) locale. * since several users use the same registry and not each user uses the same locale (e.g. one uses C, the other uses nl), you'll get problems on multi-user systems. The correct solution, proposed by some (but very work-intensive), is to i18n the data only when requested by the application. This way, gst-register and kids wouldn't use it, but applications reading the registry or displaying the element directly would.
OK, I see the great evaluation. Please close this. I'll check the elements in 2.10. Could you clarify your last comment. Which gnome-volume-control or gst-register should implement the correct solution?
No need to close this, the bug is still valid. ;). I'm not sure yet how the details will work, we'll figure that out once we do this. I'd suggest to continue shipping your current patch as part of the JDS-shipped GStreamer, until we've got our working solution out there...
Since the registry is now per-user only, I would think putting the i18n'd data into the registry would be fine now. Unless it's being used for some other purpose like identification (which it shouldn't).
Perhaps we should only include information in the registry that applications use to select elements. If an application like gst-editor wants to display a bunch of user-interesting information, it can load the plugin to get that information. It sucks that you'd have to load every plugin to get a giant table of element information, but we'll deal with that issue when it actually comes up. Note, I'm not sure this is feasable with the current ABI. We may guarantee certain element information without the plugin being loaded.
Marking as 0.11. At that point, let's remove all information intended for an end user from the registry, and make it all translated.
elementfactories are in core.
Created attachment 131754 [details] [review] Patch for gst/gstelementfactory.[c|h], gst/gstplugin.[c|h] Reviced the patch to follow the latest.
Created attachment 131755 [details] [review] Patch for gst-plugins-good/sys/oss/gstossaudio.c, gst-plugins-good/sys/oss/gstossmixerelement.c Attached patch for gst-plugins-good to follow the latest. This is an example fix. What do you think?
One comment on the patch. I would sugest to use the qdata api of gobject: once do this: priv_gst_translation_domain = g_quark_from_static_string ("gst::domain"); and then use the quark g_object_get_data ((GObject*)factory, priv_gst_translation_domain);
*** Bug 626526 has been marked as a duplicate of this bug. ***
Don't see why this can't be fixed by just adding API, so removing 0.11 target milestone.
Is anybody going to work on this? Maybe as a first step by making the patch apply against git master again? Stefan?
I might look at this next cycle once my other mystical registry stuff has landed, so let's keep it open for now. I think it's a useful feature, since these names might be exposed in UIs.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/2.