Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#149 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend-api-design, frontend

Línea de trabajo

Lee src/types/interlinearizer.d.ts, especialmente la documentación de targetProjectId en la línea 291, y luego sigue updateProjectMetadata, el modal de metadatos y DraftProject. Resuelve las cuestiones sobre la nomenclatura del campo y la reutilización de targetProjectId, incorpora interlinearMode de forma opcional en las actualizaciones de metadatos y Save As, y asegúrate de que el modelo documente tanto los significados de alineación como los de exportación, sin cambiar la creación de proyectos ni implementar write-back.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
2
Forks
0
Merge medio
1 d 19 h
PR fusionados (30 d)
55

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sillsdev/interlinearizer-extension

Todos los issues de sillsdev/interlinearizer-extension

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.