Context only changes creating fuzzy strings or how to enable pology sieves scripts

[Andre Heinecke]

Hi,

On Thursday, 25 July 2024 23:03:43 GMT+2 Albert Astals Cid wrote:
> El dijous, 25 de juliol del 2024, a les 22:11:38 (CEST), Andre Heinecke va 
> escriure:
> We can not add automatic unfuzying to strings whose context has changed.
>
> Context is critical for translation (and that's why changing it fuzzies the 
> translation).
> 
> After context changes, you need a human to check the translation is still 
> good.

Sorry i put it wrong, generalizing it as "context changes creating fuzzy 
strings" would mean that I think context has no meaning it all. Which I don't.

> Example:
> 
> string: Archive
> translation to Catalan: Arxiu <-- i.e. "An archive"
> 
> Then we realize everyone is translating it wrong and it doesn't refer to a 
> archive but to the action of archiving so we add context
> 
> string: Archive
> context: Verb, tells the application to Archive the current dataset
> translation to Catalan: Arxiva <-- "Imperative form of the verb 'to 
archive'"

I thought and still think that this could be automated. Meaning the case that 
if there is a string which occurs only in one context. If that context then 
changes from no context to some context it could directly be accepted. 

But as you give in your example there might be cases where a wrong translation 
existed and a thoughtful decision was made to fix this string through a context 
change. In an ideal world I would say only such context changes should happen, 
as translations should be handled carefully and changed as little as possible.

I am currently just bothered by bulk changes like "let us add @action as a 
context to each QAction". Changes like this https://invent.kde.org/pim/
kmail/-/commit/9baca4d559fae327a93f5a28c5fbe143dac72f4d

Which in my opinion create a lot of unnecessary work, with over 70 languages 
we have, there should be a good reason to create work for all of them. And not 
just some sense of completeness to have a context for every string.

My hope was to find a technical solution avoiding a discussion about the pros 
and cons of this, since as usual, facts were already made.

So maybe manually using some script to resolve the bulk changes manually might 
be best here. But then again, while I might do this for german where I can 
check the translations, other language coordinators will then have to learn 
about that issue and handle it. So jeah just letting them hit next and accept 
in lokalize might be the most time effective manner to resolve this. :-(

Best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 5655 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20240726/35f594c4/attachment.sig>