Alignment-based suggestions from a major-language model text

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
typescript
領域
data

調査の方向性

まず #148 を読み、A/B/C アラインメントの判断を確定してから、deriveTokenSuggestion と、それによって導入される modelProjectId のフローを確認します。manifest.json、projectStorage.updateAnalysis、AlignmentLink、および interlinearizer.useModelSuggestions 設定を調査します。アラインされたモデル単語からモデルバッジ付きの候補が生成され、永続化戦略と依存関係の順序について合意できていれば完了です。

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

説明

Split out of #148 (2026-08-12). #148 now covers the surface-form tier — a sibling interlinear project whose approved glosses match the source by surface form — which is ready to build. This issue covers the other kind of model source, which is not.

A major-language Scripture project (e.g. an English Bible) whose words are the gloss vocabulary. It is in a different language from the source, so surface-form matching does not apply: suggestions come from source↔model word alignment — source word → aligned model word(s) → suggested gloss.

Required for full PT9 interlinearization support (Options 1 & 3), which is a stated goal, so this is on the PT9 parity path even though #150's import pipeline does not depend on it.

The decision that gates this

#148 left the approach open, and it has not been answered. It should be settled before any code is written, because the three answers have completely different costs and completely different dependencies.

A. Seed from imported PT9 cluster→gloss data. PT9 already recorded which source word maps to which gloss; reuse that as the alignment. No aligner, no binaries, no licensing question.
Cost: low. But it inverts a dependency — the alignment data comes from #150's import, so this route makes this issue depend on #150, rather than the other way round. Note #150 originally listed #148 as one of its dependencies; that edge was removed on 2026-08-12 because #150's pipeline does not need it. Choosing A would mean adding #218 blocked by #150.
Also: only covers text PT9 already aligned. A project with no PT9 import gets nothing.

B. Compute alignment with fast_align. Apache-2.0, so no license conflict. Still needs per-platform binaries built and shipped, and the createProcess elevated privilege.

C. Compute alignment with eflomal. #102 investigated this in depth and its assessment applies only to this branch. Two blockers it identifies are organizational rather than code, and neither is resolved or separately tracked:

  • GPLv3 (eflomal) vs MIT (this extension) — redistribution "needs legal/licensing sign-off from SIL."
  • Per-platform binary build/ship infrastructure — win32/linux/darwin with OpenMP, and the stock Makefile's -march=native must be dropped for a portable baseline or the binary may fault on other CPUs.

Options B and C additionally require adding "createProcess" to the currently-empty elevatedPrivileges array in manifest.json — the extension spawns no subprocesses today, so this would be the first.

Scope once the approach is settled

  • Resolve modelProjectId (added by #148) pointing at a non-interlinear Scripture project to the alignment strategy rather than the pool.
  • The alignment step itself, per the chosen option.
  • Feed aligned model words into deriveTokenSuggestion as candidates, reusing the producer: "model:{id}" marker #148 introduces so SuggestionDropdown badges them "from model".
  • Respect the interlinearizer.useModelSuggestions setting from #148.

Persistence is a separate open question

#148 noted alignments "could be persisted via AlignmentLink". Two things to know before choosing that:

  • projectStorage.updateAnalysis writes only the analysis field, not links — there is no persistence path for alignment links at all today.
  • #129 (Burrito alignment specification) observes that AlignmentLink is currently dead weight, so the cost of adopting or mapping to the Burrito flavor "is near zero today and grows with every feature that touches alignment," and recommends doing that investigation before alignment work is scheduled. If this issue persists via AlignmentLink, #129 should be answered first.

Computing alignment on demand and not persisting it sidesteps both.

Open questions

  • Which approach — A, B, or C? Everything else follows.
  • Persist via AlignmentLink, or recompute? See above; if persisting, sequence #129 first.
  • Alignment granularity and quality. #102 notes an aligner "needs reasonable sentence counts to align well; single-verse alignment in isolation may be weak" — so whole-book or corpus-trained priors may be necessary, which affects whether this is a batch or on-demand operation.

Blocked by: #148 (introduces modelProjectId, the model tier in deriveTokenSuggestion, and the producer marker).
Related: #150, #102, #129, #94.

Size: L
Priority: P2 — prerequisite for full PT9 import parity; not blocking gloss-only use or #150's pipeline.

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

環境構築

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

はじめの一歩

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

sillsdev/interlinearizer-extension のほかの issue

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

似ている issue

TypeScript の issue をもっと見る

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

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