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. -- +-DRD-+ ------------------------------------------------------------------------------ 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
