RIME-LMDG: a Wanxiang grammar model and tone-annotated dictionary set for Rime

The gap it fills: dictionaries cannot cover everyday Chinese

Traditional Rime input leans on hardcoded dictionaries. A phrase like 住在里屋 has to be entered as a unit, and no dictionary size makes that tractable: the space of plausible Chinese phrases is far larger than any list a human can maintain, and lookup itself gets slower as the list grows.

RIME-LMDG attacks that from the grammar side. It builds what the project calls a sentence flow model, and the reasoning is stated directly: a model can compose fragments out of material already in the dictionary, in memory, from a C++ prefix tree scan that maps only one region, so it can be deployed at the translator stage rather than delayed until the UI layer.

The intended user is a Chinese Rime user who has outgrown a stock dictionary, and the maintainers are explicit that the shipped dictionaries are the foundation. The tone annotations, phrase composition and word frequencies are described as the core of the project, with the surrounding features treated as customizable. A feedback form is linked for collecting dictionary problems, and tone annotation corrections can be submitted as pull requests to a tab-separated file.

The project is built on a 32GB corpus drawn from community Q&A, blog comments, public accounts, encyclopedia entries, news, song lyrics, classical poetry, xiehouyu, tongue twisters, hotel and delivery reviews, legal documents, regional descriptions and literary works. Entries were selected with AI assistance and then proofread by hand.

Why the frequencies distinguish 那里 from 哪里

The dictionary design detail worth understanding is the frequency model. Word frequencies are counted on a pair of phrase and pinyin, then derived down to single characters with their specific reading. That means 那里 and 哪里 do not merge their character frequencies into a shared na bucket: the single character frequencies stay separated by reading, which is what makes polyphonic characters behave sensibly.

Scale follows from the corpus. Many single characters reach the billion-occurrence range, so frequencies are log-normalized, which keeps files small and the numbers maintainable.

The dictionaries themselves are split by purpose, and the split tells you where to look when something is wrong. Base coverage lives in zi.dict for characters in the CJK basic block that have a reading, jichu.dict for the units that make the scheme usable, and duoyin.dict for polyphonic phrases under alternative readings. Then come targeted sets: cuoyin.dict holds commonly misread or miswritten entries, and the classification sets cover animals and plants, domestic place names, chemistry, pharmaceuticals, medicine, artist names, famous people and ordinary high frequency personal names.

There is also a traditional Chinese layout. The repository carries dicts/ and dicts_hant/ as separate directories, and the pinyin_data/ tree includes the basic CJK region through extension G plus the Kangxi radical region, maintained by hand on top of an existing base.

Enabling the model: one block in your Rime configuration

Weasel and Rattic input methods can configure the model directly. fcitx5 needs the plugin librime-plugin-octagram installed, and the package name differs across Linux distributions.

Once the plugin is available, the configuration is a single include plus an octagram block:

__include: octagram   #启用语法模型
octagram:
  __patch:
    grammar:
      language: wanxiang-lts-zh-hans
      collocation_max_length: 6
      collocation_min_length: 2
      collocation_penalty: -14
      non_collocation_penalty: -6
      weak_collocation_penalty: -100
      rear_penalty: -18
    translator/contextual_suggestions: false
    translator/max_homophones: 8

The first line is what actually switches the model on; without it the rest of the block is inert. The language value selects the model file, and the two variants differ by one letter: wanxiang-lts-zh-hans for simplified characters, wanxiang-lts-zh-hant for traditional. A mismatch here is the kind of mistake that shows up as an empty grammar rather than an error.

The collocation settings control how long a collocation may be, from 2 to 6, and how heavily non-collocations and weak collocations are penalised. Turning contextual suggestions off and capping homophones at 8 keeps the candidate list from growing without bound.

Model files are downloaded from the releases page; a long term support build was published on 2025-12-07. Parameter explanations live in a wiki page, and a separate build tutorial is linked for anyone recompiling from scratch.

What the project's own benchmark reports

Evaluation uses rime-schema-compare, a component taken from gaboolic/rime-schema-compare, which is a Python script that calls the librime decoder and gathers statistics. All four configurations below were measured with the Wanxiang grammar model in place.

The published figures, on a corpus of 223535 sentences, give rime_frost a sentence accuracy of 61.71% (137944 exact matches) and a character accuracy of 92.77%, while rime_frost_with_gram reaches 75.42% (168601) and 96.02%. Wanxiang on its own sits at 62.34% (139358) and 93.5%, and rime_wanxiang_with_gram at 76.86% (171817) and 96.32%.

The pattern is consistent: adding the grammar model moves sentence accuracy up by roughly fifteen points in both pairs,. The project reads that fifteen percent as the headline figure.

Two caveats belong next to those numbers. The project itself states the evaluation is not complete, because statement flow aggregates high frequency contexts and phrases such as 多加冰, 练完腿 or 煎个鸡蛋 are very much alive but rarely present in any corpus. And the character accuracy figures are described as weighted with Levenshtein, not as strict equality, so they flatter results more than sentence accuracy does.

The tuning is locked to the Wanxiang dictionaries

This is the constraint that most affects adoption, and the project states it twice rather than burying it.

The model optimizes the ordering of pinyin weight sequences and gives shape codes no special handling, so it is recommended only for dictionaries built on pinyin sequences, and even more strongly recommended for the Wanxiang dictionary itself. The reason given is arithmetic: a dictionary's phrases, codes and sort weights interact with the model's weighting in a balance, and the parameters were tuned against that specific dictionary.

In practice the numbers above are an argument for an all Wanxiang stack. If you keep your own dictionary and only borrow the model, the collocation penalties and max_homophones value will need to be adjusted by hand, and the published accuracy figures will not describe what you get.

The toolchain that maintains the dictionaries is the same repository: wanxiang-tools.py handles refreshing pinyin, refreshing auxiliary codes, converting short codes and extracting entries from a user dictionary, and the root scripts include corpus parsing for text and Wikipedia Chinese, segmentation, tone classification, and 语法模型构建.py for building the model. Separating tooling from artifacts in one tree is convenient for contributors and awkward for anyone who only wants the dictionaries.

When a different approach is the right call

The realistic alternative is a large static dictionary with no grammar model, which is what rime_frost in the benchmark represents. It avoids an octagram plugin and its grammar-model parameters. You give up the roughly fifteen point sentence accuracy gain and the ability to compose unseen phrases, and in exchange you remove an entire class of configuration failure.

The second alternative is a shape based or auxiliary code setup, such as one of the Wanxiang double pinyin variants with tone or reverse lookup auxiliary codes. The project is explicit that the grammar model does not support shape codes, so this is not a tuning problem. If your scheme is built around shapes, the dictionary side of this project is still usable and the model is not.

A third path is a different input method engine entirely, which sidesteps the fcitx5 plugin question but also sidesteps the whole dictionary ecosystem this project plugs into.

Both of the direct alternatives are worse on accuracy and better on predictability. That trade, not the benchmark number, is the real decision.

Release cadence, upgrade cost and licence

The repository is not archived and the last push was on 2026-10-16. Releases come from several streams rather than one: a nightly dictionary and annotation package on 2026-10-15, a tool release (万象词库-刷拼音-辅助码工具) at v3.3.4 the same day, and the LTS grammar model build on 2025-12-07.

The nightly stream is a feature and a cost. Fresh dictionary and annotation builds mean your files change without a semantic version bump, so pinning a known good dictionary before a large update is more work here than with a tagged release. The LTS model is the stable counterpart for people who would rather not chase the nightly channel.

The licence is CC-BY-4.0. That is a content licence rather than a software licence, which fits a dictionary corpus, and it carries attribution obligations for anything derived from the word and frequency data. This is not legal advice, but it is worth noting that a CC-BY label on a dictionary imposes conditions on redistribution that a permissive software licence would not.

Editorial conclusion

Use RIME-LMDG if you type Chinese daily in Rime and want the higher sentence accuracy that comes from a grammar model rather than a bigger dictionary, and if you are willing to adopt the Wanxiang dictionary files rather than mixing them with your own. Skip it if your setup is shape-based, since the project states the model is not meant for shape codes, and skip it if you only need a refreshed dictionary. Verify first that your input method can load an octagram plugin at all: Weasel and Rattic input methods configure the model directly, but fcitx5 needs librime-plugin-octagram installed under whatever name your distribution uses, and without it the language line in the config points at a model nothing loads.

Frequently asked questions

Official sources

1. amzxyz/RIME-LMDG on GitHub
2. License: CC-BY-4.0
3. Project website
4. README
5. Releases