Re: [Mlt-devel] Questions about LC_NUMERIC handling
Brought to you by:
ddennedy,
lilo_booter
From: j-b-m <j-...@us...> - 2011-07-12 18:34:16
|
On Tuesday 12 July 2011 19:46:36 Dan Dennedy wrote: > On Tue, Jul 12, 2011 at 3:12 AM, j-b-m <j-...@us...> wrote: > > Hi. > > > > I am trying to solve the handling of documents created with a different > > locale than the system's current one. > > > > Let's say we have a document created with a french locale, say > > fr_FR.UTF-8 (which has a comma as separator). > > > > When loading that document on a system with english locale, MLT switches > > to the fr_FR locale and then expects all input parameters to be in that > > locale, which is not very handy since our Kdenlive UI will use the > > system locale (that is what the user expects). > > Yes, I know, and I was trying to partially address it. I have a > stashed change that does not use setlocale() and instead uses the new > mlt_properties_set_lcnumeric(). Then, property conversions will use > newer locale-specific strtod_l() and sprintf_l(). The basic use case I > was trying to achieve: use a MLT XML document with one locale as a > clip within a project of a different locale. As an editing project > this design falls short because you would end up having objects with > different locales - inconsistent state. Being able to put the > LC_NUMERIC XML attribute on any element would be ugly and not solve > the problem you mention. > > > That means that when opening a document with a different locale, Kdenlive > > (or any other UI) will have to translate all parameters to that locale > > before passing them to MLT. > > > > When saving the file through the XML consumer, it keeps that original > > french locale, and there seems to be no way to convert an MLT playlist > > from one locale to another - at least in my tests, changing the locale > > of a producer > > I think to do that would require strongly typed properties, which is > not going to happen anytime soon. Properties read from a text file, > command line, or network protocol are all strings and only converted > to numeric on demand - meaning some indeterminate time later or never. > > > did not produce a correct xml output (some parameters kept the old locale > > encoding). > > > > So is this supposed to work like that? Having to do locale conversion for > > all data that is sent to MLT? > > For now and foreseeable future, all we can offer is to let people view > and render a project from an incompatible locale and not edit it (or > simply present a warning saying here be dragons). If I get this change > working, then we can also let people load a project with incompatible > locale as a clip. Ok, making the document read (and render) only seems like a good idea to me, I will make the necessary changes in Kdenlive. We can also try to write some kind of locale translator by parsing the xml in the future... Thanks jb |