Feature Request: Rename transcription jobs (job title override)

[erklu]

Background

Currently, transcription jobs inherit their name directly from the uploaded file. While this is simple, it creates several usability issues:

• Users often run multiple transcriptions on the same source file (e.g. different models, subtitle vs fulltext, diarisation on/off)
• Uploaded filenames can be overly long, inconsistent, or not meaningful in context
• There is no way to add semantic meaning (e.g. “verbatim draft”, “final subtitles”, “cleaned version”)

This leads to reduced clarity in the My Files / Dashboard view, especially for users working with multiple iterations of the same material.

Problem

Users cannot distinguish between different jobs based on purpose or processing settings.

This becomes particularly problematic in:

• Iterative workflows (edit → export → re-run)
• Educational and research use cases with multiple variants
• Cases where filenames are auto-generated or contain technical metadata

Proposed Solution

Introduce support for user-defined job names ("job title override").

Core functionality

• Each job should have:

  • original_filename (immutable)
  • job_name (user-editable, optional)

• Default behavior:

  • job_name = original_filename (initially)

• Users can rename the job without affecting:

  • underlying file
  • storage reference
  • job ID

UI/UX Proposal

Primary location: Editor view

Renaming should be available inside the editor, where the user has full context of the job.

• Editable title field in the job info panel of the editor
• Inline editing (click → edit → save on blur/enter)
• No modal required

Rationale:

• The editor is where the user understands what the job is
• Aligns with design principle: context-aware actions oai_citation:0‡Transcriber_UI_Overview_250608.pdf

Secondary location (optional)

• Rename action in "My Files" (e.g. via kebab menu or inline edit)
• Lower priority, as context is weaker

Expected Behavior

• Renaming updates the display name in:

  • My Files / Dashboard
  • Editor header
  • Export filenames (optional, see below)

• Original filename remains:

  • visible in metadata (e.g. tooltip or details panel)
  • used internally for traceability

Export behavior (to decide)

Two possible approaches:

Option A (recommended):

• Export uses job_name
• Improves usability and clarity for users

Option B:

• Export uses original filename
• More conservative, but less user-friendly

Technical Considerations

• Add job_name field to job model (database)
• API:
  • PATCH /jobs/{job_id} → update name
• No duplication of file storage
• No impact on job processing pipeline

Future Extensions

• Auto-suggest names based on:
  • processing options (e.g. “Swedish subtitles (KB-Whisper)”)
• Version labeling (e.g. v1, v2, final), esp if job branching is introduced (see Feature Request: Versioning of edited transcriptions scribe-backend#5 )
• Integration with job branching feature if that is introduced.

Priority

Medium–High

Strong UX improvement with low technical complexity.