| Summary: | Some effects/composite descriptions, option names and option tooltips show always in English. | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | Gabriel Gazzán <gabcorreo> |
| Component: | Translation | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | berndmj, luzpaz |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Gabriel Gazzán
2025-11-19 22:17:23 UTC
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. |