Re: [Mlt-devel] Questions about LC_NUMERIC handling

[Dan D. <da...@de...>]

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.

-- 
+-DRD-+