`analyze()` returns empty string for `reading` field on all morphemes

[aptend]

Description

The API docs and Morpheme interface document a reading field ("Reading in katakana", e.g. "タベ"), but analyze() always returns "" for every morpheme in v0.9.3.

Reproduction

import { Suzume } from "@libraz/suzume"
const s = await Suzume.create()
console.log(s.version) // "0.9.3"

for (const m of s.analyze("食べる")) {
  console.log(m.surface, "→ reading:", JSON.stringify(m.reading))
}
// 食べる → reading: ""
// Expected: reading: "タベル"

for (const m of s.analyze("東京に行きました")) {
  console.log(m.surface, "→ reading:", JSON.stringify(m.reading))
}
// 東京 → reading: ""  (expected: "トウキョウ")
// に → reading: ""
// 行き → reading: ""  (expected: "イキ")
// まし → reading: ""
// た → reading: ""

Environment

• @libraz/suzume@0.9.3
• Node.js v22.18.0
• Also tested in browser (Obsidian/Electron)

Analysis

Looking at the C++ source, analyzer.cpp does copy edge.reading into the morpheme:

if (!edge.reading.empty()) {
    morpheme.reading = std::string(edge.reading);
}

But the embedded minimal dictionary does not seem to contain reading data, so edge.reading is always empty.

Question

Is reading support a planned feature? Or is there a way to provide reading data (e.g. via user dictionary or a supplementary dictionary)?

We are building a furigana annotation tool and would love to use Suzume for its small size, but reading data is essential for our use case.

[libraz]

Thanks for the detailed report — and apologies for the misleading API surface.

Honestly, the reading field is a vestige from an earlier design iteration: the struct member, the lattice plumbing, and the docs survived, but nothing in the current pipeline ever populates it. So analyze() returning "" isn't a partial implementation — the feature was never wired up, and the documentation describing it shouldn't have been there. Sorry for the confusion this caused.

Beyond the cleanup question, it's worth saying why we don't plan to revive it: Japanese readings are heavily context-dependent and can't be reliably resolved by dictionary lookup alone. A few examples:

• 行った → いった (went) / おこなった (performed)
• 辛い → つらい (painful) / からい (spicy)
• 人気 → にんき (popularity) / ひとけ (signs of people)
• 今日 → きょう (today) / こんにち (these days)
• 大事 → だいじ (important) / おおごと (big deal)

Even MeCab+IPADIC, kuromoji, and similar dictionary-based tools rely on cost-based guesses and routinely produce wrong readings for these. Doing this well requires either a much larger statistical dictionary (Sudachi system_full, MeCab+UniDic) or an LLM-based approach — and even those don't reach 100%. For a furigana tool, silently-wrong readings are arguably worse than no readings, so we don't think a half-working implementation would serve your use case.

Given this, I've removed the field from the public API along with the misleading docs. Leaving this issue open as a tracking record for anyone hitting the same limitation.

Changes:

• Morpheme.reading removed from C++/C/JS APIs (commit 1c32ff6)
• Homepage documentation updated (libraz/suzume-homepage@85408ab)