Code review recordings. Keep the revision in view.

Find the reasoning without losing the code it describes

A teammate records a walkthrough of a proposed change. By the time another reviewer watches it, the branch has moved and a function has been renamed. Searchable text can help find the explanation, but it needs the recorded revision beside it. Polyglot can transcribe an authorized recording locally on an Apple Silicon Mac running macOS 14.4 or later, support human review and translation, and export text, SRT or WebVTT.

This workflow produces a faithful viewing and reading aid plus a separate, manually prepared reference note. It does not review code, detect defects, extract text from the screen, identify speakers automatically or connect to a repository. A recorded walkthrough complements the code diff and the team’s review process.

Make a small map from recording time to repository revision

Before processing, identify the final recording filename, repository, full commit ID and the purpose of the walkthrough. For a comparison, record both the base and proposed commit. A branch name alone is not a stable reference. GitHub’s permanent-link guidance explains that a branch URL follows its current head, while a commit-specific URL identifies the file version being discussed.

Create a companion note for the moments a reviewer will need: video timestamp, file path, function or symbol, and a permanent link to the relevant revision. Include line references only with that revision. If the recording switches commits or shows uncommitted edits, mark the transition and preserve an approved patch or clean snapshot separately. Do not label the entire recording as one commit when that is not what it shows.

Keep the map outside the subtitle text. Long hashes, URLs and line ranges belong in a reference document; adding unspoken explanations to captions would change the record. This map is authored by a person, not generated or maintained by Polyglot.

Check the question before turning it into an action

Listen while reading the draft, especially around negation, conditions and tentative language. “Could we cache this?” is a question; “we cache this” is a statement about behavior. Preserve that distinction. Check a spoken identifier against the recorded code for spelling, but do not replace the actual words with a different function just because the branch now contains it.

The fictional example below shows a manual reference note. It is not a real repository, customer recording or transcription benchmark. The caption correction restores the question; the proposed follow-up remains outside the transcript.

Fictional review note
Clip: cache-review-v02.mp4
Revision: full commit ID
Anchor: 00:42 / Cache.swift
Symbol: loadEntry

Heard: “Could we cache this
only after validation?”
Draft: “We cache this
after validation.”

Caption: restore the question.
Review note: proposal open.
Decision: not recorded.

Keep later decisions out of the earlier transcript

W3C’s transcription guidance emphasizes faithful speech and human correction of automatic drafts. Do not silently improve a technical explanation, turn a suggestion into a requirement or rewrite an uncertainty using something learned later. If the narrator says something incorrect, retain the spoken record and put a clearly attributed correction in the companion note or repository discussion.

GitHub distinguishes a comment, an approval and a request for changes as separate review decisions. A phrase in a recording is not a submitted repository review. Transfer actionable feedback through the team’s normal review process, linked to the relevant code; do not infer approval from a transcript or mark a discussion resolved because the video says “looks fine”.

If a new commit changes the relevant code, keep the original recording and its map intact. Add a separate follow-up identifying the new revision and which questions remain open. Before reusing old captions with an edited walkthrough, verify the whole track against the new cut. A current pull request can contain historical explanations that are useful but no longer describe its latest state.

Review technical language and permissions together

Check that the spoken language is supported before automatic transcription. Recognition and translation have different coverage. For translated tracks, have a technically competent bilingual reviewer check conditions, uncertainty, return-value terminology and identifiers. A readable translation should still let the viewer find the same symbol in the recorded revision. Cue-structure checks do not prove that the code or explanation is correct.

Use recordings and code you are authorized to process and share, with permission for captured voices and screens. Check company rules for local AI tools and the approved recipient group. Remove secrets, customer data or unrelated material in an appropriate media editor before producing the final recording. Removing a token from captions leaves it visible or audible in the media; Polyglot does not redact it.

Check the destination before uploading. GitHub documents that attachments upload immediately and that uploaded files in public repositories are accessible without authentication. An unfinished comment is not private staging. Local processing also does not determine access to a recording after delivery.

Test the video, text and revision as one handoff

Export reviewed text for searching or SRT/WebVTT for a compatible player. Name the recording and language files consistently, and include the reference note. GitHub’s attachment list includes video, text and ZIP files but does not list SRT or VTT. If your approved destination cannot accept a subtitle directly, use a permitted archive or file location. File acceptance does not prove the embedded video player can load that track; test the intended viewing arrangement.

Have an authorized reviewer open the exact delivered recording, enable the intended language and seek to a mapped moment. Confirm that the caption matches the audio, the permanent link opens the intended code revision, and the viewer has access to both. Check small code text and subtitle placement at the actual viewing size. Silent code edits need a separate explanation; speech recognition cannot describe actions nobody narrates.

The handoff is ready when a reviewer can locate the explanation, inspect the code it referred to and distinguish recorded speech from later feedback. Polyglot prepares local subtitle and transcript files; screen recording, repository review, hosting, access controls and burning captions into video remain separate tasks.

Keep exploring.