Serialise translation reviews to stop duplicate report comments (#134)

Ports the fix from QuantEcon/lecture-python-programming.fr#7. This repo
has the identical trigger list and no concurrency guard, and the bug is
already reproducing here: PR #133 carries two "Translation Quality
Review" comments, scoring 9.2/10 and 8.8/10, both posted at 23:51:37.

A single translation sync fires `opened` plus one `labeled` event per
label applied, all within a couple of seconds. Each starts its own run of
this workflow, and the review action's "update existing comment, else
create" logic is a check-then-act with no lock: concurrent runs all see
"no comment yet" and each create one. On PR #133 three runs fired; two
logged `Posted review comment` and one logged `Updated existing review
comment`, leaving two independent reports of the same diff and three full
model calls where one was intended.

Add a per-PR concurrency group so runs queue instead of racing — the
first creates the comment, any later run updates it. cancel-in-progress
is left false on purpose: the labels are applied in one API call so event
order is not guaranteed, and cancelling would let a `labeled` event for
'automated' kill the in-flight review and then skip its own job, leaving
no review at all.

Also ignore `labeled` events for labels other than 'action-translation',
which removes the redundant review triggered by the 'automated' label.

The underlying unsynchronised upsert is tracked in
QuantEcon/action-translation#96.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: mmcky

.github/workflows/review-translations.yml

@@ -7,9 +7,34 @@ on:
   pull_request:
     types: [opened, synchronize, labeled, reopened]
 
+# Serialise reviews per PR.
+#
+# The sync action creates the PR and then applies its labels in a separate call,
+# so a single sync fires `opened` plus one `labeled` event per label, all within
+# a couple of seconds. Every one of those starts a full review, and the action's
+# "update the existing comment, else create one" logic is a check-then-act with
+# no lock — concurrent runs all observe "no comment yet" and each create one.
+# See QuantEcon/lecture-python-programming.fr#6, which collected two review
+# comments this way, and QuantEcon/action-translation#96 for the upstream bug.
+#
+# cancel-in-progress is deliberately false. The labels are applied in one API
+# call, so event ordering is not guaranteed; if 'automated' arrived last it would
+# cancel the in-flight review for 'action-translation' and then skip its own job
+# via the filter below, leaving no review at all. Queuing instead means the first
+# run creates the comment and any later run updates it — one comment, always.
+concurrency:
+  group: review-translations-${{ github.event.pull_request.number }}
+  cancel-in-progress: false
+
 jobs:
   review:
-    if: contains(github.event.pull_request.labels.*.name, 'action-translation')
+    # Require the 'action-translation' label, and — for `labeled` events — ignore
+    # labels other than that one. Without the second clause the 'automated' label
+    # fires a second, redundant review of the identical diff.
+    if: >-
+      contains(github.event.pull_request.labels.*.name, 'action-translation') &&
+      (github.event.action != 'labeled' ||
+       github.event.label.name == 'action-translation')
     runs-on: ubuntu-latest
 
     steps: