lapis: an Anki note type for Japanese that leaves handlebars behind

A note type, a template and a group of contributors

Lapis is an Anki note type, described as advanced yet lightweight and designed with compatibility in mind. It is not an application in the usual sense. It is a set of card templates, styling and behaviour that a learner imports into Anki, and the repository is correspondingly small in structure, with src/, build/, docs/ and assets/ at the top level and a README that is mostly an FAQ.

The project was co-created by Ruri, itokatsu and kuri, and the division of labour is described in the README. Ruri focused on the technical side, writing the code and building the note, kuri helped design it, gave feedback and led the project heavily in its early stages, and itokatsu later joined as a driving force behind code development, with Ruri providing feedback and leading and managing the codebase.

The licence is GPL-3.0, and the project publishes tagged releases, with Lapis v1.7.0 on 2026-01-20, v1.6.0 on 2025-06-29 and v1.5.1 on 2025-04-14. The repository was last pushed on 2026-05-18 and is not archived.

The context that explains the project is a predecessor. The group had been using the Aquafina note and later arbyste's jp-mining-note, abbreviated in the README as JPMN, and while that note was considered fantastic and a major inspiration for Lapis, the founders listed six concrete problems with it.

The six problems that shaped the rewrite

The list of reasons is the most useful part of the project documentation, because it explains every design choice that follows.

First, the old note relied on custom handlebars, many of which had by then been implemented directly in Yomitan, so the note was reimplementing something the dictionary already did. Second, the heavy amount of JavaScript on the card caused noticeable lag on mobile devices. Third, the dependency on handlebars made the note incompatible with tools that do not support Yomitan or handlebars directly, and JL is the example given. Fourth, the use of custom handlebars and CSS to format definitions meant the note sometimes broke dictionary formatting.

Fifth, and this is the one that shaped the whole project, the source code was auto-generated, which made it a real challenge for both developers and non-developers alike to read and customise, and coupled with the complexity of the note it made contributing very hard. That is why Lapis is written to be read, and why the README is a long FAQ rather than a list of features.

Sixth, the original developer went missing in the summer of 2023, leaving arbyste alone to understand the codebase and fix potential issues, with the note that this work was outstanding but no further development was planned except for bug fixing.

A second project, rudnam's JP-study, also influenced the design, and the stated aim was to take the best of both worlds and avoid the problems above. The result is a note type whose compatibility story is the headline: it supports every Japanese dictionary that Yomitan does, and the chance of something breaking is described as exceptionally rare, because there is no custom handlebars layer in which it could break.

Card types, frequency sorting and dictionaries in separate fields

Three features carry most of the practical weight.

The first is the set of card type selectors. Different types of card can be selected using the Is...Card selectors, and the mechanism is deliberately simple: add an x to the Is...Card field of your choice, and make sure only one of them is selected. Switching card types for many notes at once is done with Anki's Batch Editing. The design is worth noting because the alternative, a field holding a value that the template interprets in complex ways, is what the previous generation of note types did and what made them hard to read.

The second is frequency handling. Lapis uses harmonic frequency ranking to create a FreqSort field that you can use to reorder new cards by frequency, either manually with the Advanced Browser, where a separate document explains the procedure, or automatically with AutoReorder. The warning attached to the automatic option is blunt and worth repeating: there have been cases where AutoReorder has reset learned cards to new. That is a data loss risk, in the sense that a card's scheduling state is lost, and it is the sort of thing that makes an automatic convenience worth using carefully.

The third is that dictionaries are organised into different fields, which makes it easier to view information in an organised manner and lets you choose which dictionaries you see first. Since the note renders the dictionaries itself, this arrangement is what makes the note useful for someone who mines from several sources at once.

The interactions on the card, and how the note is set up

The card is interactive, and the interactions are described in one sentence that reads like a feature list. You can click on the edges of the definition blockquote to traverse your dictionaries, hover over the sentence to show furigana, and hover over the top right to see frequency information.

Those three behaviours are the visible result of the design decisions above. Traversing dictionaries by clicking a definition blockquote edge works because the note lets the dictionary render the definition, so the note can offer multiple dictionary entries as separate blocks rather than merging them. The furigana on hover and the frequency information in the corner are additions on top of that, placed where the eye is not already busy.

The setup is a Yomitan configuration rather than an Anki configuration, which surprises people who expect a plugin. You download the example deck from the releases page, and then you change your field settings in Yomitan: select Lapis as the Model in Yomitan's Configure Anki Card Format, and set up the fields as in the table in the documentation, where the Expression field is mapped to {expression} and the remaining fields follow the same pattern of Anki template placeholders.

The order matters. Configure the Yomitan model and the field mapping first, then import or mine into the collection, because a mismatch between the field names in the model and the fields in your notes is the failure that produces empty or scrambled cards, and the example deck is there so that you can check the mapping against a working configuration.

The FAQ is the manual, and it covers the sharp edges

Because the note is a template, the questions a user has are mostly about specific behaviours, and the README's table of contents is a list of those questions. Reading the headings tells you what a user actually runs into.

There are the conceptual ones, like what Anki, note type and mining mean, how sentence furigana is set up, and how to switch from JPMN to Lapis, which is the migration question for anyone coming from the note type this one replaces. Then there is the use questions, such as how to use the various card types, how to see all the definitions, what the Hint field does, and why there are three different fields for definitions, which is a design choice that needs explaining to a user rather than a defect.

Then there is the interoperability question, whether the note will work with tools like JL, and the tagging question, how tagging works in Lapis.

The styling questions are the longest group, and they are all the kind of thing that would otherwise be a support thread. How to change the font size, how to change the fonts used, how to change the bold colour, how to move the sentence on mobile, and how to change the blur effect, with a separate entry on why the blur feature is not working, which is the kind of FAQ entry that only exists because the answer is non-obvious.

Two more are specific to the pitch accent work: a question about having garbage text like a ruby element inside the pitch, and a question on how to specify pitch accent for compound words or expressions. The last two are where to report a bug and where to ask a question that the FAQ does not cover. A project that documents the failure modes this precisely is a project that expects its users to customise the note, which is the whole premise.

Forking, updating and what a reader should check

The README has sections on how to update Lapis and on Lapis forks, and the fork section is worth a note. A note type is the kind of artifact that people personalise, so a fork list is normal, and the fact that the project keeps one in its README means a user can see whether the changes they want already exist somewhere.

For someone evaluating the project rather than using it, the checklist is short. Read the reason it exists, because the six problems are the design brief and any change to the note should be judged against them. Check that the thing you are migrating from is compatible in the ways that matter to you, which in practice means the handlebars-dependent tools, and the answer in the FAQ is about JL. Look at the version history: v1.7.0 in January 2026, v1.6.0 in June 2025 and v1.5.1 in April 2025 are a steady sequence rather than a burst, with the last push on 2026-05-18, so the project is alive but not frantic.

And read the licence, GPL-3.0, with the practical note that a note type is usually shared inside a group, sometimes with modifications by several people, and the terms of the licence are the terms that follow the template around. That is a small thing to check and an awkward one to discover later.

The project also invites contributions warmly, and the acknowledgements name kuri and Ruri, and the maintainers are explicit that they want new contributors, which is consistent with a project whose stated origin problem was that auto-generated code was hard to contribute to.

Editorial conclusion

Lapis fits a Japanese learner who mines sentences with Yomitan, wants a card that renders the dictionaries the way Yomitan renders them, and would rather read and edit the templates than accept generated code. It is the wrong tool if you rely on the specific behaviour of the note types it replaces, since the field layout and the Is...Card selectors are its own, and it is the wrong tool if you want the auto-reordering convenience without the risk, because the documentation itself warns that AutoReorder has reset learned cards to new. Before you migrate an existing collection, read the FAQ sections on the three definition fields and on the Hint field, download the example deck from the releases page, and set the Yomitan model to Lapis before importing anything, because a mismatched field configuration is the step that is easiest to get wrong.

Frequently asked questions

Official sources

1. donkuri/lapis on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases