Fixes and changes to Lokalize, request for feedback

[fin-w at tutanota.com]

Hi all,

Thanks for your feedback Karl. How do you think the new screenshot looks?

Data is now always ordered:

1. Source
2. Target
3. Metadata

Source string is again always present, even on 100% match.


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.

Diff colour is back to how it currently is in Lokalize: the colour changes in my merge request have been reverted.

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 https://api.kde.org/frameworks/kirigami/html/classKirigami_1_1Platform_1_1PlatformTheme.html#a41239a560f31c0e8ac309f276d016319 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.

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

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.

Two screenshots of the updated TM view:
 <https://invent.kde.org/-/project/2339/uploads/f28e80d1dcca377804d26f6ff0517952/Screenshot_20240726_015539.png>

 <https://invent.kde.org/-/project/2339/uploads/0a6c65fe53a8d6e5d08060009a666ae0/Screenshot_20240726_032112.png>


Thanks,
Finley

Jul 25, 2024, 23:22 by karl at huftis.org:

> 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:
>> <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/8c9e5274/attachment-0001.htm>