Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Wire the output project (back-translation / adaptation) into export, not creation

Aperta
  • Qualcosa non va?
#149 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend-api-design, frontend

Direzione di ricerca

Leggi src/types/interlinearizer.d.ts, in particolare la documentazione di targetProjectId alla riga 291, quindi segui updateProjectMetadata, il modal dei metadati e DraftProject. Risolvi le questioni relative alla denominazione del campo e al riutilizzo di targetProjectId, fai passare interlinearMode opzionalmente attraverso gli aggiornamenti dei metadati e Save As, e assicurati che il modello documenti sia i significati di allineamento sia quelli di esportazione, senza modificare la creazione dei progetti né implementare write-back.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Follow-up to #94 — resolving the second and third model gaps (interlinearMode and the targetProjectId semantic question): model the interlinear output (a back-translation project or an adaptation/daughter project, PT9 Options 3 & 4) as a deferred, attach-when-you-export concern — not a mode chosen at project creation.

Design principles this follows

  • Simplify project creation — you don't declare "this is a back-translation project" up front. A project starts as just gloss a source; an output target is chosen later, only if and when you produce output.
  • Generalize the interlinearizer — a project isn't locked to one output kind or destination. An output target is attached, changed, or dropped at will, and the same analysis can serve gloss-only use or feed an export.
  • First-contact discoverable — the output picker and its intent (BT vs adaptation) surface intuitively at export time, and aren't worried about before then.

Reframe

#94's original framing made the output a creation-time mode (PT9 Option 3 = back translation, Option 4 = adaptation/revision), each locking the project into producing a second project. This issue defers that:

  • The output target (a second Platform.Bible project glosses/adapted text are written to) is attached at export time via the project metadata modal, not at creation.
  • An output-intent discriminator distinguishes back-translation from adaptation, driving export behavior and UI wording — set alongside the output target, when it's chosen.
  • No creation-time mode picker.

Model additions

  • InterlinearProject.interlinearMode?: 'back-translation' | 'adaptation' (the #94 gap #2 proposal). Absent for gloss-only projects (PT9 Options 1 & 2) and for BT-Extension alignment imports; present only when the analysis is being exported to an output project. Consider naming it outputMode to reflect the reframe — see Open questions.
  • Resolve the targetProjectId overload (#94 gap #3). targetProjectId currently means "alignment target for a BT-Extension import" — an input whose AlignmentLink.targetEndpoints resolve to a second text (InterlinearProject.targetProjectId). The PT9 output project plays a structurally similar role (a second project + cross-side links) but the relationship is one-directional export, not two-way alignment. Recommendation: reuse targetProjectId for the output destination and let interlinearMode carry the intent that disambiguates the two uses. Update the field's JSDoc to document both meanings — including src/types/interlinearizer.d.ts:291, which currently documents targetProjectId as "absent for analysis-only projects (LCM, PT9)"; reuse makes it present on an imported PT9 project that has an export target.

The distinct cases the model must represent:

Case targetProjectId interlinearMode Notes
Gloss only (Options 1 & 2) absent absent source-only analysis
BT-Extension alignment import present absent existing bilateral-alignment use
Back translation (Option 3) present (output) 'back-translation' glosses exported to a BT project
Adaptation / revision (Option 4) present (output) 'adaptation' adapted text written to a daughter project

Where this gets consumed

  • Export/output feature (largely future work) reads targetProjectId + interlinearMode to decide what to write and where. This issue is about modeling the output so it's deferred and attach-later; the actual write-back to the output project can be built on top.
  • UI wording keys off interlinearMode (e.g. "Export back translation" vs "Update adaptation").
  • The metadata modal / interlinearizer.updateProjectMetadata already accept targetProjectId?; add interlinearMode? there (and mirror on DraftProject as targetProjectId is mirrored, so it survives Save As).

Companion issue

The model-text suggestion source is the sibling gap, tracked in #148: it defers the suggestion input the same way this defers the output. PT9 import shipped in #150; attaching an imported project's output/BT project is #215, which consumes this issue.

Out of scope

  • Building the actual export/write-back pipeline to the output project (separate feature work).
  • Model-text suggestions (companion issue #148).
  • Any project-creation UI changes.

Open questions

  • Field name: keep interlinearMode (traceable to #94) or rename to outputMode (clearer under the reframe)?
  • Reuse vs. separate field: reuse targetProjectId for both alignment-import and export-output (recommended, disambiguated by interlinearMode), or add a dedicated outputProjectId to keep the two roles physically separate?
  • Should this go to user-questions.md for review outside the dev team, given it decides project-output UX? (per AGENTS.md UX-decisions guidance)

Size: S–M (model fields + metadata-modal wiring; the export pipeline itself is separate)
Priority: P2 — unblocks a coherent output/export design; not blocking gloss-only use

Lingua principale
TypeScript
Stelle
2
Fork
0
Merge medio
2g 5h
PR unite (30g)
42

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sillsdev/interlinearizer-extension

Tutte le issue di sillsdev/interlinearizer-extension

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.