Quality of Frameworks announcements

[David Faure]

Hello Yuri,

Thanks for bringing this to my attention.

I generate the KF5 release changelog based on the git commits, with some 
automated filtering (to remove most maintenance commits like "fix build", "add 
override", "fix comment", version upgrades etc. etc.) and some manual 
filtering (I go through the list and try to remove both lines when a commit 
was reverted, or when it looks too internal and not interesting for readers).
As you found out, I didn't do a very good job with the latter the last time, 
because I was in a rush, and because, well, my fellow developers don't make 
that job easy in kirigami, ktexteditor and syntax-highlighting in 
particular...

On mercredi 12 septembre 2018 00:38:27 CEST Luigi Toscano wrote:
> > no need to new/delete hash on each doHighlight, clearing it is good enough

I should have removed this one indeed, internal.
 
> > ensure we can handle invalid attribute indices that can happen as left
> > overs after HL switch for a document

It's as opaque to you as it is to me....
 
> > let smart pointer handle deletion of objects, less manual stuff to do
> > remove map to lookup additional hl properties

Yep, I should have removed these.

> > KTextEditor uses the KSyntaxHighlighting framework for all

Oops, that one was a real CHANGELOG entry but only the first line was kept.

    CHANGELOG: KTextEditor uses the KSyntaxHighlighting framework for all
    highlighting tasks and not only as XML file providers like before.

I have now fixed my extraction script to support multiline changelog entries.
 
> > use character encodings as provided by the definitions

I *think* that one is clear. The definitions (for syntax highlighting) can 
specify a character encoding, and this is now taken into account.

> > non-bold text no longer renders with font weight thin but (bug 393861)

I never remove a line that mentions a bug number (for the benefit of those who 
cared about that bug), but yeah I wonder what the "but" is, here...

> > footer separator line visually lighter

This was extracted from a longer line, which makes sense to me:

Printing: Respect footer font, fix footer vertical position, make header/
footer separator line visually lighter

> > make can break bit more like in word code

That's not English indeed ;-)
I should have removed it, since I don't know either what was meant.

> > Merge branch 'master' into syntax-highlighting

Yep, added to automatic filtering now.

> > There are also some workflow things (commit -> revert -> commit again,

That I'm supposed to remove myself, and usually do, sorry for skipping that 
last time when faced with a wall of text for 3 modules.

> > commit (5.49) -> revert (5.50)).

That, I have to keep, it affects users.
 
> > If announce is some kind of advertisement it can be some kind of
> > meaningful.
> > 
> > Is it possible to ask developers/release team/marketing team to give us,
> > translators, the material that can be retranslated to community on the
> > quality that KDE deserves?

I actually wonder if it makes sense to translate the changelog for KF5 
releases. After all, these releases mostly target developers, who will have to 
understand English in order to use KF5 anyway.
A KF5 release can contain a bugfix that affects users, but they can learn that 
their bug is fixed via bugzilla too -- and well, that's in English too. And 
it's not like we list every bugfix in KDE Plasma or Applications release 
announcements either.

It seems to me that we are just creating work for ourselves, but translating a 
changelog that really, in the end, only matters to people who understand 
English.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5