Repository navigation
Translation tracker: auto close issue on PR merged and closed and translation coverage - #1582
aashishpanthi wants to merge 557 commits into
Conversation
feat: add title attributes to all iframes for accessibility
…-doc fix: correct circle() diameter explanation in Get Started tutorial
fix: restore focus after search submission (processing#914)
feat: add visually invisble h1 to search result page
feat: Add alt text to CC BY-NC-SA license badge in ExampleLayout
…y under Astro/Vite)
Fix processing#870: apply underline styling to anchor element
…nt-path replace deprecated dirent.path with dirent.parentPath (on main). fixes processing#1111
…ation chore: add missing Hindi translations for homepage & UI elements
fix: inconsistent paths and backticks in technical_overview.md file
Also added some logging so it's clear which repo & branch are being considered / cloned
Improve code block contrast with GitHub Light High Contrast theme
…README documentation
…generation limits per language; remove test files.
As adviced by mentor
We now look at the title, body, comments, cross references to pull out the issue number(s)
|
Note: This branches off the stub-file-generation PR. So, #1473 should be merged first, then this. |
…es changed/added in the PR to ensure the correct translations have been added
| name: Translation Auto-Close | ||
|
|
||
| on: | ||
| pull_request: |
There was a problem hiding this comment.
Hi @aashishpanthi , I see one blocker here for which I'm not very sure.
For any PR opened from a fork (which is how virtually all external translation contributors submit), GitHub downgrades GITHUB_TOKEN to read-only regardless of the permissions: block. This workflow needs issues: write to remove labels, edit the body, comment, and close/reopen, all of those API calls (removeLabel, issues.update, createComment) will return 403 for fork PRs.
The whole motivation of the PR ("real contributors" not using linking keywords) implies fork-based PRs, so as written the feature might work only for maintainers pushing branches inside the repo.
Can we test this on a fork?
cc: @ksen0 do you have any views here?
There was a problem hiding this comment.
Sorry for the very delayed response, but I created a new GitHub account just to try the new changes. As you can see, aap009#15
Here, the write on issues is working. In the workflow file, I changed the workflow trigger from pull_request to pull_request_target. Exactly this.
Let me know if any problems arise.
| const { getLanguageDisplayName, getTranslationPath } = require('./utils'); | ||
|
|
||
| // List all files changed in a merged PR (paginated). | ||
| async function listPullRequestFiles(octokit, owner, repo, pullNumber) { |
There was a problem hiding this comment.
This function returns every file including status: "removed"/"renamed", and neither identifyLanguagesFromFiles nor the verifiedLanguages filter checks status:
const verifiedLanguages = languages.filter((lang) => {
const paths = expectedPaths.get(lang);
if (!paths || paths.length === 0) return false;
return paths.some((p) => changedFileNames.includes(p)); // matches removed files too
});
A PR that deletes src/content/examples/es/foo.mdx would strike Spanish, remove lang-es, and potentially close the tracker issue - the opposite of the truth. Filter to file.status === 'added' || 'modified' (or exclude removed) before deriving languages and verifying paths.
There was a problem hiding this comment.
I resolved it, now we check if the file was updated, added, or deleted.
|
Also, latest update: I have added the translation coverage to this PR. A detailed description is found above in PR description. But it can be dispatched from GitHub Actions. See one here. This is what the dispatch looks like: |
aashishpanthi
changed the title
Summary
Extends the translation tracker with:
lang-*label, and close the issue when nothing remains.public/translation-status/coverage.json(served as/translation-status/coverage.json).Addresses #1404.
Auto-close issue
How an issue is found
Relying on
Resolves #123did not worked well with real contributors: most translation PRs either use no linking keyword or mention the issue somewhere other than the body. So any#123is treated as a candidate, and it is looked for in:#123" during review)https://github.com/<owner>/<repo>/issues/123linksHow false positives are avoided
Matching every
#123is deliberately greedy, so candidates are filtered:owner/repo#123cross-repo references and#123abcare not matched; numbers are capped at five digits because color codes are six digits and we are in four digits, we'll reach six digits in years (needs attention)needs translationlabelHow an issue is updated
Which languages a PR translated is derived from its changed file paths, for example
src/content/examples/es/...means Spanish. For each such language, the action removes thelang-<code>label and strikes that language's line in the issue body. The issue is closed only when nolang-*labels are left.One tracker issue often covers several languages for the same English file, which creates a wrinkle: GitHub closes an issue natively the instant a PR saying
Fixes #123is merged, even when only one of four languages was done. The action detects this and reopens the issue, leaving a comment naming the languages still working.Translation coverage
translation-coverage.yml— runs on push tomainfor content changes, or via Actions → Translation Coverage → Run workflow..github/actions/translation-tracker/coverage.js— filesystem-only scan (present/missing/stub). Andd excludesreference.coverage.jsonas a public file for the visualization.languages,content_typeswhich can be dispatched from web.Test plan
coverage.jsonupdates quickly. See here/translation-status/coverage.jsonis publicly reachable after deploy.