Fixes and changes to Lokalize, request for feedback

[Karl Ove Hufthammer]

fin-w at tutanota.com skreiv 25.07.2024 21:36:
> 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:
>
> Screenshot_20240723_004807 
> <https://invent.kde.org/-/project/2339/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png>
>
My initial impression:

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?)


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.

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%)?


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).


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.

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):

Previous string (‘| msgid’):
Show the window title bar and border when taking a screenshot of a window.

New string (‘msgid’):
Show the window shadow when taking a screenshot of a window.

This currently shown like this in Lokalize (I use [] markers in case 
HTML colours are not allowed):
Show the window [+shadow+][−title bar and border−] when taking a 
screenshot of a window.

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.

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.

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.


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?)


> 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:
> <https://invent.kde.org/-/project/2339/uploads/a61607f9c078fabdce00e25db9d15125/Screenshot_20240723_004807.png>
>
(This screenshot was not visible in my email application.)


-- 
Karl Ove Hufthammer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20240726/ec91d11d/attachment.htm>