Page MenuHomePhabricator

Title column validation (!28)
Closed, ResolvedPublic

Description

Summary

The Title column doubles as the future filename of a published Commons file (sans extension). It needs to follow Commons' filename rules — uniqueness, length, character restrictions, readability — but today there's no validation. Implement client-side validation backed by Commons' API where needed, surface clear errors, and improve the default value so the title is something readable rather than a camera-generated string.

Research first

Survey how the Commons Upload Wizard validates filenames (it's the closest reference; we don't need to copy it exactly, but it's a good baseline). Document in the task the specific rules to enforce:

  • Length limit (Commons / MediaWiki filename max length).
  • Character restrictions (which characters are forbidden, e.g. /, :, leading/trailing whitespace, etc.).
  • Readability heuristics (rule of thumb: plain readable text, not "IMG_2351"; not enforced strictly but called out).
  • Uniqueness — a real-time check against Commons via API (likely action=query&prop=info&titles=File:<NAME>.<ext> to detect a clash). Cache the lookup with a small TTL.

Implementation

  • Default value of the Title column: the original filename (sans extension) of the user's upload, instead of being blank. Today's "Original filename" column, which surfaces the same thing in a separate column, becomes:
    • Optional — not visible by default.
    • Available — the user can add it via the columns modal if they specifically want both side-by-side.
  • Validation runs as the user edits a Title cell:
    • Length, character restrictions: client-side, instant.
    • Uniqueness: debounced API call to Commons; show a "checking…" indicator, then a tick or an error.
  • Error display: inline, below the cell, with actionable wording — e.g. "Already exists on Commons — pick a different title" or "Forbidden character: ':'".
  • Info link / icon: next to the column header or in its settings dropdown, link to Commons' filename guidance page.

Out of scope

  • Suggesting alternative filenames automatically.
  • Renaming the file extension from the column (the extension stays bound to the source file).

Acceptance

  • New uploads land with the original filename pre-filled in the Title column (sans extension).
  • "Original filename" column is present but hidden by default in the columns modal.
  • Editing a title shows live validation errors for length, characters, and Commons-clash.
  • Publishing is blocked while a Title cell has a validation error.
  • The validator's behaviour matches the documented Commons / Upload Wizard rules.

Source

User feedback session, 2026-05-10.

Event Timeline

Daanvr moved this task from To do to Doing on the Tool-upload-workbench board.

Research summary — proposed validation rules

Sources: Commons:File naming, MediaWiki page title manual, Commons title blacklist.

Validation rules to enforce client-side

Forbidden characters (hard error, blocks publish):

  • MediaWiki wiki-syntax characters: #, <, >, [, ], |, {, }
  • Path/title separators: /, \\, :
  • Tab/CR/LF and ASCII control characters (0–31, 127)
  • Three-or-more consecutive tildes (~~~) — interpreted as a signature
  • Percent followed by two hex digits (%XX) — looks like URL-encoding to MediaWiki

Length (hard error):

  • Max 240 bytes UTF-8 (Commons recommendation; MediaWiki hard cap is 255 but Commons reserves 15 bytes for date prefixes on file revisions)
  • Min 1 character after trimming whitespace

Whitespace (hard error):

  • No leading/trailing whitespace
  • No two-or-more consecutive whitespace runs

Other structural (hard error):

  • Title cannot equal exactly . or ..
  • Title cannot start with a colon

Soft warnings (yellow, doesn't block publish, just informs):

  • Camera-style auto-names matched by Commons title blacklist (DSC*, IMG_*, P*, MVIMG_*, screenshots, WhatsApp images, etc.) — these will be rejected by Commons at upload time anyway, so we warn before publish to save the round-trip
  • Title equals (or differs only by extension from) another visible row in the workbench (would create a server-side filename clash mid-publish)

Uniqueness check (hard error if hit, soft 'checking…' while in flight):

  • action=query&prop=info&titles=File:<title>.<ext> — missing:true ⇒ free; pageid present ⇒ taken
  • Debounced ~400 ms after the last keystroke
  • Cached via existing apiCache (5-min TTL is fine — it's only a cache, the real check happens at publish via upload warnings anyway)

Default value

Title pre-filled from the original filename (sans extension) on every new upload — replacing today's blank default. The 'Original filename' column stays available, but is hidden by default.

Out of scope

Suggesting alternative filenames, renaming the extension. The blacklist match is a soft warning only — implementing the full Titleblacklist regex set client-side is an order of magnitude more work than this task warrants and Commons enforces it server-side anyway.

Implementing now.

Let's make the yellow uh because the you the name is probably wrong appear also when the title sell is not selected.

Have al known camera prefix been added to cheque? if needed extend the list. Also audio recording equipment prefixes and file creation devices like video camera, ...

Daanvr renamed this task from title validation to Title column validation (!28).May 11 2026, 2:13 PM

Iterated per feedback (2026-05-11):

  1. Soft warning is now visible without selecting the cell. recomputeIssues adds a title-format-warning code when validateTitleLocal returns severity=warn; the cell picks it up via a yellow tint (.tbl__td--title-warn) plus an inline warning icon, and the row's status-dot tooltip lists it under 'Warnings'. Doesn't block publish (BLOCKING_ISSUE_CODES unchanged).
  1. Camera-prefix list extended from ~13 to ~80 patterns. Cross-referenced the live Commons title blacklist plus added audio recorders (Zoom, Tascam DR, Sony PCM, Olympus DM/WS, generic REC/Voice/Audio/Recording), camcorder/dashcam containers (MAH, MAQ, MOV, M2U/T, MTS, FILE, MDR, raw 00001.MTS), action/360/drone (GoPro GP/GH/GX/GS chapters, DJI alt forms, YDXJ Xiaomi/YI), more mobile-app patterns (WhatsApp Video, Snapchat, KakaoTalk, WeChat, Line, TikTok, Messenger received_…), and pure-junk titles ("untitled", "image_002", "photo1", "Scan 2023-…"). 41 warn cases verified, 14 real-title controls (Image Comics, Untitled by Banksy, PI Day…) verified clean — patterns anchor on prefix + digit/separator so legitimate titles starting with a prefix word don't false-positive.

Preview updated: https://upload-workbench.toolforge.org/mr-28/

The trailing space dynamic is still not working properly. Uh when I'm typing and I add a space it becomes red even though uh it should just silently um not warn me about its waiting space and remove it uh when I decide Select or one to save. Um so it should never warn me about a trailing space The same for all other characters that are not allowed to be the last character. These should be simply removed automatically whenever you deselect and checked for that they don't exist when saved Living. Or like publishing I mean. No, sorry. I do not mean me publishing. I mean saving the metadata to the user namespace

Iterated per feedback (2026-05-11, second pass):

Trailing/leading whitespace is now silently auto-trimmed instead of being flagged as a red error.

Concretely:

  • validateTitleLocal trims internally before applying the rule set, so the live editor view never lights up red for whitespace at the edges. Typing a word, hitting space, then typing the next word no longer flashes red between the two words.
  • The whitespace-edge error code is removed entirely. whitespace-double (mid-string runs of 2+ spaces) stays as a hard error — the user only flagged trailing/leading.
  • TitleEditor commits the trimmed value via a new cleanTitleForCommit helper (called from onCommit/onBlur/Enter), so a stray trailing space typed mid-edit doesn't get persisted to the user-store as a draft.
  • The detail-panel title input mirrors the same trim-on-blur behaviour, so the user's reported case (saving metadata to the user namespace) drops the stray whitespace before the debounced 3 s save fires.
  • Build green; preview verified — deployed JS no longer contains the "leading or trailing" message but still has "Two or more spaces".

Branch was rebased onto current main (v0.8.0); CHANGELOG [Unreleased] updated to reflect the new behaviour, version untouched (merger handles).

Preview updated: https://upload-workbench.toolforge.org/mr-28/

Released as v0.22.0 (MR !28 merged into main).