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

Strip blank morpheme forms on import and assert the invariant

Aperta
  • Qualcosa non va?
#324 0 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, data

Direzione di ricerca

Per prima cosa risolvi la decisione sul parsing misto con #317. Poi esamina bareWordAnalyses.ts e clusterAnchoring.ts, preservando parseLexemeKeyId, e segui il passaggio di validazione proposto in #140. Il lavoro è completato quando le forme vuote non possono raggiungere né lo store né l’editor, il report di importazione conta i dati scartati e l’invariante viene asserita.

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

Descrizione

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.

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

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.