wcgrep "\[" src/data/kateschemarc src/data/kateschemarc:2:[Normal] src/data/kateschemarc:34:[Printing] src/data/kateschemarc:66:[KDE] src/data/kateschemarc:70:[Breeze Dark] src/data/kateschemarc:102:[Solarized (light)] src/data/kateschemarc:134:[Solarized (dark)] src/data/kateschemarc:165:[Vim (dark)]
These strings are displayed in the menu View->Schema and on the Fonts & Colors page in Kate's settings dialog. It is not possible for Scripty to extract those strings via an ExtraDesktop.sh file, because Scripty needs a Name= key to work.
But is this something we really want to translate? These are all proper nouns, are they not?
This should certainly be fixed and is a shortcoming of the current implementation. There is hope, though: Recently, KTextEditor internally switched to the KSyntaxHighlighting framework for highlighting. This is a gradual process though, meaning that it does not yet use the Theme class from the KSyntaxHighlighting framework. Instead, KTextEditor still uses the "Schema" classes that are around in ktexteditor.git. The good news: Once we push more to this, we will only use the colors that are provided by the KSyntaxHighlighting::Theme class. At that point in time, we of course also use the names of the Themes, and Theme has ::name() and ::translatedName(), see: https://api.kde.org/frameworks/syntax-highlighting/html/classKSyntaxHighlighting_1_1Theme.html#aaead19e67bdc6ce6e45e195f51317d36 Therefore: In KSyntaxHighlighting this is fixed. And once we move over to KSyntaxHighlighting for Themes fully, the file 'kateschemarc' will be fully dropped. And then, this will be fixed automatically. If you have a simple fix for KTextEditor today, then it's ok to fix this. But if not, then this gets resolved automatically later. (Whatever 'later' means...)
I think this is done now. That file is gone and we use the KSyntaxHighlighting translated names.