2 product
william le roux edited this page 2026-04-01 16:51:37 +03:00

Current Product Scope

This document describes the product behavior that is implemented in the repository today.

What The Product Does Today

Iris Translation v2 is a governed DOCX translation workflow built on Django, Celery, Aspose-based DOCX processing, scoped terminology, translation memory, and a TMX-based review loop.

The current repository supports:

  • DOCX job intake with preflight inspection
  • extraction into anchored translation units
  • translation with either approved-memory reuse or a provider call
  • automated segment verification and document-level QA
  • TMX export for review and TMX import back into the job
  • final DOCX reassembly
  • glossary, project, provider-profile, and language-pair-policy APIs
  • candidate-memory capture from reviewed imports and promotion into approved memory
  • artifact listing and controlled download links
  • job comparison, review coverage reporting, and audit-event search
  • maintenance cleanup and integrity reporting for artifacts, candidate memory, and delivery gaps
  • a Django-template operator console for job operations and project coverage

Supported Inputs

Current supported inputs in the public API are:

  • source DOCX uploads for job creation
  • glossary CSV uploads for import
  • reviewed TMX uploads for human-reviewed job updates
  • JSON configuration updates for projects, provider profiles, and language-pair policies

Supported Outputs

The repository can currently produce:

  • serialized job records and job statistics
  • per-unit verification results
  • source, intermediate, review, replay, and delivery artifacts
  • reviewed TMX export files
  • replay ZIP packages
  • final translated DOCX files
  • project review-coverage summaries
  • audit-event search results

Supported Workflow Shape

The implemented workflow is:

  1. intake and preflight
  2. extraction
  3. translation and verification
  4. automated QA finalization
  5. optional TMX export/import review loop
  6. reassembly to final DOCX

The workflow can run:

  • synchronously through the job action endpoints, or
  • asynchronously through Celery when async workflow is enabled

Knowledge And Governance Features Present Today

The repo currently includes:

  • domain-pack, project, and language-pair-policy scoping
  • provider profiles for named translation runtime configurations
  • glossary scope precedence across domain, project, and document family
  • candidate-memory capture from reviewed TMX imports
  • explicit promotion from candidate memory into approved memory
  • per-job policy snapshots and statistics snapshots
  • audit events for workflow and control actions
  • operator/admin access control on the JSON API

Current Hard Scope Boundaries

These are true of the current repo and should be treated as present-day constraints:

  • the public intake API is DOCX-only
  • review import/export is TMX-based
  • the checked-in runtime defaults to a local-development PostgreSQL/Redis/MinIO/OpenSearch stack, with SQLite kept as a fallback
  • the checked-in Docker stack is a local dev stack, not a finished production deployment shape
  • the current supported operator surfaces are the Django-template console and the JSON API, while Django admin remains internal-only

What Is Not In Scope In The Current Repo

The repository does not currently implement:

  • non-DOCX source intake
  • a separate SPA or standalone frontend beyond the Django-template console
  • built-in multi-service production deployment manifests
  • Django admin as a supported day-to-day operator workflow

For scaling guidance, see Operations And Scaling. For unresolved product or delivery decisions, see Open Questions.