feat: mark invalid entries as fuzzy | FC-0012 #1944

OmarIthawi · 2023-10-21T01:02:58Z

Description

This is an feature that I'd like to make for Transifex pull requests to avoid having stale PRs at all.

Problem

The Transifex bot creates pull requests with invalid entries in the po-files. Pull requests with invalid translations gets stuck and needs manual intervention in Transifex to fix invalid entries manually.

This often creates a backlog of PRs that needs attention:

Current list of *15* stuck PRs

If Transifex had marked the invalid entries as fuzzy, then the django compilemessages command would have ignored them. However, that's not the case. Therefore, we need to perform this task ourselves.

Solution

Please review the included design document for this PR because it will modify Transifex bot pull requests before merging them.

TODO

Write unit tests
Test locally on an actual invalid file
Test with unfixable file

Details

diff --git a/translations/credentials/credentials/conf/locale/hi/LC_MESSAGES/django.po b/translations/credentials/credentials/conf/locale/hi/LC_MESSAGES/django.po
index bc7f6bcb..0f24afc7 100644
--- a/translations/credentials/credentials/conf/locale/hi/LC_MESSAGES/django.po
+++ b/translations/credentials/credentials/conf/locale/hi/LC_MESSAGES/django.po
@@ -249,6 +249,7 @@ msgstr "{first_org} और {second_org}"
 
 #: apps/credentials/views.py
 #, python-brace-format
+#, fuzzy
 msgid "{series_of_orgs}, and {last_org}"
 msgstr "{Series_of_orgs}, और {last_org}"
 
@@ -270,6 +271,7 @@ msgstr "कैश क्लियर हो गया।"
 
 #: apps/edx_django_extensions/views.py
 #, python-brace-format
+#, fuzzy
 msgid "{action} is not a valid action."
 msgstr "{कार्रवाई} एक वैध कार्रवाई नहीं है।"
 
@@ -628,6 +630,7 @@ msgstr "द्वारा देखा गया"
 #. Translators: This phrase appears on certificates to show the issue date
 #: templates/credentials/programs/base.html
 #, python-brace-format
+#, fuzzy
 msgid "Issued {month} {year}"
 msgstr "जारी किए गए {महीने} {वर्ष}"

Get the decision reviewed
Update the GitHub workflow as described in the decision
Test on my fork
Rename validate-po-files to tests because it's testing Python as well
Notify the Translators Working Group about faulty translations

Test results on my fork

The script was successful: https://github.com/Zeit-Labs/openedx-translations/actions/runs/6668435745/job/18123996026 but fails (intentionally) due to draft status on the test pull request: Fuzzy test zeit-labs/openedx-translations#82
Test set the new commit status so it's merge-able

Fix lint issues and squash commits

openedx-webhooks · 2023-10-21T01:03:04Z

Thanks for the pull request, @OmarIthawi! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

supporting documentation
Open edX discussion forum threads
timeline information ("this must be merged by XX date", and why that is)
partner information ("this is a course on edx.org")
any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

OmarIthawi · 2023-10-23T18:17:18Z

@shadinaif @brian-smith-tcril this is ready for initial review.

brian-smith-tcril

@OmarIthawi before I finish reviewing the documentation in this one I'd like to discuss this decision.

The fact that

The workflow lacks a notification mechanism to notify the reviewers
that their translations are invalid.

Is rather concerning to me, as it could lead to a disconnect in understanding of the state of translations. A translator working in Transifex would think everything is fine, and the lack of error on the PRs could make it likely that we wouldn't notice a translated string isn't working until it came time to test the translations manually in-application.

I'm not opposed to utilizing fuzzy, but I want to make sure we do this in a way that we aren't just "eating errors" so to speak.