ci: add workflow to track doc-en changes and open sync issues

[lacatoire]

Adds a daily GitHub Actions workflow that watches commits on php/doc-en and automatically opens issues for files that need updating in the Japanese translation.

How it works

• Runs every day at 06:00 UTC (and can be triggered manually)
• Fetches all doc-en commits from the last 7 days
• For each commit, checks whether an issue already exists (deduplication by SHA)
• If not, opens an issue listing the JA files to update
• Skips commits tagged [skip-revcheck]
• Creates the sync-en label on first run if it does not exist yet

Prior art

This workflow is already in use in doc-fr, doc-ru, doc-es, and doc-de. There is also an ongoing initiative in doc-base to provide reusable workflows that all doc-* repos can share.

[KentarouTakeda]

Thanks. A bug report first, since this is already running in doc-fr, doc-es, doc-ru and doc-de.

There is an infinite loop in the pagination guard:

COUNT=$(echo "$BATCH" | grep -c . 2>/dev/null || echo "0")

On an empty page grep -c prints 0 and exits 1, so || echo "0" runs as well and COUNT becomes the two-line string 0\n0. [ "$COUNT" -lt 100 ] then errors ("integer expression expected") instead of evaluating false, break is never reached, and while :; spins until the 6-hour job timeout. set -e does not catch it because the test is an if condition. It triggers on a zero-commit window, on a total that is an exact multiple of 100, or — most likely — on a failed or rate-limited gh api call, since || true leaves BATCH empty.

COUNT=$(echo "$BATCH" | sed '/^$/d' | wc -l)

For doc-ja I'm declining, for the reason given in php/doc-pt_br#786: revcheck already tells us what needs updating, on demand and without a backlog to triage. doc-en has averaged about 13 commits a week over the last 12 weeks, so this would add roughly 700 issues a year against the 4 we currently have open.

One note across the three PRs: this script skips [skip-revcheck] commits while #413 fails a PR on exactly those commits, so merged together they would give opposite signals about the same doc-en change. Given that doc-base documents the marker's current behaviour as a defect (php/doc-base#181, open since 2024-11-18), it seems worth letting that settle before more repositories depend on it.

Closing. The pagination fix is worth applying regardless.