Untranslated strings are incorrectly marked as strings with failed checks

Translations
1

I don’t know if this problem appeared after that Translations on supported branches or is this really a platform bug that I haven’t identified or checked on a dedicated GitHub.

Yesterday, I uploaded updated translations using a Gettext PO (.po ) file. And started to check other status like Strings with any failing checks because I could simply did a mistake by introducing dot in the end or other typo, or when there’s no mistakes I’m simply ignore-multiple-capital set to false on my translations.
And what, I noticed that Weblate did not classify all untranslated strings as expected. Some untranslated stings still appeared were listed in Strings with any failing checks and not in Untranslated strings.

Because of this, I had to upload an updated file again (with fully translation) and apply translations to all strings. Existing translations were automatically skipped, so they were not overwritten.

Is this expected situation? Because current state indicates that the translation will simply be incomplete, unless the user performs additional verification via the Weblate interface and uploads changes.

As example, here’s XWiki Platform/xwiki-platform-netflux-api — Ukrainian @ Weblate XWiki.org.

image
image3063×1478 293 KB

P.S. If this post will be read by community users at start of the week or later, you won’t find untranslated lines because I’ll upload translation in few mins. However, you can check the history, and see original lines were added as translations by automatic webhook:github account.

image
image2312×1318 204 KB

2

The issue here, that some process put original language into translation lines, and it creates false check Unchanged translation: Source and translation are identical., ex. I’ve found these changes in Blog translations

3

I’m not 100 % sure but I think I had such an issue in the german translation last week too. But I can’t remember how many strings and what keys were affected. But they were not so many that I did ignore it. I better had complained about it.

4

Date shows that something did it not long ago at least this year.

5

So I think this is related to the handling of the missing translation comment in our translation files.

Basically per our format, when a translation is missing we put in our translation file:

### Missing: mykey=source of the translation

The problem is that the value of the key here, is really the source of the translation, and when we perform the parsing it’s recognized as a translation…

I know that we had some problems earlier this year causing the Missing value to just disappear (only the key was appearing) but I thought it was fixed…

Would be good if you have a very clear list of steps to reproduce the problem here.

6

Thanks for explanation. Regarding steps, I’ll try to share them, if I notice this problem again.