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

Strip blank morpheme forms on import and assert the invariant

Abierto
  • ¿Algo no está bien?
#324 0 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, data

Línea de trabajo

Primero resuelve la decisión sobre el parseo mixto con #317. Después inspecciona bareWordAnalyses.ts y clusterAnchoring.ts, conservando parseLexemeKeyId, y sigue el pase de validación propuesto en #140. Se considera terminado cuando las formas en blanco no pueden llegar al store ni al editor, el informe de importación contabiliza los datos descartados y se afirma la invariante.

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

Descripción

Per the decision on #285, blank morpheme forms are dropped at import rather than carried. This issue owns that change and the invariant it establishes.

What arrives today

PT9 files can carry a lexeme id with an empty form, and every check on our side counts keys rather than inspecting them, so the records reach the store intact. Observed in one small test project:

surface morphemes source
thanksgiving ["", "giving"] WordAnalyses.xml
thanksgiving ["", ""] WordAnalyses.xml
prayer [""] WordAnalyses.xml, from the id Stem::2

The import reported droppedEmpty: 0 and droppedUnparseable: 0 for all three. A cluster can carry them too (["Stem:", "Stem:giving"]), though in that project the cluster dropped for an unrelated reason.

What to change

Two conversion boundaries, each with a visible counter:

  • bareWordAnalyses.ts — its only rejection is keys.length === 0 (:54), which counts keys rather than inspecting them.
  • The cluster path — clusterAnchoring.ts classifies lexemes without looking at the form; a new drop reason belongs alongside unparseableLexemeId.

Leave parseLexemeKeyId alone. It is faithful to PT9's grammar, which admits Type: with an empty form, so rejecting there would make the parser diverge from what its doc comment claims to implement.

The one rule to decide

An all-blank parse drops cleanly — it states nothing. A mixed parse is the judgment call:

  • Drop only the blank morpheme, leaving ["giving"] for "thanksgiving" — but that fabricates a breakdown whose forms do not sum to the surface, which is #317's problem class, and worse because we would be creating it rather than importing it.
  • Drop the whole parse, which is more defensible and keeps the store free of breakdowns we would immediately flag.

Decide this together with #317, since both concern breakdowns that do not sum to their surface.

The invariant this establishes

Nothing in the store carries form === "" afterwards, and our editor cannot create one either — MorphemeEditor collapses and trims (MorphemeEditor.tsx:112) and TokenChip filters (:225). Make that explicit so a future import path or edit affordance cannot reintroduce blanks silently:

  • Assert it in the validation pass proposed by #140, alongside the invariants already listed there.
  • Keep the counters in the import report, so a project whose PT9 data contains zero morphemes says so rather than quietly shedding them.

Extensions are pre-release, so already-imported records need no migration.

What this makes unnecessary

Rendering work for blank forms. MorphemeBox.tsx:106 puts {m.form} straight into a grid cell and breakdownOf joins forms on a space, so both would need a placeholder glyph, a spoken label, and a #130-compatible normalization — three surfaces of upkeep for a state that can no longer occur. #130 also no longer needs a blank-form rule.

What is being given up

PT9 treats a zero morpheme as ordinary data: it renders one as an empty // slot in both the Interlinearizer and the Wordlist, auto-selects its sense as the gloss, lets that gloss be edited, and preserves it across its own saves. Stripping trades that away for a counter. #285 records the evidence should the decision ever be revisited.

Size: S.
Priority: P2 — no user-visible defect today, but it is the gate on #313's fold and on closing #285.

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

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.