This is the canonical repository contract for workspace statuses and their UI behavior. It guides implementation and regression checks; it does not establish that these changes have been deployed or verified on the hosted editor. User workflows are described in the Editor Guide, Import Workflow, and Cloud Backup guide.
Calculate a loaded file's statuses for the current game, branch, accepted source version, content group, selected translation language, and active local/account profile. Changing any of these must use the new scope's data. Thai saves, dropped copies, and counters must not appear as German work, including for an Admin assigned Thai who selects German. Explicit content groups also isolate work when two versions use identical original bytes; legacy scopes retain their existing identities.
The immutable parsed original ZIP baseline supplies English, entry metadata, and original translations. Preserve it separately from staged work. Saving, restoring, importing translated work, and receiving shared edits must not rewrite it or change its source identity. A new source import establishes a new baseline.
The current committed translation is the complete staged SD translation for this file, language, and source version when one exists; otherwise it is the original ZIP translation. A complete stage identical to the ZIP is still Saved. An absent original language tag is distinct from a present language block with an empty array or blank entries. Invalid legacy stages remain recoverable but are excluded from active Saved text. Unsaved editor typing is a draft and must not change workspace counts or export data.
Both inline and full editors retain translation drafts locally under their profile/account, game, accepted source, language and filepath. Drafts have no badges, counters or dedicated status filter. Actionable editor findings describe unsaved editing state; they are not Saved, Error or Warning workspace statuses. Displaying draft text in a row must not replace its committed descriptor or make Lookup, exports, manual scans or collaboration treat it as committed text.
A dropped copy is a separate unresolved frozen snapshot of translation text with its original baseline identity and filepath. API SQLite retains the target and lifecycle; historical English and entry metadata resolve from that matching ZIP or verified client cache where available. Never reconstruct an existing dropped target from the predecessor's mutable current stage. A valid current ZIP translation may coexist with a dropped copy. Missing old English must be reported as unavailable rather than reconstructed from the new source. The owner's SD source trust decision favors the immutable ZIP over SQLite, 10:1; losing optional old source does not discard a frozen dropped target.
Dropped ownership follows its version chain. A Local recovery belongs to the browser's standalone import chain; Shared Dropped belongs to the online chain accepted by the API. Both can be available for the same current file, including identical text, with independent candidate IDs, assignments, revisions and dispositions. The selected workspace's ownership drives Dropped counts and Revised eligibility; an extra Local recovery in an online workspace is a recovery choice, outside its managed assignment workload. Explicitly opened online work retains its online identity when cached or opened while disconnected. A matching source hash or automatic catalog association alone does not convert standalone work into online ancestry.
Shared translation rooms use game + branch + accepted source baseline + language. Local profiles, unsaved drafts, and queued operations retain their account scope; queued work also retains its original game, branch, language, source version, and access context. Switching accounts or versions must not publish an old operation in the new scope. Dictionaries are shared by language, independent of game and source version. Translators synchronize their assigned language; Managers and Admins synchronize the selected language with or without an assignment.
Online/offline catalog association, HEAD, import deadlines, ended windows and withdrawal are version metadata, not translation statuses. Manager dashboards derive the same content statuses from server-accepted work; unsaved drafts and pending local saves are outside their counts and collection snapshots. The Progress column displays Saved / (Missing + Saved), with ordinary Saved in green, the Revised subset of Saved in purple, and Missing in red. The tooltip states the counts and overlap: Revised is included in Saved; absent SD language tags are Missing only, while present incomplete blocks are Missing and Error and cannot become Saved. This progress denominator is a workload indicator, not a count of distinct files or overall baseline completeness. An empty workload has a neutral bar. Ended badges belong beside version/team names rather than a separate status column: translators see their assigned team's window; Managers/Admins see a catalog version as ended only when every team has ended. The current version name/hash opens the chooser from the workspace status bar and full editor heading. The workspace deadline follows Saved counts, and hover/focus details retain deadline, ended and withdrawal guidance. Ended is a warning before editing and does not mutate Saved/Missing/Dropped/Revised or the already collected ZIP.
Dictionary entries use gameScope (poe1, poe2, or all; legacy absence means All) while the complete Dictionary remains language-shared. Automatic matching uses only the current game's entries and All fallbacks. A current-game entry overrides the entire All entry with the same normalized main Find, including its alternates. Other-game rows remain visible with a warning but do not contribute autocomplete, highlighting, keyword/Regex replacements, terminology findings, or matches-first ordering. Each row retains a unique internal ID; duplicate Find/keyword identifiers across games are separate records.
| Status | Derive from | Color |
|---|---|---|
| Missing | The selected committed language block is absent, contains a blank/whitespace-only line, or has a different entry count from English | Red |
| Dropped | An unresolved dropped copy owned by this workspace's chain exists for the loaded file and selected language | Orange |
| Saved | A complete staged translation exists for this file, language, and current source version; every SD entry contains nonblank text | Green |
| Revised | Saved text differs from the complete immutable original ZIP translation and the file has never belonged to this source version's Dropped workload | Purple |
| Error | A present committed SD language block is incomplete, or the active/completed manual scan reports an error | Red, matching Missing |
| Warning | The active or completed manual diagnostic scan reports a warning for the file | Orange, matching Dropped |
| Unchanged | Current translation is complete, with no staged translation and no unresolved dropped copy | Neutral |
Use these color relationships in every supported theme and in list labels, filters, and workspace counters. An absent immutable selected-language tag produces Missing only. A present language block with any blank entry or a count mismatch produces Missing + Error immediately without a scan. Use immutable tag presence, not the editor's padded empty fields. A diagnostic error need not imply Missing or Dropped. Warning remains a manual diagnostic status. Unchanged is neutral rather than a completion-success color.
An SD file with even one empty or whitespace-only quoted translation is invalid as a whole, including files with other useful translations. Table/newline separators and Unicode formatting characters alone are blank. Entry count must match English. Save, translated import, history restore, promotion, carry-forward, collaboration and new exports/collections enforce this rule. Validation does not rewrite meaningful whitespace or table fragments. Original ZIP content stays immutable and readable: an absent selected-language tag is Missing only; a present incomplete block is Missing + Error until complete staged text replaces it. Full export preserves an untouched absent tag without synthesizing an empty translation block. Drafts and promotion candidates must be complete before staging even when their baseline tag is absent. ClientText blank fields remain supported.
The same rule applies to creating or loading Dropped copies. Blank or incomplete preserved SD targets belong in recovery archives, outside active Dropped work and its assignment counts. Browser activation and API schema v25 quarantine existing invalid copies while retaining their exact snapshots, candidate identities, provenance, queued request evidence and history. Quarantine never changes a complete current translation or a valid independent recovery copy. Stale imports and compact responses cannot reactivate a quarantined generation. Invalid recovery archives do not automatically restore editor drafts.
Check preserved targets against their original entry count when retained English or accepted origin facts establish it. A complete older layout remains valid Dropped work when the destination count changes; alignment is still required before saving against that destination. Historical source loss alone does not establish incompleteness. Nonblank target-only copies with an unknown original count remain recoverable for explicit review; legacy destination English copied into an unknown-origin record is not evidence of its original layout. Deploy API v25 before the frontend and reload older tabs; retain existing storage.
Browser v19 and API schema v21 remove invalid active SD stages regardless of their origin, retaining exact old text and scope in recovery archives and immutable history. Local drafts remain editable; rejected pending submissions/operations retain their IDs and payloads for review and cannot upload. API resets advance revisions and send recovery evidence to peers, so reload cannot restore Saved from an old room cache. Existing receipts replay idempotently without authorizing a new invalid save. Frozen historical collections remain retrievable; new captures require complete SD work. Existing v19/v21 data derives language-block presence from immutable baselines or verified baseline facts, replacing cached status interpretations without a schema/version bump. Deploy API v21 first, then browser v19 and reload older tabs.
Revised identifies corrections outside this version's Missing/Dropped assignment workload. Original ZIP completeness establishes Missing eligibility; becoming complete after a save does not change it. Compare staged text to the immutable ZIP translation, never to the preceding save, a history entry, or a dropped snapshot. Returning an eligible file exactly to its ZIP text removes Revised while retaining Saved.
Dropping a file in this version permanently excludes it from Revised for this version and language, even after confirmation, replacement, or discard. Preserve version-specific assignment provenance, not a permanent file-wide exclusion. A new source version recalculates eligibility against its new immutable baseline.
ClientText Hide DNT entries filters individual immutable English fields, including marked formatting payloads, while preserving ordinary siblings. It changes visible/search/navigation/manual-scan fields and matching row totals. Existing ClientText Loaded/status counters, assignment progress, sheet colours and exports continue to include their original committed field facts; hiding does not redefine accepted workload. Gender remains attached to visible prose, and all-hidden rows leave the result list. Raw drafts and reviews survive toggles and guarded navigation. See ClientText DNT visibility for exact detection rules and local evidence. The SD whole-file eligibility rules below remain unchanged.
ClientText MTL candidates are separate review obligations, outside committed translation statuses. Generating or editing a suggestion must not set Saved, Revised, Source reviewed, normal draft values, TM entries or export values. Accept explicitly transfers the reviewed text to an ordinary draft; normal Save commits the selected candidate's resolution atomically with authored work, history, outbox and receipt. Dismiss leaves underlying translation and source review unchanged. MTL counts/dots appear only above zero, overlap existing statuses and do not change assignment progress. Exact raw source changes silently hide inapplicable candidates. See ClientText MTL for storage, lifetime and export rules.
Under trusted ClientText storage, the browser derives original field facts and workload summaries. The API accepts those facts with scoped work instead of retaining a full per-ID baseline catalog. It maintains accepted counts and freezes collections transactionally; these are client-derived content calculations, with server-enforced identity, revision and receipt rules. Drafts and pending uploads remain outside accepted counts. Original facts come from the immutable workbook, not mutable editor status flags.
ClientText uses immutable workbook fields and per-ID saved records. A unit is one record identified by workbook role, sheet name and ID; each named text or grammatical-form field has its own status. Missing is a required committed field still needing translation (red). A valid active source-bound Use English decision intentionally resolves its blank target; raw target emptiness is internal metadata, not a second visible counter. Revocation, source changes, suspension, ineligibility or a genuine conflict return the field to actionable Missing. Outdated is an original orange field or a carried English-source change whose current source hash has not been reviewed (orange). Every ClientText field, including text, forms and Gender, accepts empty or whitespace-only values in saves, restores, synchronization and exports. The required field fact determines Missing workload only; it never imposes nonblank validation. NONEXISTENT is a supported whole-cell form value. Gender is raw text metadata with suggested values, rather than translated prose; arbitrary values and exact whitespace are preserved.
Saved means an explicit durable save exists, including unchanged or intentionally blank values. Revised means a saved field differs from its complete original translation outside that field's original Missing/Outdated workload (purple). Eligibility is per field: correcting a complete field can make its row Revised even if another field is Missing. Reverting that correction removes Revised while retaining Saved. Source-only carry records preserve Outdated/review facts with saved: false; they must not manufacture Saved or Revised work. Row counters overlap. Editor and assignment progress use resolved initial workload fields / all initial Missing/Outdated workload fields, counting each field once. Explicit active Use English decisions resolve assigned fields; unmarked blanks remain unresolved. Missing + Outdated overlap appears once as Outdated work until reviewed, then stays Missing if it is blank without an approval. Complete-field corrections outside the initial workload remain outside the denominator. An assignment with no workload is neutral. Original workload summaries and source fingerprints remain unchanged; the API derives accepted Missing and resolved counts from sparse decision metadata, with no source catalog or data migration.
Recognized class variants (StrFour, IntFour, DexFour, StrDexFour, DexIntFour, StrIntFour and their b variants) are independent form fields in the v2 workbook parser. Each shares its identified English source but retains a separate target, review hash, original fill and identity. An unmarked blank variant is outside Missing workload, including after English changes while that variant stays unused; a direct red mark contributes Missing workload, and a direct orange mark requires review. A carried nonempty target still requires review when English changes. Switching tabs or collapsing defaults never removes fields from atomic saves, workload, history or export. TM and consistency matching keep each exact form separate.
Saved remains a durable-work status and filter even when a record also has Missing or Outdated fields. Green row completion requires every required committed field to be translated or resolved by valid Use English, and every applicable source review to be current. Missing colors the entire row red; otherwise Outdated colors it orange. Optional blank fields and fields with no active English retain their existing workload exemptions. Saving one field never completes another field's workload or removes the record from attention navigation.
The ClientText Sheets list and affected exported workbook tabs aggregate field colours in this order: red → orange → purple → green → grey → no colour. These mean Missing, Outdated, eligible revisions, reviewed sources, completed original Missing work, and unmarked content. Use English completes original Missing work with existing grey, reviewed Outdated work with existing green, or an eligible authored correction with existing purple; it does not invent a color. Grey is distinct from the ordinary uncoloured sheet style: complete original text and unchanged complete saves remain uncoloured unless a recognised completion fill is already present. Unused optional blanks and unrelated original formatting do not manufacture completion. The sheet list uses committed content across all rows, including rows hidden by filters, and additionally retains red/orange manual diagnostic findings above completion colours. Export ignores those diagnostic findings. This visual distinction does not add a status, change Saved/Revised counts, or change NPC/Convo severity navigation.
Parser v3 retains v2 class variants and adds Turkish Normal Translation/Possessive Translation forms for BaseItemTypes Display Name. A blank Normal contributes Missing workload when English is active; Possessive follows existing form-workload rules, including orange blank Outdated without Missing. These named forms treat NONEXISTENT as literal text without sentinel completion or diagnostic exemptions. Styled shared-string cells without a value element remain blank with their original fills. Existing accepted v1/v2 groups retain their original field interpretations and fingerprints.
Changing English never creates ClientText Dropped work or erases an authored translation. Stable role/sheet/ID/field identities drive three-way carry-forward: a local-only change survives; competing local and upstream changes keep the incoming value active and preserve the local alternative for an explicit choice. Removed records and fields remain in the previous version/history, outside the new active export. Review applies to the exact current source hash; stale reviews cannot clear Outdated. Editing or Mark reviewed is a draft action until Save commits it.
One exact audio metadata prefix ([NOAUDIO], [NO AUDIO], [OLD AUDIO], or [AUDIOTEST]) is ignored for source equivalence, with at most one leading space and one following separator removed. Repeated markers, including mixed audio markers, other whitespace and all remaining characters stay significant. These exact markers are optional in translations and excluded from keyword identity, terminology checks and completion suggestions. Raw workbook cells are preserved. Verified predecessor/current originals can establish unchanged dialogue and record a review against the current field fingerprint; persisted v1/v2 source fingerprints retain their original [NOAUDIO] normalization for compatible facts, reviews and proofs. Marker-only [NOAUDIO] source fields retain their existing translation workload exemption; the immutable parser/fact contract is unchanged. Normal text, actual newlines, literal \n, and @ remain distinct raw content.
Manual Error/Warning results remain separate from content statuses. ClientText checks numeric substitutions, <<…>> icons/keybinds, bracket link identities, <continue> controls and formatting structure while allowing localized brace contents. Differences in styling tags (i, b, u, size, colors, fonts and other recognized styles) are warnings because translators may adapt styling in place of punctuation; malformed delimiters and runtime-token identity mismatches remain errors. Unrecognized angle syntax is retained with a warning rather than guessed; it does not teach TM. A saved correction refreshes affected findings and consistency peers without clearing unrelated completed scans. The remaining Dropped sections below describe StatDescription recovery.
Explicit StatDescription source advancement compares the predecessor's saved text with the incoming immutable baseline for every staged language. Identical English, translation and entry metadata need no inherited save: the incoming ZIP is already the exact committed content. Explicit unchanged saves in the same source version remain Saved. Reimporting a version with existing work preserves that destination's saves; competing predecessor work remains recoverable for review.
When the English strings match but metadata outside the quoted translation changes, carry the saved translation with the incoming English name, stats, variables and remarks. Keep it Saved and show Metadata updated with the old/new fields in the import report and full editor. Derive this indication from source-carry facts and current metadata, never a persisted status boolean. Changed English or an incomplete incoming translation with nonblank predecessor text creates a separate Dropped copy before metadata carry is considered. Removal of an entire filepath from the verified incoming source is authoritative: do not create or carry a Dropped copy, recovery alternative or review assignment into the new version. Earlier-version saves and history remain in their original scope. Existing removed-file recovery records are physically deleted during scoped activation after verification against the matching ZIP or a complete accepted browser baseline. Previous-version Saved work and history remain intact; legacy candidates assigned to another version keep only that valid assignment. Text-free recovery receipts retain their original hashes. The review freezes the predecessor target and its original source reference; historical English and metadata resolve from the exact matching ZIP or verified client cache when available.
Browser v18 removes proven redundant inherited saves on scoped activation, retaining the original record in a recovery archive. Comparison pads absent or short translation blocks with empty English-entry lines, just as the editor displays them; it preserves whitespace and extra entries. Cleanup revisits earlier completion checkpoints to remove inherited blank padding and recover inheritance evidence lost to an unchanged first shared snapshot. Repeated accepted snapshots preserve the original local save time and before text. Per-file recovery archives prevent a cached initial merge from restaging already-cleaned work. Metadata corrections, Dropped assignments, explicit saves in the destination version, pending operations and ambiguous legacy records are protected. The API v20 counterpart uses cleanup checkpoint v2, verifies retained originals or identical accepted per-file baseline hashes and publishes revisioned staging resets for proven automatic carry records; it retains immutable history, events and receipts. For an older standalone initial merge, the browser can relay its proven predecessor identity and affected original file witness. The API verifies that witness against an accepted predecessor baseline, compares identical English and metadata against trusted immutable current-file facts, and retains only server-authored hash pointers. That provenance-relay path requires a matching accepted predecessor save. Browser v18 also discovers unopened legacy predecessors and uses retained authored timestamps plus pre-join recovery when no frozen current aggregate exists. Its revision-checked initial-merge repair lets the owner correct proven local inheritance into a standalone version without a server predecessor; another actor still requires accepted predecessor evidence. The API checks exact current baseline content, predecessor English/metadata, receipts, uploads and Dropped assignments. Rejections and newer work retain authoritative Saved stages with their protected revision. Explicit server saves and ambiguous records remain protected. Deploy this API capability before the v18 frontend. Cleanup does not rewrite a baseline or frozen collection.
Dropped copies can survive across source imports within their owning chain, scoped by game, branch, language, file and applicable content group. Local imports preserve local copies in browser storage; managed advancement derives shared copies from the managed predecessor. Local imports, local assignment extensions and local discards never upload automatic candidates or modify online assignments. If local advancement leaves an online workspace, it retains the old online record and creates an independent local snapshot for its successor. Their original and target source identities remain provenance.
For Revised eligibility, retain evidence of the versions in which that file was actually assigned Dropped. Only a copy with durable assignment evidence for the selected source and branch belongs to that version's Dropped workload. Explicit source advancement extends an unresolved predecessor assignment to its successor; promotion, discard, reload and synchronization preserve established assignments. Ordinary selection/activation of a named version, room joining or receiving another version's candidate cannot add a target or upload new assignment provenance. Resolved cloud receipts preserve the same exclusion when the assignment is known. A resolved record belonging only to an unrelated earlier version must not exclude an otherwise eligible file in the current version.
The workspace model records this provenance in a candidate's targetSourceHashes list. Preserve that list through active copies, resolved archives, aliases, and cloud receipts within the same owner. Never merge Local recovery assignments into Shared Dropped, even when their preserved text is identical. It records assignment history rather than an authoritative UI status flag; the current status remains derived by WorkspaceState.workspaceFile.
Do not infer all version assignments from the latest target hash, discard the evidence when resolving a copy, or treat every historical dropped record as a global exclusion. Cross-browser correctness requires durable, synchronized assignment provenance; an in-memory cache alone cannot establish it. This is a persistence/sync requirement, not a claim that an older deployed API supplies that evidence.
The companion API persists targetSourceHashes for active candidates and resolution records (schema v11), explicit-recovery generation receipts (v12), and branch-scoped managed versions (v13). The schema-v24 separate-v1 ownership capability accepts a new client-created online generation only for an explicit recovery carrying a stable recoveryId; managed automatic generations come from server advancement. Existing accepted generations, old retry bodies and resolution receipts remain recoverable. Promotion records the actual target room's source hash in the same transaction as the saved translation and history. Listing with includeResolved also returns superseded generations as provenance records without their snapshot payload. Legacy records recover only target hashes supported by retained evidence; an unknown old target stays unknown. Deploy this API capability before the browser-v22 frontend.
Save stages a replacement; Confirm unchanged stages the selected dropped translation. Both resolve that copy together with the staged write. Discard resolves it without staging. Validate the current source, candidate revision, and shared file revision before committing. A failed durable write or stale conflict decision must preserve recoverable content and the editor draft. None of these actions removes the version's Dropped assignment.
The full editor exposes both owners as labeled recovery choices. Using Local recovery reviews its frozen text against the current immutable source and saves through the normal completeness and revision guards. That save may enter collaboration as an authored translation, while the online Dropped candidate remains unresolved until explicitly selected and resolved. Discarding either owner leaves the other available. Historical English that cannot be loaded remains unavailable; it is never substituted with current English.
When an online workspace attaches a Local recovery from the matching standalone workspace, it retains a scoped link to that local candidate. Resolving it updates the local disposition and destination save atomically, with revision and exact-snapshot checks, so returning to the standalone workspace cannot revive the copy. This does not change the standalone workspace's staged translation or history. A changed local snapshot rejects the destination action and retains both recoveries for a fresh decision.
Within the same online owner, consolidate competing copies automatically when game, branch, language and filepath agree, and the preserved English and translation arrays match exactly, including whitespace and line breaks. Metadata, original archive hashes, source availability, candidate IDs and candidate revisions alone do not require a choice between identical text. Local and online owners always retain independent lifecycles. Active variables, remarks, stats and name always come from the immutable current baseline, including saves, shared hydration and exports. Retain differing original snapshots and provenance in recovery storage while adopting the canonical shared receipt. Keep assignment provenance, recovery receipts, and any already staged save. Consolidation alone does not stage or approve an unreviewed dropped translation. An existing reviewed promotion of the same text may resume with the canonical candidate's current ID/revision and its original shared-file revision guard; a concurrent change to the actual saved translation still requires conflict review. An equivalent resolved receipt must not recreate an unresolved copy. Different English or translation text, unavailable comparison evidence, or a saved operation following an explicit decision about different text still needs review.
Dropped synchronization and copy decisions list candidates across source versions within the selected game, branch, language and content group. Filtering the freshness check to the current source can hide the canonical competing copy and incorrectly reject every decision as stale. Listing alone does not create assignment provenance for the selected source.
Synchronization also revisits retained candidate_conflict, needs_candidate_review and legacy alias review flags, including operations whose conflict row is absent. Resume an already saved promotion only when its original captured dropped text matches the canonical copy, the durable stage still matches that queued save, and no later operation supersedes it. Keep its mutation ID and original shared-file revision guard. An uncertain prepared request replays its exact original bytes; only a definite rejection permits preparing a replacement request. Missing evidence, different text, newer saved work and scope changes remain protected. Clear a failed copy-decision notice only after the same scoped file has no remaining copy conflict or queued review action.
When an older conflict only reflects a Local recovery and Shared Dropped competing for one slot, retain the complete conflict in droppedConflictArchive and expose the two independently owned snapshots. This removes the obsolete cross-owner block without erasing its request or recovery evidence. Existing collaboration rooms, edit events, attribution, history and durable receipts keep their identities. Browser v22 fences earlier pages and workers that could coalesce owners; it preserves the existing stores and data.
API schema v23 retains a scoped hash of exact preserved English/translation arrays through resolution. Metadata and origin variants therefore reuse a resolved automatic generation without restoring its payload or resurrecting Dropped work. Stable explicit-recovery receipts continue to bind the complete original request; a new explicit recovery action can still create a new generation. Migration fills hashes only from retained snapshots, keeping older tombstones without such evidence on their existing exact-fingerprint behavior. Deploy the API before this frontend.
An explicit history recovery may create a new unresolved generation even when identical text was previously promoted or discarded. Capture one stable recoveryId for that user action, retain it through the initial queued upload and retries, and preserve the older resolved generation. Retrying the same action must return its original generation, even after resolution; it must never resurrect it. Another unresolved copy still requires revision-checked conflict resolution. Ordinary migration, imports, peer retargeting, and provenance uploads deduplicate resolved content and must not request a new recovery generation.
Statuses overlap. Revised implies Saved. SD Saved requires completeness and cannot also be Missing. Dropped can coexist with Missing or with a complete current translation. Diagnostic findings can coexist with any applicable content status, including Unchanged. A file originally assigned Missing or Dropped may remain Saved without Revised after many later corrections.
Workspace counters count files, not entries or actions. Missing, Dropped, Revised, Saved, Error, and Warning count eligible loaded files under Hide DNT entries, independent of the search and selected status filters. Loaded counts all loaded files. The pagination/result total counts files that match both the search and selected statuses. Adding overlapping counters does not give the number of distinct files.
A file is DNT when any selected English entry starts with [DNT or DNT , including a marker after an ordinary first entry. Hide DNT excludes the whole file from workload counters. Manager dashboard counts use this same eligibility rule; older stored first-entry-only eligibility must be corrected from the verified original baseline. DNT eligibility does not change source identity, staged translations, history or collection snapshots.
Status filters combine with OR and never duplicate a file. No selected statuses means no files. Unchanged is the final filter and starts off in ordinary worklists; the other status filters start selected. ClientText NPCs browsing starts with all statuses selected so related complete dialogue remains visible, and keeps its filters separate from Sheets during the active workspace session. NPC membership and result counts are derived browsing data; they do not change workspace statuses, workload counts or progress. The SD footer order is Loaded, Missing, Errors, Dropped, Scan warnings, Revised, Saved. Errors combines present incomplete committed blocks with active/completed scan errors. Absent committed language tags are excluded from Error counts. Scan warnings appear only during a scan or while completed results remain available.
The dropped-conflict warning links to a hidden filter for the selected account, game, source version, and language. Include competing dropped copies and queued promotions awaiting a decision or fresh review, including Saved files without an active Dropped copy. Clear text search on activation and include affected DNT files without changing the Hide DNT setting or workload counts. For files absent from the current source, offer comparison and guarded copy selection without staging or adding them to the loaded-file counts. Exiting this filter restores the normal defaults. Resolve matching files from live conflict and retry state; do not persist a conflict status flag.
Manual scans use the selected checks, current language, and Hide DNT eligibility across all loaded files, including files hidden by search or status filters. Absent committed SD language blocks contribute neither blank errors nor empty consistency variants. A staging reset removes the previous variant without indexing padded empty fields; a later complete save becomes eligible for comparison again. Authored draft and promotion-candidate validation remains strict. Scan errors and warnings are separate from automatic editor checks and save guards.
Keep completed scan results and their selected checks while correcting translations. A local save, restore, shared translation update, or consistency correction refreshes affected files and any relevant consistency peers; retain unrelated results. Unsaved draft diagnostics belong to the editor and do not rewrite committed workspace statuses.
Inline focus loss attempts promotion using the full editor's save checks. Errors block promotion; warnings may require explicit acceptance. Blank SD entries and entry-count mismatches have no save-anyway confirmation. Declining keeps the draft and its findings below the filepath. Moving into that file's tools or helper popup retains the editing session. Dropped approval, competing copies and comparison-based decisions require the full editor or their existing resolver; inline promotion must never implicitly resolve Dropped.
Excess translation entries require whole-entry alignment in the full editor before ordinary editing or saving. Align each block once to current English, explicitly leave new entries blank, and explicitly mark leftovers unused. Unique exact preserved-English matches may be suggested; duplicate or unavailable old source must not be guessed. Applying alignment changes only the scoped local draft. Its original blocks remain in the draft checkpoint until Save writes before-alignment local history together with the staged translation, checkpoint consumption, outbox and receipt. Dropped alignment uses the existing guarded promotion on Save. Immutable source and Dropped snapshots remain unchanged during alignment; blank aligned targets must be completed before Save.
For an unstaged original with excess translation blocks, shared collaboration uses a source-count baseline view while local recovery retains every original block. Save guards recognize those two exact representations of the verified immutable original at revision zero. This equivalence does not apply to staged work, newer shared revisions or changed original text, and does not rewrite draft checkpoints or queued retry bodies. Completing alignment can therefore save and promote the selected Shared Dropped copy without a false committed-text conflict.
Changing language, the Dictionary, Hide DNT eligibility, or the imported workspace clears scan results without starting another scan. Translation changes invalidate an unfinished scan. Stop scan clears partial results. Clearing or stopping a scan removes manual findings. Intrinsic SD completeness errors remain visible; Missing, Dropped, Revised and Saved are unchanged. The scan result list is titled Files with findings.
Persist immutable baselines, staged text, dropped snapshots and assignment provenance, and factual metadata/history. Derive status booleans from those records. UI descriptors may cache derived values for rendering, but cached isMissing, isDropped, isRevised, or hasChanges values must not become authoritative workspace data.
Saving atomically commits staged text, history, any collaboration outbox, its durable receipt and consumption of the exact associated recovery checkpoint revision. A valid Save does not need to create a private draft first. Inline and full-editor typing still receive compact, per-file local recovery checkpoints; invalid or declined edits remain recoverable. Publish committed UI only after acknowledgement. Newer typing remains a draft; retries reuse the original save identifier. Cross-tab draft conflicts and changed committed bases preserve recoverable drafts and require a new decision. Source/profile changes keep older drafts in their original scope for explicit recovery, without retargeting or uploading them automatically.
Deferred saves first retain a durable submission in their captured account, game, branch, source and language. The editor prepares and paints the destination before dispatching queued work. Reload resumes submissions under their original identity, subject to current scope/access and base guards. Committing a submission removes it in the same transaction as its save receipt. A rejected stale-base or conflicting-draft submission preserves reviewable text and cannot silently overwrite newer work. Network synchronization starts after local acknowledgment; pending submissions remain outside Saved counts and exports.
Older workspaces may use needsReview, trackedForExport, hasChanges, or language status flags. A one-time migration can use that evidence to recover staged work and dropped snapshots in the correct language. Preserve recoverable history and identify unavailable old source text. Historical Needs Review labels and older wire compatibility fields may remain; they do not define a new persisted UI status. “Review” remains an action word, not the current status name.
IndexedDB v9 adds separate scoped records for immutable baseline files/assets, workspace metadata, staged files, Dropped recovery, checkpoints, collaboration state/operations, submissions and receipts. Ordinary one-file transactions touch only that file's records. Complete workspace/source/room views are materialized for consumers instead of written back as aggregates. Readiness markers make normalized absence authoritative: deleting staged work must not restore it from a legacy snapshot.
The upgrade retains all earlier stores and freezes old aggregate records as recovery evidence. Conversion runs in resumable, bounded batches; failed or interrupted conversion leaves the scope unready and retains the original content. Preserve source identities, staged presence, history ordering, IDs, receipt signatures, draft variants and Dropped assignment provenance. Do not dual-write old aggregate records or clear storage to bypass a failed conversion.
Open older connections close for the upgrade, and later v4/v5/v6/v7/v8 opens/writes fail with VersionError. v4 cannot read staged records; v5 can mistake a shared saved-status reset for a new staged save; v6 Dictionary normalization drops game scope; v7 writers overwrite a single per-game slot and cannot preserve named-version/account isolation; v8 writers can overwrite aggregate state after per-file conversion. Pending older transactions finish before upgrade. Per-game slots retain their owner's default-branch recovery evidence. Dictionary pending requests, save/draft receipts and recovery archives retain their IDs and payloads. A blocked upgrade asks users to close other editor tabs and reload; never clear storage to bypass it. This browser refactor adds no API contract or schema requirement. Existing API compatibility requirements for game-scoped Dictionary and managed storage remain; reload older tabs after frontend rollout.
Legacy migration compares translations after adding the editor's empty placeholders up to the English count. An absent ZIP language block and its display-only blank lines do not create Saved work. Browser v19 additionally quarantines every incomplete SD stage, including explicit old saves. Complete unchanged saves retain Saved; additional entries are never truncated to manufacture a valid translation.
Before browser v19, a one-time repair corrected old inferred placeholders whose immutable ZIP has no translation block. It requires blank staged text with an empty before snapshot and no authored provenance, timestamps, translation history, save receipts, Dropped assignment, or explicit queued operation. A shared repair also requires evidence of this account's original local join. The workspace and retry state change in one storage transaction, and the original staged record is retained in a recovery archive. Local-only placeholders cease to be Saved; uploaded placeholders stay staged until the API validates and publishes the reset.
The API's placeholder-repairs operation requires a verified blank baseline and the requesting account's only file history event: an unchanged first automatic merge at revision 1. It protects later edits, confirmations, imports, Dropped promotions, and deliberate saves, including no-op saves. Historical room mutation receipts without an event are ambiguous and prevent automatic repair. Accepted resets keep the file and immutable history, advance the file revision and room sequence, and propagate stagingReset to every current client. Explicit saves after a reset are Saved again. This older repair remains conservative for complete work; browser v19/API v21 quarantine every incomplete stage and retain its raw recovery evidence. Deploy this API contract first, then the frontend; reload all older editor tabs. Local test results do not establish hosted correction.
Normal export includes complete staged Saved translations, including unchanged saves. Full export uses current ZIP/staged data and blocks if an included file has a present incomplete selected-language block. An untouched absent language tag remains absent in the export; editor padding must not become a new blank block. A complete current ZIP translation remains exportable alongside an unresolved dropped copy. Never encode a dropped snapshot as fallback current translation. Exporting does not resolve a copy, clear its assignment, or turn an unsaved draft into Saved.
Delete staged translation explicitly removes a staged record for the selected language after confirmation, restoring the immutable ZIP translation without applying draft save checks. Commit the deletion, before/after history, any shared retry operation, and durable receipt atomically. Preserve other languages, local drafts, dropped copies and their assignment provenance. Shared deletion uses a revision-checked reset; concurrent shared edits require a fresh decision, never a partial text merge. A later explicit save stages the file again.
These examples omit independent diagnostic findings:
| Original/current situation | Result |
|---|---|
| Complete original ZIP translation; never Dropped here; no save | Unchanged |
| Same file intentionally saved with identical ZIP text | Saved, without Revised |
| Same file saved with different text | Saved + Revised |
| Eligible complete original file submitted with a blank entry | Save rejected; committed text/status unchanged and draft retained |
| Original ZIP translation Missing; filled and saved, then corrected again | Saved, without Revised |
| Complete current ZIP plus unresolved older copy | Dropped; current text stays the ZIP text |
| Dropped copy confirmed or replaced, then corrected again in the same source version | Saved, without Revised |
| Dropped copy discarded; current complete ZIP then corrected in the same source version | Saved, without Revised |
| New version has complete original text, no Dropped assignment here, and only an unrelated resolved copy from an older version | A changed staged correction can be Saved + Revised |
| Thai staged work exists; Admin selects German with no German work | German statuses derive only from German data |
Do not interpret Revised as “edited twice,” “the previous save was complete,” “any changed Saved file,” or “the translation is complete now.” SD completeness is necessary for Saved, but a complete untouched ZIP translation has no staged save. Saved does not mean “different from ZIP,” “uploaded successfully,” or “exported.” Do not hide Dropped merely because current text is complete. Do not use a role's assigned language instead of an authorized Manager/Admin's selected language.