You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BAJ kindly requested to transform a customer care ticket to a GitHub issue:
Hello,
When the original was initially correctly translated with a terminal \n but in a revision loses that, then the translation needs to be updated accordingly. Just that small reddish square at the end is easily overlooked and then we get errors like these:
po/gmoccapy/tr.po:416: 'msgid' and 'msgstr' entries do not both end with '\n'
po/gmoccapy/tr.po:420: 'msgid' and 'msgstr' entries do not both end with '\n'
po/gmoccapy/tr.po:545: 'msgid' and 'msgstr' entries do not both end with '\n'
po/gmoccapy/tr.po:588: 'msgid' and 'msgstr' entries do not both end with '\n'
This happens more easily and more frequently than one may think. To spot the entry causing the trouble, one needs to check that file and then search for the text in weblate. Could you instead please find these instances and have these forced as fuzzy?
Just a comment since this was not clear to the other admins of our project (LinuxCNC): This error is related but not identical to the "number of lines not matching" check. Also, a different number of lines would be tolerated by gettext, but this one is not.
Many thanks!
The text was updated successfully, but these errors were encountered:
This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger.
In case your question is already answered, making a donation is the right way to say thank you!
BAJ kindly requested to transform a customer care ticket to a GitHub issue:
Hello,
When the original was initially correctly translated with a terminal \n but in a revision loses that, then the translation needs to be updated accordingly. Just that small reddish square at the end is easily overlooked and then we get errors like these:
This happens more easily and more frequently than one may think. To spot the entry causing the trouble, one needs to check that file and then search for the text in weblate. Could you instead please find these instances and have these forced as fuzzy?
Just a comment since this was not clear to the other admins of our project (LinuxCNC): This error is related but not identical to the "number of lines not matching" check. Also, a different number of lines would be tolerated by gettext, but this one is not.
Many thanks!
The text was updated successfully, but these errors were encountered: