Re: [libreoffice-l10n] KeyID change across branches for the same string

Hi Ming, *,

On Sat, May 2, 2020 at 4:23 AM Ming H. <2097632994@qq.com> wrote:
> While doing translation for "UI - master" on Weblate today I came across the following string, at 
> the time untranslated, with KeyID BUn8M:
> https://translations.documentfoundation.org/translate/libo_ui-master/sfx2messages/zh_Hans/?checksum=414ab42ae064f7da
> I was surprised that this was never translated for Chinese, so I went back to "UI - 6.4" and 
> found this, with KeyID dPabj:
> https://translations.documentfoundation.org/translate/libo_ui-6-4/sfx2messages/zh_Hans/?checksum=414ab42ae064f7da
>
> In my naked eye, they look the same.  They are also both from the same file 
> (sfx2/uiconfig/ui/licensedialog.ui), and have the same context (licensedialog|label).  So how did 
> they end up with different KeyIDs?

Wow, you have eagle-eye for spotting that - long story short: that was
some error back when the translations were updated against the
templates at some point - the pot files have the same key-id, but that
wasn't carried over to the po files.

> They don't show up in the other's "similar strings" section either, though that's probably 
> expected as that feature may only match strings in the same Weblate project.

Not sure what you mean with "similar strings" section. There's nearby
strings - but that only are strings from the same component that are
just before/after the current string in the po files.
Then there's "Machine translation" with weblate's own translation
memory (with strings that were translated on weblate) and the strings
from the amagama server (listed from "tmserver") as they had been
translated on pootle (the latter obviously doesn't cover any strings
that changed for master/6-4 since the switchover to weblate happened
way before that).
Weblate's translation memory has different layers, personal and the
language one. It is configured to share translations between
components/projects, so it will show/offer entries from other files
and the other branches if they had been translated in weblate.
See for example:
https://translations.documentfoundation.org/translate/libo_ui-master/connectivityregistryflatorgopenofficeofficedataaccess/de/?checksum=e9a36bc3245f66d6#machine
you should see suggestions from "tmserver" (i.e. amagama, having the
old strings as imported from pootle) and suggestions from the shared
weblate translation memory. For that from the same project (in this
case libo_ui-master, but different component) as well as shared one
from different projects (as the strings is very generic it matches in
help and online projects as well)

Weblate's translation memory is also available from the dedicated
"Translation Memory" section (honestly I don't really understand why
there's a distinction between weblate's TM as "Machine translation"
and as "translation memory") for which basically the same applies:
that covers the strings translated while using weblate. So
tmserver/amagama covers the old/existing strings, and weblate TM
covers the new strings.

tldr: machine translation matches should come from all projects and
components, if they don't show up, then either because the string is
relatively new (had not been translated in pootle) and/or because the
string was not translated using weblate/weblate didn't put it in its
translation memory. Taking your example: the string from the master
project shows up as an entry from weblate translation memory for the
6-4 project. It won't show up as entry from the 6-4 project when
viewing the master one, since it has not been translated/added to the
TM of the 6-4 project, but rather was a string that already had a
translation when the file was imported. Or otherwise put: history of
the string is empty/unknown to weblate)

> It would be nice if such problem can be avoided.  I only noticed this because this is an 
> extremely long string.  There are probably many other short ones that fell through the crack and 
> increased work for many translation teams.

Nope, that was the only one, and this specific problem also cannot
happen anymore.

ciao
Christian

-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/l10n/
Privacy Policy: https://www.documentfoundation.org/privacy