Proposal: reviewable hub cards, plus lookup / highlight / save (no core change)
Background
My background is primarily STEM; I am also a multilingual learning enthusiast (Japanese, English, and Arabic). I have come to see that learning methodology and the condensation of knowledge into clear summaries matter a great deal—for example, in morphology, an upper-layer abstraction over word structure and form–meaning patterns: English roots and affixes, Japanese kanji morphemes, Arabic triliteral roots and patterns. A few proposals follow from that.
Where it comes from. Efficient study means less copying and more transfer: keep a root or affix in one place, while derivatives stay in the word decks already being reviewed. Summarizing knowledge means drawing a rule from confirmed examples and applying it to words not yet studied. Copying the concept onto every fact card scatters the text, makes edits painful, and never trains transfer. Anki already does spaced repetition and deck scheduling well. What is missing is an optional structure layer: a hub card points at leaf cards, and the leaves stay in the learner’s existing deck.
Why it is needed. With several languages in parallel, root notes and vocabulary lists split apart without that layer, and a looked-up word is hard to attach back to the deck in use. Commercial dictionaries often make “select → look up → save” a daily habit (remembering a word in article context pays off far more than an isolated word card), then gate the number of dictionaries (the user’s offline dictionaries) and pronunciation behind membership. Saving into one’s own deck with a confirmable affiliation is an everyday need (in my assessment, this kind of feature has high stickiness in user usage); the hub layer is what keeps morphology reviewable afterwards, instead of a flat pile of new words.
Route 1 — Reviewable hubs
- A hub card can be reviewed on its own. Opening it lists the leaves already attached (which deck, which note).
- Leaf cards stay in the learner’s existing deck and review like any other Anki card. The only added UI is an affiliation tag.
- Affiliation has a confirmation flag:
0= automatic match, not yet confirmed (the default);1= the learner confirmed the affiliation. Unconfirmed affiliations must be visible, and must not be treated as verified knowledge. - The hub text lives only on the hub card. It is not copied onto every leaf.
- Roots and affixes are the first hub type. Notes are created by the learner from their own materials in each subject. The repository does not ship copyrighted books. Decks that do not use hubs (for example, plain fact cards) stay as they are.
Route 2 — Lookup, highlight, save
The motivation is the daily stretch in Eudic : select a word → look it up → save it to a word list. That comparison is appropriate. Eudic turned this into a habit, and membership locks on everyday abilities; users are often annoyed, but they still depend on lookup and saving. This proposal wants that stretch of the path, not Eudic’s dictionary text, its UI, or its membership system. The learner imports their own local dictionary; when there is no local entry, a public translation can be used. The save target is the learner’s own Anki deck, with a hub attached, not a vocabulary locked inside someone else’s product.
Two concrete pain points:
- A cap on how many offline dictionaries can be uploaded. Learners cannot add their own dictionary files as their study needs grow. Several languages, or several sets of root materials, hit the quota.
- System text-to-speech is blocked by the software. Pronunciation already on the device cannot be used freely on the word just looked up; it is held behind membership or replaced by the client. This proposal caches speech locally (generate once, then play offline) and does not use that membership channel.
Lookup and highlight happen every day, far more often than opening a root tree. Being able to save into the deck already being studied, with an affiliation attached, at the moment of lookup, gives the learner a reason to open it every day. Route 1 is what they come back to afterwards, to organize and review.
First slice: three items:
- Desktop system-wide lookup. A separate process (not inside Anki) pops up a lookup from the selection, a hotkey, or the clipboard. It searches the learner’s own offline dictionaries, falls back to a public translation when there is no entry, saves into a chosen deck, and attaches a hub. New affiliations default to unconfirmed (
0). No Anki core changes. - Merge on saving the same word again. Saving the same word again merges into the same note. It does not create another card or reset review history.
- Mobile system lookup. Android uses an accessibility overlay; iOS uses a share extension. Both write the same deck and the same pointer, and neither runs its own scheduler.
A further layer: relation paradigm (after route 1)
This layer is not a separate product. It is a further proposal, made after reading Anki’s design intent and then summarizing, together with how other fields remember knowledge.
Reading of Anki’s intent: keep the core lean and do spaced repetition well; each card is a schedulable study unit; do not write one subject’s method into the official client.
The induction starts from morphological constituents in linguistics, not from drawing tools. Roots, affixes, stems, and patterns are the higher units of word formation; derived and inflected forms are the concrete items under them. A hub in route 1 first corresponds to those constituents: one root (or one affix) is maintained in one place, with collected derivatives and related words attached beneath it. Looking further at mind maps, concept maps, medical classifications, code modules, and legal elements, the surfaces differ, and underneath is the same shape: “higher constituent / class — typed relation — concrete member.” Morphology is where this abstraction starts; other subjects are the same structure carried onto other material. Reducing the links to a small fixed set of relations lets the review unit rise from “a word or a node” to “a relation,” without becoming a freeform canvas.
Order:
- Route 2 saves a word into a deck and attaches an affiliation (unconfirmed by default).
- Route 1 makes the hub reviewable on its own, and able to expand the leaves already attached. Leaves stay in their original deck. What is reviewed is still a node: the hub is the concept, the leaf is the fact.
- Relation paradigm labels the link between hub and leaf with a fixed set of relation types, and generates questions (review cards) only from relations the learner has confirmed (
1). Without route 1 there is no structure for those questions to hang on. Without the confirmation flag, an automatically attached wrong relation would be used as a question.
What this adds for learning:
| Stage | What the learner gets |
|---|---|
| Ordinary deck only | Facts are remembered one card at a time. A root or concept has to be copied onto every card. Words already seen and words not yet seen use the same kind of question |
| Routes 1 and 2 added | The concept is maintained in one place. Saving is faster. Opening a hub shows the members already collected. How the original deck is reviewed does not change |
| Relation paradigm on top | The relation itself starts to be practiced. Examples: what word-formation rule these confirmed examples share (induction); use that rule to produce a word not yet studied (deduction); how these two confusable items differ (contrast) |
The relation types stay a small fixed set: member-of, derived-from, induction, deduction, confusable, analogy, sequence, prerequisite, comparison. A freeform canvas is not included. Unconfirmed relations may be shown, and do not generate questions.
Formalization: let N be the set of nodes, and let the set of relation types be finite:
A relation is
c=1 means the learner has confirmed it. A review card is generated only from a confirmed relation whose type is not prerequisite:
Inputs to induction cards and deduction cards are likewise taken only from relations with c=1. Relations with c=0 may be shown, and do not enter \mathrm{Card}.
Technical feasibility
- Route 1 can be done with ordinary notes and existing hooks (
editor_did_init_buttons,editor_did_load_note,browser_will_show_context_menu). Phones can review these notes because they are ordinary notes; expanding the whole tree stays on the desktop. No core change. - Route 2 keeps desktop system-wide lookup and mobile system lookup outside the Anki process. Saves are written back into the deck, and scheduling stays with Anki. No core change.
- Relation paradigm is not in the first slice. If it is done later, only member-of and derived-from come first, and deduction and confusable pairs come next; the questions are still ordinary notes, and the core still does not change.
Ask
Please confirm whether this set of functions is complete, and whether anything is missing. For the part that lives in the add-on, please point out any step that cannot be done today and needs only a hook. Lookup that lives outside the add-on is not judged as an add-on proposal. This issue does not ask for code to be merged.