Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Add lexicon ref resolution when copying a Paratext 9 import for editing

Đang mở
  • Có gì không ổn?
#280 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
42/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend, frontend

Hướng nghiên cứu

Bắt đầu với src/converters/pt9/lexiconResolver.ts, pt9ImportService, analysisMerger.ts, bareWordAnalyses.ts và Pt9ImportModal.tsx; xác định quy ước authority từ issue bị chặn #226. Theo dõi createEditableCopy và báo cáo import PT9, sau đó bổ sung coverage để các refs vẫn tồn tại sau khi tạo bản sao có thể chỉnh sửa và cho các tổng sense đã gộp. Được xem là hoàn tất khi các import PT9 tạo ra refs, các bản sao giữ lại chúng và báo cáo render các tổng sense mà không thay đổi hành vi hiển thị.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

The PT9 import stack ships a lexicon-resolution seam with nothing plugged into it, so every import
persists gloss text and no lexicon refs. That deferral (#273) is right for the import project
itself. It is not right for an editable copy, which is the one place PT9 lexeme identity becomes
unrecoverable.

Current state

  • The seam exists and is fully wired. Pt9LexiconResolver
    (src/converters/pt9/lexiconResolver.ts) offers
    resolveEntry(key) -> EntryRef and resolveSense(key, senseId) -> SenseRef. Every ref site the
    converter can produce already calls it: morpheme entryRef / senseRef and token-level
    glossSenseRef in analysisMerger.ts, morpheme refs on
    bare-word payloads in bareWordAnalyses.ts. Outcomes are
    counted in the import report (senses.entryRefsResolved / entryRefsUnresolved, same for senses).
  • Nothing supplies an implementation. pt9ImportService.importPt9Project calls
    convertPt9Project({ data, books, importedAt }) with no resolver, so
    unresolvedPt9LexiconResolver applies, every lexeme counts as unresolved, and imported analyses
    carry inlined gloss text and zero refs.
  • The identity is in the payload, not missing. Pt9InterlinearProjectData.lexicon carries
    entries keyed by composed lexeme-key id and senses with ids and per-language glosses - the same
    data pt9GlossSource already reads for gloss text. For PT9
    the seam's work is minting refs from data in hand, not looking anything up.

Why the copy is the case that matters

lexiconResolver.ts records the current rationale: a PT9-authority ref "would store fine as a
foreign ref, but nothing would ever resolve it; re-importing recovers the identity instead."

That holds for the import project, which is frozen and replaced wholesale by savePt9Import on
every run. It does not hold for a copy:

  • createEditableCopy clones the analysis, keeps sourceProjectId, and drops pt9Import.
  • Re-import finds its target through getPt9ImportForSource, which matches on pt9Import. A copy
    carries none, so no re-import ever touches one.

So the artifact the user actually edits and keeps is the one artifact whose dropped PT9 lexeme
identity cannot be recovered. Re-importing produces a fresh import project; the user's edits stay
behind in the old copy, still refless.

Ask

  • Implement a PT9-authority resolver over the served Pt9Lexicon and pass it from
    pt9ImportService.
  • Name the authority constant (paratext9, following whatever convention #226 fixes).
  • Decide projectId. PT9's lexicon lives in the PT9 project, so the id space is partitioned and a
    ref must carry one. LexiconRef.projectId already anticipates exactly this: "an authority whose
    lexicon lives in a Paratext project may well use a Paratext project id here, even the analyzed
    project's own."
  • Test the case this issue exists for: an import that carries refs, copied, still carries them.
  • Fold and render report.senses in the import report summary. foldReport
    (Pt9ImportModal.tsx) deliberately leaves it out today, since with no resolver every run
    would show zero resolved; ReportTotals carries a TODO pointing here.

Display does not change, and must not. No registered resolver declares paratext9, so per
#225/#269 every minted ref is foreign - never resolved, never dropped, rendered as the stored
free-form gloss, which import already inlines. These refs are provenance now and resolvable later.

Open questions

  • entryId is not a GUID here. The model documents EntryRef.entryId as IEntry.id (GUID); a
    PT9 ref carries a composed lexeme key (Stem:exauc, Word:a:2). Either that doc widens to
    "whatever the authority mints" or PT9 refs need a different shape. Widening looks right -
    authorities are opaque by design - but it should be written down, not assumed.
  • Senses with no id. Pt9GlossOutcome.defaultSingle can produce gloss text from a sense carrying
    no id, and bareWordAnalyses only attempts a senseRef when the languages agree on exactly one
    id. Confirm an entry-only ref is the intended outcome there.
  • Minting only, or a provider too? Minting is self-contained. Actually resolving these refs needs
    something that declares the paratext9 authority - a PT9 lexicon provider, which is a live
    candidate for the tier-1 slot in #46 and for #44's "create from Paratext 9 data." Mint regardless;
    whether this issue also provides is the open part.

Non-goals

No PT9 lexicon provider, no lexicon UI, no writes to any lexicon. Minting refs during import and
keeping them through createEditableCopy.

Blocked on

#226, for the convention naming an authority constant. This is the first code path in the repo that
mints a ref, and #226 exists partly so the first writer does not improvise a label that then
persists.

Relationship

Completes #150's scope item 3 (gloss-text resolution) on the identity half - #150's open question
"import to glossSenseRef vs. literal gloss text vs. both?" is answered here as both. What a
resolvable ref renders as is #227's ladder.

Ngôn ngữ chính
TypeScript
Star
2
Fork
0
Merge trung bình
2 ngày 8 giờ
Pull request đã merge (30 ngày)
44

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sillsdev/interlinearizer-extension

Tất cả issue của sillsdev/interlinearizer-extension

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.