GNOME Bugzilla – Bug 638860
encoding profiles i18n support
Last modified: 2011-04-09 20:49: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).
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.
apparently locale isn't what I want... /me confused.
Created attachment 178448 [details] [review] some profile loading/saving fixes
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?
> 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.
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.