Fix crowdin syncing

[SaschaCowley]

Link to issue number:

Fixes #20524

Summary of the issue:

The "Fetch tracked translations from Crowdin" workflow was successfully running, committing new translations that were valid, creating a PR, and sending an email to the l10n list, but the emails were being bounced. As there was no return path address, and the workflow runs didn't show that there were errors unless you reviewed the logs, these failures were essentially silent.

Description of user facing changes:

No end-user-facing changes.

Emails sent to the l10n list now include each failing locale's output as attachments, which should make reviewing the logs they are interested in much easier. The emails also now link to the generating workflow run.

Description of developer facing changes:

None to the NVDA API. Changes are limited to CI:

• The Crowdin sync workflow now produces clearer PRs and translator notifications.
• Per-locale validation reports are uploaded as workflow artifacts and attached to the notification email rather than embedded inline.

Description of development approach:

As best as I can tell, the sudden failure of this workflow was due to either Google tightening checks in Google Groups, or some change in our Workspace configuration that I'm not aware of. The end result was that messages to nvda-l10n@nvaccess.org from <nvda-l10n@nvaccess.org` were being bounced. Thus, the ultimate fix here is that the emails now come from noreply@nvaccess.org.

I also fixed some other problems with the workflow:

• The branch name for translation syncs (branchName) now includes github.run_attempt so re-runs don't collide.
• Added workflowRunUrl and workflowRunName env vars for reuse in the PR body and emails, both of which refer to the specific run and attempt.
• Replaced the single temp file containing all failing locales with a temp directory containing one <lang>.txt file per failing locale. These files are then exposed via a report_files step output (JSON array) instead of the inline invalid_pofile_reports blob.
• The validation script now emits GitHub Actions log groups (::group:: / ::endgroup::) and error annotations (::error file=...::) for each failing .po file. This gives a clear indication of failures on the workflow run page, and makes the log output easier to read.
• Added an "Upload error logs" step that uploads the per-locale reports as a workflow artifact when there are locales which failed validation.
• The "Create pull request" step now builds the title/body in PowerShell — "Update valid tracked translations…" when some locales were excluded (listing them) vs. "Update all tracked translations…" otherwise — and links to the workflow run.
• When failures occur, the reports are now sent as attachments rather than inline, and the body links to the workflow run.
• The email recipient/sender are sourced from repo vars (L10N_EMAIL_TO, L10N_EMAIL_FROM). A return path address has been added (EMAIL_BOUNCE_ADDRESS) so that if something similar happens in future, we should hear about it.
• Updated actions/checkout from v4 to v7; actions/setup-python from v6 to v7; astral-sh/setup-uv from v6 to v8.3.2; and dawidd6/action-send-mail from v4 to v18. Added actions/upload-artifact at v7.

Testing strategy:

Iteratively validated by running the workflow in CI to confirm branch naming, artifact upload, PR title/body generation, and email delivery with attachments. Tests were run with the checkout branch set to crowdin-sync so the updated CI script would be used, and were mostly run with the recipient being my email address rather than the l10n group, though that was tested too.

Known issues with pull request:

The "Monitor Localisation File Changes" workflow will need some of the same changes. This should be done in a separate PR.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.