[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-i18n-doc
Subject: Re: Quality of Frameworks announcements
From: Dominik Haumann <dhaumann () kde ! org>
Date: 2018-09-16 21:21:12
Message-ID: CALi_srCZngPT3dsumVVQ83N3P5ap_zJuq-CW1ewSpmXs83EP0A () mail ! gmail ! com
[Download RAW message or body]
Hi,
indeed I agree that the log messages should be better. Maybe blogging about
how to write good log messages can already help.
Besides that, there is a simple reason for this kind of messages appeared:
we did big changes by replacing the entire highlighting implementation in
KTextEditor by the KSyntaxHighlighting framework. This is what matters for
the changelog. We even did the entire switch in a branch. But for big
changes there are also regressions. So at the end of the day, we tried to
fix the regressions as fast as possible to get things back to normal. All
these changes are completely irrelevant for the changelog... But it's also
not feasible to always write GIT_SILENT.
Simple solution: if you do not understand an entry, noone will. Leave it
out in your translation.
PS: I don't think that we have a real issue here. After all many changes
still imply that a lot of work has been done (most of the time), so there
is still some information in it.
Greetings
Dominik
David Faure <faure@kde.org> schrieb am So., 16. Sep. 2018, 11:07:
> 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@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
[Attachment #3 (text/html)]
<div dir="auto"><div>Hi,</div><div dir="auto"><br></div><div dir="auto">indeed I \
agree that the log messages should be better. Maybe blogging about how to write good \
log messages can already help.</div><div dir="auto"><br></div><div dir="auto">Besides \
that, there is a simple reason for this kind of messages appeared: we did big changes \
by replacing the entire highlighting implementation in KTextEditor by the \
KSyntaxHighlighting framework. This is what matters for the changelog. We even did \
the entire switch in a branch. But for big changes there are also regressions. So at \
the end of the day, we tried to fix the regressions as fast as possible to get things \
back to normal. All these changes are completely irrelevant for the changelog... But \
it's also not feasible to always write GIT_SILENT.</div><div \
dir="auto"><br></div><div dir="auto">Simple solution: if you do not understand an \
entry, noone will. Leave it out in your translation.</div><div \
dir="auto"><br></div><div dir="auto">PS: I don't think that we have a real issue \
here. After all many changes still imply that a lot of work has been done (most of \
the time), so there is still some information in it.</div><div \
dir="auto"><br></div><div dir="auto">Greetings</div><div dir="auto">Dominik</div><div \
dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr">David Faure \
<<a href="mailto:faure@kde.org">faure@kde.org</a>> schrieb am So., 16. Sep. \
2018, 11:07:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Yuri,<br> <br>
Thanks for bringing this to my attention.<br>
<br>
I generate the KF5 release changelog based on the git commits, with some <br>
automated filtering (to remove most maintenance commits like "fix build", \
"add <br> override", "fix comment", version upgrades etc. etc.) \
and some manual <br> filtering (I go through the list and try to remove both lines \
when a commit <br> was reverted, or when it looks too internal and not interesting \
for readers).<br> As you found out, I didn't do a very good job with the latter \
the last time, <br> because I was in a rush, and because, well, my fellow developers \
don't make <br> that job easy in kirigami, ktexteditor and syntax-highlighting in \
<br> particular...<br>
<br>
On mercredi 12 septembre 2018 00:38:27 CEST Luigi Toscano wrote:<br>
> > no need to new/delete hash on each doHighlight, clearing it is good \
enough<br> <br>
I should have removed this one indeed, internal.<br>
<br>
> > ensure we can handle invalid attribute indices that can happen as left<br>
> > overs after HL switch for a document<br>
<br>
It's as opaque to you as it is to me....<br>
<br>
> > let smart pointer handle deletion of objects, less manual stuff to do<br>
> > remove map to lookup additional hl properties<br>
<br>
Yep, I should have removed these.<br>
<br>
> > KTextEditor uses the KSyntaxHighlighting framework for all<br>
<br>
Oops, that one was a real CHANGELOG entry but only the first line was kept.<br>
<br>
CHANGELOG: KTextEditor uses the KSyntaxHighlighting framework for all<br>
highlighting tasks and not only as XML file providers like before.<br>
<br>
I have now fixed my extraction script to support multiline changelog entries.<br>
<br>
> > use character encodings as provided by the definitions<br>
<br>
I *think* that one is clear. The definitions (for syntax highlighting) can <br>
specify a character encoding, and this is now taken into account.<br>
<br>
> > non-bold text no longer renders with font weight thin but (bug 393861)<br>
<br>
I never remove a line that mentions a bug number (for the benefit of those who <br>
cared about that bug), but yeah I wonder what the "but" is, here...<br>
<br>
> > footer separator line visually lighter<br>
<br>
This was extracted from a longer line, which makes sense to me:<br>
<br>
Printing: Respect footer font, fix footer vertical position, make header/<br>
footer separator line visually lighter<br>
<br>
> > make can break bit more like in word code<br>
<br>
That's not English indeed ;-)<br>
I should have removed it, since I don't know either what was meant.<br>
<br>
> > Merge branch 'master' into syntax-highlighting<br>
<br>
Yep, added to automatic filtering now.<br>
<br>
> > There are also some workflow things (commit -> revert -> commit \
again,<br> <br>
That I'm supposed to remove myself, and usually do, sorry for skipping that <br>
last time when faced with a wall of text for 3 modules.<br>
<br>
> > commit (5.49) -> revert (5.50)).<br>
<br>
That, I have to keep, it affects users.<br>
<br>
> > If announce is some kind of advertisement it can be some kind of<br>
> > meaningful.<br>
> > <br>
> > Is it possible to ask developers/release team/marketing team to give \
us,<br> > > translators, the material that can be retranslated to community on \
the<br> > > quality that KDE deserves?<br>
<br>
I actually wonder if it makes sense to translate the changelog for KF5 <br>
releases. After all, these releases mostly target developers, who will have to <br>
understand English in order to use KF5 anyway.<br>
A KF5 release can contain a bugfix that affects users, but they can learn that <br>
their bug is fixed via bugzilla too -- and well, that's in English too. And <br>
it's not like we list every bugfix in KDE Plasma or Applications release <br>
announcements either.<br>
<br>
It seems to me that we are just creating work for ourselves, but translating a <br>
changelog that really, in the end, only matters to people who understand <br>
English.<br>
<br>
-- <br>
David Faure, <a href="mailto:faure@kde.org" target="_blank" \
rel="noreferrer">faure@kde.org</a>, <a href="http://www.davidfaure.fr" \
rel="noreferrer noreferrer" target="_blank">http://www.davidfaure.fr</a><br> Working \
on KDE Frameworks 5<br> <br>
<br>
<br>
</blockquote></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic