Placeholders on Translations

I just want to share this script which checks the placeholders of the translations.

You can use it placing in your tryton repo clone base path and run with:
python -langs es,fr,de

You will be prompted with:

msgctxt: model:ir.message,text:msg_mygls_api_error ./modules/stock_package_shipping_mygls/locale/fr.po
msgid placeholders: {'message'}
msgstr placeholders: {'messages'}

So if you check that translation, the original is:

MyGLS API call failed with the following error message: %(message)s

and the translation is the following (check the extra s of messages):

L’appel de l’API MyGLS a échoué avec le message d’erreur suivant : %(messages)s

I just run and correct in Weblate all the strings for the languages with more than 90% of completion (es, fr, ca, nl, de), feel free to run the script in your language and make the suggestions.

If this could be somehow incorporated in Tryton as some internal test, I would be willing to contribute. But I don’t know where to contribute, should be a tool on the export translation wizard? Should be a test that run in the heptapod? Should be something on trytond-admin?


Wondering if this is more useful to be incorporated in Weblate directly. If you consider it will be better I will deep further on the platform as today my knowledge is very limited about weblate.

FTR, Placeholder mismatch detection · Issue #11429 · WeblateOrg/weblate · GitHub

Weblate has already such checks.
But it seems that we need to add the appropriate flags to the po entries.

Thanks for the script and the suggestions! I’m working through it. What I see is that it seems that some of the placeholders were also translated instead of keeping the name.

1 Like

Yes translated strings was one of the spotted problems, also I found:

  • strings with placeholder errors (extra spaces) like %( value)s
  • new placeholders incorporated on previous translated messages

Here is Add python-format flag to PO files (!1435) · Merge requests · Tryton / Tryton · GitLab

Nice, also I will not remove the script because maybe someone need it to check custom modules.
I wonder if it’s not still valuable to incorporate such checks in tests for custom modules.