Hi Ming, *, On Sat, May 2, 2020 at 4:23 AM Ming H. <2097632...@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+unsubscr...@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
