<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div dir="auto">Hi all,<br></div><div dir="auto"><br></div><div dir="auto">Thanks for your feedback Karl. How do you think the new screenshot looks?<br></div><p data-sourcepos="5:1-5:27" dir="auto">Data is now always ordered:<br></p><div dir="auto">1. Source<br></div><div dir="auto">2. Target<br></div><div dir="auto">3. Metadata<br></div><p data-sourcepos="12:1-12:91" dir="auto">Source string is again always present, even on 100% match.<br></p><p data-sourcepos="14:1-14:143" dir="auto">The
source strings are always bold. If the source is a >=95% match with
the current translation source string, the % match metadata is also
bold.<br></p><div dir="auto">Diff colour is back to how it currently is in Lokalize: the colour changes in my merge request have been reverted.<br></div><div dir="auto"><br></div><div dir="auto">I've
made the text colour in the diff switch between white and black,
whatever is calculated to be a better contrast against the background
colour. I can instead try to look into the positive and negative colours
you mention, but it looks like it's a Kirigami feature <a target="_blank" href="https://api.kde.org/frameworks/kirigami/html/classKirigami_1_1Platform_1_1PlatformTheme.html#a41239a560f31c0e8ac309f276d016319" rel="noopener noreferrer">https://api.kde.org/frameworks/kirigami/html/classKirigami_1_1Platform_1_1PlatformTheme.html#a41239a560f31c0e8ac309f276d016319</a> and Lokalize doesn't use Kirigami I don't think, so I'm not yet sure if there's a way to use the colours.<br></div><div dir="auto"><br></div><div dir="auto">I
can confirm that the percentages are rounded down so even 99.99%
renders as 99%. Anything above 99.99% is treated as 100% (the code is
using the numbers 0-10000 instead of decimals, behind the scenes).<br></div><div dir="auto"><br></div><div dir="auto">I
can look into making something clickable, but I don't think the
keyboard shortcut text is big enough to be a button. It's a good idea
though, since currently neither clicking nor double clicking enters the
translation from TM into current translation target text.<br></div><div dir="auto"><br></div><div dir="auto">Two screenshots of the updated TM view:<br></div><div dir="auto"><p dir="auto" data-sourcepos="3:1-3:103"><a data-link="true" data-canonical-src="/uploads/f28e80d1dcca377804d26f6ff0517952/Screenshot_20240726_015539.png" rel="noopener noreferrer" href="https://invent.kde.org/-/project/2339/uploads/f28e80d1dcca377804d26f6ff0517952/Screenshot_20240726_015539.png" class="" target="_blank"><img style="max-width: 100%;" data-canonical-src="/uploads/f28e80d1dcca377804d26f6ff0517952/Screenshot_20240726_015539.png" class="" alt="Screenshot_20240726_015539" src="https://invent.kde.org/-/project/2339/uploads/f28e80d1dcca377804d26f6ff0517952/Screenshot_20240726_015539.png" data-sourcepos="3:1-3:103" data-testid="js-lazy-loaded-content"></a><br></p></div><div dir="auto"><a data-link="true" data-canonical-src="/uploads/0a6c65fe53a8d6e5d08060009a666ae0/Screenshot_20240726_032112.png" rel="noopener noreferrer" href="https://invent.kde.org/-/project/2339/uploads/0a6c65fe53a8d6e5d08060009a666ae0/Screenshot_20240726_032112.png" class="" target="_blank"><img style="max-width: 100%;" data-canonical-src="/uploads/0a6c65fe53a8d6e5d08060009a666ae0/Screenshot_20240726_032112.png" class="" alt="Screenshot_20240726_032112" src="https://invent.kde.org/-/project/2339/uploads/0a6c65fe53a8d6e5d08060009a666ae0/Screenshot_20240726_032112.png" data-sourcepos="4:1-4:103" data-testid="js-lazy-loaded-content"></a><br></div><div dir="auto"><br></div><div dir="auto">Thanks,<br></div><div dir="auto">Finley<br></div><div dir="auto"><br></div><div dir="auto">Jul 25, 2024, 23:22 by karl@huftis.org:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div class=""><a target="_blank" rel="noopener noreferrer" class="" href="mailto:fin-w@tutanota.com">fin-w@tutanota.com</a> skreiv 25.07.2024
21:36:<br></div><blockquote type="cite"><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"><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%;"></a><br></p></div></blockquote><p>My initial impression:<br></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?)<br></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%)?<br></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.<br></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></p><div dir="auto">Previous string (‘| msgid’):<br></div><div dir="auto"> Show the window title bar and border when taking a screenshot of a
window.<br></div><p></p><p></p><div dir="auto">New string (‘msgid’):<br></div><div dir="auto"> Show the window shadow when taking a screenshot of a window.<br></div><div dir="auto"> <br></div><div dir="auto"> This currently shown like this in Lokalize (I use [] markers in
case HTML colours are not allowed):<br></div><div dir="auto"> Show the window <span style="color:#1a5fb4" class="">[+shadow+]</span><span style="color:#a51d2d" class="">[−title bar and border−]</span> when taking a
screenshot of a window.<br></div><p></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.<br></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.<br></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"><div dir="auto"><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><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"><img class="" style="max-width: 100%" src="cid:h4m01ctkctl"></a><br></div><div dir="auto"><br></div></div></blockquote><p>(This screenshot was not visible in my email application.)<br></p><div dir="auto"><br></div><pre class="" cols="72">--
Karl Ove Hufthammer<br></pre></blockquote><div dir="auto"><br></div> </body>
</html>