Strip blank morpheme forms on import and assert the invariant

オープン
  • 何か問題がありますか？
#324 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend, data

調査の方向性

まず #317 に関連する mixed-parse の判断を解決してください。次に bareWordAnalyses.ts と clusterAnchoring.ts を調べ、parseLexemeKeyId を維持しながら、#140 で提案された検証パスを追跡してください。空の形式が store や editor に到達できず、インポートレポートが破棄されたデータを数え、不変条件がアサートされれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
2
フォーク
0
平均マージ
1日 10時間
マージ済み PR（30日）
74

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sillsdev/interlinearizer-extension のほかの issue

sillsdev/interlinearizer-extension の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。