[l10n/automation] Advisory source-string diff comment on PRs

[Chaitanya-Keyal]

Note

One of the l10n source-string automation PRs (#940, #941, #942, #943, #944). It uses the schema and tools from #940 and #941. It needs no bot fork, secrets, or configuration: these workflows run in this repo on the built-in GITHUB_TOKEN.

Description

Problem or Issue being addressed

There is no automated way to see what source strings a PR adds, removes, or changes. Reviewers either skip translation impact entirely or manually diff catalogs.

Solution

Adds the two-workflow advisory comment pipeline:

• l10n-pot-diff.yml -- triggers on pull_request (the untrusted path, no secrets). It regenerates the catalog from the base branch and the PR head separately, calls pot_diff.py to build a review manifest, and uploads it as a workflow artifact. Running untrusted PR code here is safe because the job has only contents: read and no secrets to leak.
• l10n-pot-comment.yml -- triggers on workflow_run (the trusted path, default-branch code only). It downloads the artifact, validates it via validate_manifest.py (schema plus trust anchors), renders the comment via render_comment.py, and upserts a single advisory comment per PR. The workflow_run trigger guarantees this job always runs the code from the default branch, never the PR, so the write-capable GITHUB_TOKEN is never in the untrusted execution context (pwn-request-safe split).

Both jobs are SHA-pinned, use persist-credentials: false, run with minimal permissions, and have a timeout-minutes: 10 guard.

Additional Information

Demo PR: Chaitanya-Keyal#2

---

This pull request is categorized as a:

• Other (l10n automation)

---

Checklist

I ran pytest locally

• N/A

(No Python code is added here; the unit tests for the code these workflows invoke are in #940 and #941.)

---

I included screenshots of any new or modified screens

• Yes (Demo PR link included)

---

I added or updated tests

• N/A

(The workflows are validated end-to-end on a fork; there are no unit-testable parts in this PR.)

---

I tested this PR hands-on on the following platform(s):

• Github Actions

---

I have reviewed these notes:

• Keep your changes limited in scope.
• If you uncover other issues or improvements along the way, ideally submit those as a separate PR.
• The more complicated the PR, the harder it is to review, test, and merge.
• We appreciate your efforts, but we're a small team of volunteers so PR review can be a very slow process.
• Please only "@" mention a contributor if their input is truly needed to enable further progress.

• I understand

---