Subtitles for bug reproduction videos on Mac.

Make a recorded bug easier to follow

A narrated bug reproduction lets a teammate see the moment an application behaves unexpectedly. Polyglot can transcribe an authorized recording locally on an Apple Silicon Mac, help you review and translate timed text, and export separate SRT or WebVTT files. Pair those captions with a written reproduction note so another tester can recreate the starting conditions and find the relevant moment.

The video shows one recorded attempt. It does not establish the cause, the frequency of the issue or whether a later build fixes it. Keep setup, actions, expected behavior and observed behavior distinct. Polyglot creates and edits subtitles; it does not diagnose bugs, read interface text from video, record your screen or create issue-tracker reports.

Prepare a recording that is safe to share

Use software, test data and recordings you are authorized to process and share. Prefer a synthetic account and an approved test environment. Before recording, close unrelated windows and notifications; check names, addresses, tokens, paths, browser tabs and spoken information. Arrange permission for anyone whose voice or image appears. Use the approved private reporting channel for confidential defects.

If an existing capture includes excluded information, resolve it in an appropriate video editor or make a clean authorized recording before creating the final captions. Removing a secret from subtitle text leaves it in the picture or audio. Polyglot does not redact recordings. Local transcription also does not determine who can access a file after you share it; the privacy page describes the app’s separate network boundaries.

Review the destination before attaching anything. GitHub documents that attachments upload immediately and that files uploaded to public repositories can be accessed without authentication. An unfinished issue draft is therefore not a private staging area for a sensitive recording. Check the receiving system’s rules and audience before transferring any file.

Write down the conditions needed to reproduce it

Record the application build, operating system, relevant locale, test-data revision and starting settings. Include only environment details that help reproduce the problem. Number the actions, naming both the intended task and how it was performed: mouse click, keyboard shortcut or another input method. State what should happen, what you actually observed and whether repeat attempts produced the same result.

Mozilla’s reporting guide separates precise steps, expected results, actual results and speculation. Chromium likewise asks for detailed reproduction steps and a simplified test when possible. Apply that discipline to the companion note. Do not let a polished video replace setup instructions, relevant logs or a small test case requested by the receiving team.

Give the final recording a versioned filename and note the moment where the result appears. If you shorten a capture, retain enough setup to explain the state or describe omitted preparation explicitly in the note. Keep real elapsed time visible when a delay is part of the defect. Do not join separate attempts in a way that implies one continuous run.

Review the words without inventing an explanation

The following newly written fictional example uses a made-up task app and synthetic data. It illustrates a manual review note, not a real defect, test result or model benchmark. The narration, visible result and proposed explanation have different roles.

Replay every cue against the audio. Restore missing negation, exact numbers and spoken keys. In this example, dropping “not” reverses the observation. If the narrator says “I click Apply” but the pointer misses the button, preserve the words and describe the mismatch separately. Captions must not silently turn an attempted action into a confirmed one.

Fictional reproduction note
Clip: filter-reset-v02.mp4
App: Sample Tasks / build 42
OS: macOS 14.4 / locale en-GB
Data: synthetic set B
Start: all tasks, filter off

1. Choose status Open.
2. Activate Apply.
Expected: only open tasks.
Observed at clip 00:18:
A row marked Closed remains.

Heard: “It did not filter
out the closed task.”
Draft: “It did filter
out the closed task.”
Review: restore “not”.

Cause: not established.
Retest: not yet performed.

Keep screen evidence and translated narration connected

Check product terms, error codes, menu names and shortcuts against the recording and the exact build. A visible error message can belong verbatim in the written report even if the narrator only paraphrases it. Do not substitute that message for what the person actually said. Silent cursor movements, clicks and state changes need clear written steps or separately prepared visual description; speech recognition cannot recover unspoken actions.

W3C recommends reviewing automatic captions and including relevant non-speech audio. Check audible alerts or device speech when they affect the reproduction. Distinguish an application announcement from the narrator where needed, using labels you have verified. A silent screen recording needs an authored explanation rather than an expectation that transcription will describe its interface.

Translate only after reviewing the source. Have a competent reviewer check negation, uncertainty and the difference between “should close” and “closed”. Preserve a usable connection to labels visible in the recorded interface, even when a localized build uses different wording. Put any explanatory mapping in the companion note. Cue-structure checks and preserved source timing do not establish technical correctness or translation accuracy.

Test the exact video, captions and report together

Export the format your receiving player accepts, then load it with the final recording and enable captions. Check attachment acceptance separately from subtitle playback. GitHub’s documented attachment list includes videos and ZIP archives but does not list SRT or VTT. Where your team permits it, package subtitle files in a ZIP or place them in an approved file location. Accepting those files does not establish that the issue’s video player will load them. Test the extracted track in a compatible player. If it cannot display the track, use an approved player that can, or prepare a captioned video separately in suitable editing software. Polyglot does not burn subtitles into the picture or upload them to a tracker.

Watch the setup, decisive action and result at the intended viewing size. Confirm that captions do not obscure the control, error or status being reported. If you compress or edit the clip, check that small interface text remains readable and that a flicker, delay or intermediate state has not disappeared. Recheck timing after any cut or speed change; an older caption file does not automatically fit the revised video.

Deliver the versioned clip, reviewed language files and reproduction note together. Check that every time reference points into that clip and every build identifier refers to the recorded attempt. Give a later retest its own record instead of overwriting the original evidence. The handoff passes when the next tester can locate the observation, understand the starting state and play the intended captions. It does not pass merely because the files uploaded successfully.

Keep exploring.