On Tuesday 12 July 2011 19:46:36 Dan Dennedy wrote: > On Tue, Jul 12, 2011 at 3:12 AM, j-b-m <[email protected]> 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 ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
