<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><a class="moz-txt-link-abbreviated" href="mailto:fin-w@tutanota.com">fin-w@tutanota.com</a> skreiv 25.07.2024
21:36:<br>
</div>
<blockquote type="cite" cite="mid:O2fOGXM--3-9@tutanota.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Right now, I'm interested to change the layout and
formatting of the translation memory view. I'd like to know what
you all think of this as a new layout, where in this example
Cymraeg is the target language (top lines) and English is the
source language:<br>
</div>
<div dir="auto">
<p data-sourcepos="8:1-8:103" dir="auto"><a target="_blank"
class=""
href="https://invent.kde.org/-/project/2339/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png"
rel="noopener noreferrer"
data-canonical-src="/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png"
data-link="true" moz-do-not-send="true"><img
data-testid="js-lazy-loaded-content"
data-sourcepos="8:1-8:103"
src="https://invent.kde.org/-/project/2339/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png"
alt="Screenshot_20240723_004807" class=""
data-canonical-src="/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png"
style="max-width: 100%;" moz-do-not-send="true"></a></p>
</div>
</blockquote>
<p>My initial impression:</p>
<p>I like the bullet view of the metadata. It’s cleaner and easier
to read than the current implementation. (Not important, but
perhaps the ‘Ctrl+2’ text can also be made clickable?)</p>
<p><br>
</p>
<p>I find it confusing that the English text is missing from the
first entry. Since it’s a perfect match, the text is of course not
*needed*, but I think it’s easier to read the list if the original
string is always shown. Then *all* entries will have the same
format, instead of the first one *sometimes* having a different
format.<br>
</p>
<p>BTW, is is possible for the percentage match for a non-perfect
match to be shown as 100% (e.g., for a 99.8% match)? Or are the
percentages always rounded down (or to the nearest number, but
with special handling of values >99% & <100%)?</p>
<p><br>
</p>
<p>For me, having the source string on the first line and the
translation on the second line feels more natural than the other
way around. Perhaps because that’s the way they’re shown in the
*main* view (current string)? And I usually want to look at
‘changes’ done to the English string first (to evaluate if the
translation suggestion is reasonable), so having the source string
first is more useful (at least for me).<br>
</p>
<p><br>
</p>
<p>I’m *not* fond of the colour change. BTW, is this change also
implemented for the ‘Alternate Translations’? It would be
confusing if the colouring was different in the two views.</p>
<p>Here’s how I interpret the colours in the current (old) version
of Lokalize for ‘Alternate Translations’: Red means that text has
been removed and green (or blue) that it has been added (this is
very common in diff tools) from an ‘old’ source string to a ‘new’
version of the string. For example (this is a real example, from
spectacle.po):<br>
</p>
<p>Previous string (‘| msgid’):<br>
Show the window title bar and border when taking a screenshot of a
window.</p>
<p>New string (‘msgid’):<br>
Show the window shadow when taking a screenshot of a window.<br>
<br>
This currently shown like this in Lokalize (I use [] markers in
case HTML colours are not allowed):<br>
Show the window <font color="#1a5fb4">[+shadow+]</font><font
color="#a51d2d">[−title bar and border−]</font> when taking a
screenshot of a window.<br>
</p>
<p>Then it’s easy to see that the the words ‘title bar and border’
have been replaced by ‘shadow’, so I must make the same change in
my translation.</p>
<p>In this case, the change was not actually done by *updating* the
English string (it’s a *new* string, for a *new* feature), but
msgmerge found a string that was *close enough* that it could
*potentially* be an old version of the new/current string.<br>
</p>
<p>Note that this is for the ‘Alternate Translations’ view. But for
the translation memory, the exact same logic should apply.
Lokalize finds some strings (from the current or historical
versions of the same file or from other translation files) that
might be considered the ‘original’ version of the current English
string. And the changes shown there (by the colour diff marking)
should be performed on the translation.</p>
<p><br>
</p>
<p>In your new version, the text colour is white. That’s an
improvement, as black was difficult to read against the dark
colours. I guess you have manually changed the diff (background)
colours in the Lokalize settings to darker versions, to match your
darker theme. However, a better solution might be to use
‘Positive’ and ‘Negative’ colours (the ‘View’ versions, I think)
from the current colour scheme. This defines background and text
colours that should provide good contrast, and also match the rest
of the colours in the UI. Then the Lokalize settings to change the
diff colours can actually be completely removed. (I guess this
option was implemented *before* positive and negative colours were
added to the KDE colour scheme system, or perhaps even inherited
from the old KBabel application?)<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:O2fOGXM--3-9@tutanota.com">
<div dir="auto">You can see below a screenshot of crowdin.com's
translation editor, which lays out translation memory data under
the strings to translate in a similar fashion to what my merge
request is doing:<br>
<div dir="auto"><a target="_blank" class=""
href="https://invent.kde.org/-/project/2339/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png"
rel="noopener noreferrer"
data-canonical-src="/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png"
data-link="true" moz-do-not-send="true"><img
style="max-width: 100%" src="cid:h4m01ctkctl"
moz-do-not-send="true"></a></div>
<div dir="auto"><br>
</div>
</div>
</blockquote>
<p>(This screenshot was not visible in my email application.)<br>
</p>
<br>
<pre class="moz-signature" cols="72">--
Karl Ove Hufthammer</pre>
</body>
</html>