I use Kdenlive 0.9.10 4.14.9 from http://packman.links2linux.de in openSUSE 13.2 After creating project with Title Clips, I saved it and re-opened. After reloading, some Title Clips are not displayed in Project Monitor or after Rendering; it only shows content in Clip Monitor. After editing Title Clips (e.g. changing alignement, X, Y values), It starts to show in Project Monitor, but still not after Rendering to video file. Reproducible: Sometimes
Created attachment 96226 [details] test.kdenlive This test has 5 Title Clips. Third Title Clip not displayed.
It seems, that Kdenlive fails to display Title Clips containing non-ASCII characters.
I just found it reported in another place: https://bugs.kdenlive.org/view.php?id=3441
I just tested Kdenlive 15.12.0 – problem is the same!
Created attachment 96229 [details] testing.tar.gz – scripts for rendering 002 – created with š letter in third slide. 003 – š replaced with s letter in third slide. > diff test_002.sh.mlt test_003.sh.mlt 80c80 < <property name="xmldata"><kdenlivetitle width="1365" duration="125" height="768" LC_NUMERIC="C"> --- > <property name="xmldata"><kdenlivetitle width="1365" duration="125" height="768" out="125" LC_NUMERIC="C"> 86c86,95 < i</property> --- > iskart su > kasdienio > naudojimo > programomis</content> > </item> > <startviewport rect="0,0,1365,768"/> > <endviewport rect="0,0,1365,768"/> > <background color="0,0,0,0"/> > </kdenlivetitle> > </property>
Can you please tell me what is your locale setting ? Just type: locale in a terminal and paste the result here
> locale LANG=lt_LT.UTF-8 LC_CTYPE="lt_LT.UTF-8" LC_NUMERIC="lt_LT.UTF-8" LC_TIME="lt_LT.UTF-8" LC_COLLATE="lt_LT.UTF-8" LC_MONETARY="lt_LT.UTF-8" LC_MESSAGES="lt_LT.UTF-8" LC_PAPER="lt_LT.UTF-8" LC_NAME="lt_LT.UTF-8" LC_ADDRESS="lt_LT.UTF-8" LC_TELEPHONE="lt_LT.UTF-8" LC_MEASUREMENT="lt_LT.UTF-8" LC_IDENTIFICATION="lt_LT.UTF-8" LC_ALL=
The attached test.kdenlive project was created with Kdenlive 0.9.10 and for some reason it has a "C" locale setting when it should be "lt_LT.UTF-8".. that might be the reason. If you start a new project in Kdenlive 15.12.0, and create a new title clip with whatever character you want, can you still reproduce the bug ? If you can, please attach this Kdenlive 15.12 project file here
I tested Kdenlive 15.12 in another system. If I create new project, I can not reproduce bug. And if I open kdenlive project as text file, I see LC_NUMERIC="lt_LT.UTF-8"
But in first system, i I manually change C to lt_LT.UTF-8, and try open in Kdenlive, I get warning: There is a locale conflict on your system. The document uses locale lt_LT.UTF-8 which uses a "," as numeric separator (in system libraries) but Qt expects ".". You might not be able to correctly open the project.
Hm... Workaround for my first system with Kdenlive 0.9.10 is to start program with variable: LC_ALL="lt_LT.UTF-8" kdenlive Then after editing slides, saving them, I can revert document and text will be displayed in Project Monior, even if LC_NUMERIC="C"
P.S. In second system with latest Kdenlive `locale` returns LC_ALL="lt_LT.UTF-8" in one row
As Kdenlive proposes to insert any unicode character in dialog, please ensure fine creation of Title Clips with unicode independent of user locale!
Kdenlive must not use locale, while writing configuration files. Using locale causes problems: see https://bugs.kde.org/show_bug.cgi?id=359016 case – they solved by switching to QString::number
The problem is that Kdenlive project files are not just configuration files. When playing a Kdenlive project file, the xml is directly sent to MLT and passed to the various libraries involved in the process, and these libraries are locale aware. So unfortunately, we cannot simply ignore the user locale.
I don't know about these libraries, but then they must be handled in way, that don't disturb Kdenlive. Even if user use multi-lingual interface, i.e. often switch between locales. Hint: maybe you could provide patches to enhance libraries...
Can you please explain comments 7 and 9? I.e. why LC_ALL is sensitive? Why not only LC_NUMERIC is sensitive?
It is important feature! Please use some workarounds!
Do you understand the implications that Jean-Baptiste, the current main developer, pointed out to you?
Jean-Baptiste just said, that locale can not be ignored. He did not closed bug.
I suggest, Kdenlive could check, 1) if $LC_ALL is empty (as in comment 7), try temporally assign same value as $LC_NUMERIC 2) but never use LC_ALL=C, use LC_ALL=en_US.UTF-8 to keep unicode! But maybe exist better workarounds
The issue is, for example MLT, which is not only the engine inside Kdenlive and other editors, but also the part doing most, if not almost all of the XML serialization and deserialization. So this is at this time an upstream issue which you can discuss with the MLT project.
Hi, As suggested by Wegwerf this is an MLT upstream issue so please report this in MLT's trackers at: https://github.com/mltframework/shotcut Regards