feat: mark invalid entries as fuzzy | FC-0012

[OmarIthawi]

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]

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]

@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.

[brian-smith-tcril]

Left more comments with more thoughts. I like the fuzzy plan. Looking forward to seeing what we can do to make it great!

[brian-smith-tcril]

Suggested change

	Implement a GitHub Actions workflow that will mark the invalid entries as
	``fuzzy``. Then create a commit -- editing the pull request -- to branch
	of the bot pull request.
	A GitHub Actions workflow will be implemented to mark invalid entries in synchronized
	``.po`` files as ``fuzzy``. This will update pull requests created by the Transifex GitHub
	App.

[brian-smith-tcril]

I discussed this with Sarina and I think we can address this fairly elegantly by allowing this action to create issues on https://github.com/openedx/wg-translations/issues

It might take a bit of work to ensure we don't spam that repo with issues. I'd be happy to discuss how this could be implemented with you!

[OmarIthawi]

You're right, we should implement a notification mechanism.

I think the following has the same cost and complexity, therefore we should implement the one with the best Translator Experience.

Option 1: WG Translations project GitHub issues

Create a list of people/teams to notify when things fail. One way is to utilize a CODEOWNER file to know who to nofity for which resource/language pair. Often the file has flexible enough rules to specific files belongs to which contributor.

If the CODEOWNER file format turns to be difficult, we can implement a YAML file to provide an easier to parse file in a similar manner.

Option 2: Slack comments in a new #translations-wg-issues channel

Post to a message to a new Slack channel e.g. #translations-wg-issues to announce the issue.

The Slack message may include a handle to the Slack CODEOWNER

with handles to assign Slack users handles and let the bot notify them.

Option 3: Email the contributors with their Transifex emails

Emails are not public, but definitely one way to tackle the issue

Option 4: Open Transifex issues for each entry, and mark them as "unreviewed"

Get the msgid of the fuzzy entry then look it up on Transifex and open an issue. This notifies Transifex admins with a direct link to the entry via email. However, those issues are not visible to translators as far as I know.

We can use one or more notification mechanism based on what we see fit.

Please let me know what do you think @brian-smith-tcril.

[brian-smith-tcril]

Since goal is to implement the solution that provides translators with the best experience, I think this is a good question to ask in the #wg-translations slack channel.

[brian-smith-tcril]

Since goal is to implement the solution that provides translators with the best experience, I think this is a good question to ask in the #wg-translations slack channel.

[OmarIthawi]

Yes, this is sufficient and retry isn't needed because this step will either succeed or keep failing.

The --rebase --auto marks the pull request to be auto-merged by GitHub and GitHub will take care of the process.

[OmarIthawi]

Status: Currently testing on my fork and there are some complications, but I'm hoping I could address them.

Testing PR:

• Fuzzy test Zeit-Labs/openedx-translations#82

[OmarIthawi]

@brian-smith-tcril this pull request is ready for review and merge. It lacks the notification mechanism, which we can implement in another pull request to make this one smaller.

Please check it out and let me know what do you think.

Once this is ready for merge, we will need your admin-forced merge. Then update the main branch protection rules to set the required status check from validate-po-files (github actions) --> tests (any source) once this pull request is merged.

[OmarIthawi]

Closed for reasons mentioned in #2128.

[openedx-webhooks]

@OmarIthawi Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.

[openedx-webhooks]

@OmarIthawi Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.