Hi, This comes from discussion at: https://invent.kde.org/multimedia/kdenlive/-/commit/54b8afd8e1c208f27267e345c61c89cb7a827629#note_1349712 It seems that strings that contain <![CDATA[ at the beginning are not being shown in their translated form, or at least is the conclusion I've come to. Example of the problem can be seen in the following effects, among many others: TAP Equalizer - effect description, several option names ("Band n Freq") TAP Fractal Doubler - effect description, options numeric fields tooltips. It happens in some video effects also, like: Chroma Hold - effect description*, "Similarity" option tooltip. *the description of this effect doesn't start with <![CDATA[ though.
Looking at the translation file, I now realize that the <![CDATA[..]]> tags are included in the string to be translated. https://invent.kde.org/multimedia/kdenlive/-/blob/master/po/es/kdenlive.po?ref_type=heads#L7643 However, when we try to translate these tags do not appear. This should be stripped from the source string, as it is only used as an xml storage conveninence. I will check if we can update the Messages pipeline to remove the CDATA tags.
ok, that may be it. thanks!
A possibly relevant merge request was started @ https://invent.kde.org/sdk/kde-dev-scripts/-/merge_requests/43
Git commit 02fdbf1848a883fd6f32da4885c5e3aad45af795 by Jean-Baptiste Mardelle. Committed on 25/11/2025 at 04:06. Pushed by mardelle into branch 'release/25.12'. Correctly extract strings with CDATA, now that extractrc supports it M +1 -1 Messages.sh https://invent.kde.org/multimedia/kdenlive/-/commit/02fdbf1848a883fd6f32da4885c5e3aad45af795
Ok, so everything is now in place to remove the CDATA strings from strings to be translated. It means unfortunately that all strings with <![CDATA[ will be changed, but once translated they should now appear correctly Please check and let me know if this solves the problem.
Strings in git master now appear without the CDATA in po files. Could you check if things work as expected once translated? If that works, I will also apply the fix to 25.12 branch
Great, thanks! I'm on a trip right now, on Saturday when I get back home I'll test it. 💪
All seems to be working great, now. Thanks!! 😊
(In reply to Gabriel Gazzán from comment #8) > All seems to be working great, now. > Thanks!! 😊 Closing it as RESOLVED - FIXED
For some reason this one is still present in the 25.12.0 release. (in the last nightly [11757] they show translated, though)
(In reply to Gabriel Gazzán from comment #10) > For some reason this one is still present in the 25.12.0 release. > (in the last nightly [11757] they show translated, though) Gabriel, would you mind clarifying what is still present in latest stable ?
(In reply to luzpaz from comment #11) Hi, just checked on 25.12.1 The originally reported problem is still present. It's fixed in master, though.
(In reply to Gabriel Gazzán from comment #12) > It's fixed in master, though. Thanks Gabriel. Lets close this in that case?
It'd be ok for me. Still, I see it more as a project owner prerogative in this case, because I can't wage if fixing it in the current 25.12 series is a valid target, or just waiting until 26.04 is adequate. 🤷♂️
(In reply to Gabriel Gazzán from comment #14) > It'd be ok for me. > Still, I see it more as a project owner prerogative in this case, because I > can't wage if fixing it in the current 25.12 series is a valid target, or > just waiting until 26.04 is adequate. 🤷♂️ Fair, the problem is bug die of bug rot in this tracker. So perhaps the compromise is to find the commit that fixed it and add it to the bug and then close it. What do you think ?
Yeah, I understand, I have no problem with closing it. (I think the commit that fixed it is the one in Comment 4)
(In reply to Gabriel Gazzán from comment #16) > Yeah, I understand, I have no problem with closing it. > (I think the commit that fixed it is the one in Comment 4) That's the one. I can remember. Closing this bug.