librime : le moteur de saisie qui laisse les schémas dicter la frappe

Un moteur, pas une méthode de saisie

librime résout un problème précis : fournir le cœur logiciel d'un moteur de saisie chinois, sans imposer de méthode particulière. Le README le dit clairement : le projet couvre les fonctionnalités que l'on trouve dans une grande variété de méthodes chinoises, qu'elles soient basées sur la forme ou sur la phonétique. Il ne s'agit pas d'un outil utilisateur final, mais d'une bibliothèque que des frontends comme Squirrel sur macOS ou Weasel sur Windows utilisent pour offrir une interface. Pour qui ? Pour les développeurs qui veulent intégrer la saisie chinoise dans leur application ou créer un frontend. Pour les utilisateurs, le chemin passe toujours par un frontend. C'est une distinction importante : adopter librime, c'est accepter de construire l'interface soi-même ou de dépendre d'un projet tiers.

Des schémas YAML comme langage de conception

Le mécanisme central de librime est le schéma de saisie, un DSL en syntaxe YAML. Ce schéma définit la correspondance entre les frappes et les caractères, les règles de transformation, et les dictionnaires. Le README mentionne deux concepts clés : le Spelling Algebra, qui permet de créer des variantes de prononciation, particulièrement utile pour les dialectes chinois, et le support de la frappe par accords avec un clavier Qwerty générique. Concrètement, un schéma peut décrire une méthode phonétique comme le pinyin, mais aussi une méthode basée sur la forme des caractères. Cette approche diffère des moteurs traditionnels qui codent en dur une méthode. Avec librime, la logique de saisie est externe au code C++, ce qui facilite l'expérimentation. Le README insiste sur ce point : le DSL permet d'essayer rapidement des idées innovantes de conception de méthode de saisie. En pratique, cela signifie que l'utilisateur peut modifier un fichier YAML sans recompiler la bibliothèque.

Construction et dépendances : un socle exigeant

La mise en route de librime n'est pas triviale. Le README donne des instructions pour Linux uniquement : make puis sudo make install. Pour macOS et Windows, il renvoie à des fichiers README spécifiques. Les dépendances de build sont nombreuses : un compilateur C++17, cmake au moins 3.12, Boost au moins 1.74, LevelDB, marisa-trie, OpenCC (au moins 1.0.2), yaml-cpp. En option, glog et gtest. Ces bibliothèques ne sont pas anodines. marisa-trie est un outil de compression de dictionnaires, LevelDB une base de données clé-valeur. Leur présence indique que librime gère des dictionnaires volumineux et des données persistantes. Pour un développeur, cela signifie que l'installation système doit être préparée. Sur une distribution récente, la plupart de ces paquets sont disponibles, mais la version d'OpenCC peut poser problème. Le README signale que glog est optionnel, ce qui suggère que la journalisation peut être désactivée pour réduire les dépendances.

Frontends et plugins : un écosystème à double tranchant

librime est conçu pour être utilisé via des frontends. Le README en liste plusieurs, officiels et communautaires. Les officiels sont ibus-rime pour Linux, Squirrel pour macOS, Weasel pour Windows. Les communautaires couvrent des environnements variés : Trime pour Android, fcitx5-rime pour Linux, emacs-rime et rime.nvim pour les éditeurs, tmux-rime pour les terminaux. Cette diversité est une force, mais elle implique que la qualité et la maintenance varient. Chaque frontend doit suivre les évolutions de librime, ce qui peut créer des décalages. Il existe aussi des plugins officiels, comme librime-lua pour le scripting Lua, et librime-octagram pour un modèle de langage. Certains sont dépréciés, comme librime-charcode, qui dépendait de boost::locale et d'ICU. Cela montre que l'écosystème évolue, mais que certaines briques peuvent être abandonnées. Pour un intégrateur, il faut vérifier si le frontend ou le plugin visé est toujours actif.

Limites et cas où librime est le mauvais choix

La première limite est la complexité de la configuration. Le DSL YAML est puissant, mais il demande un apprentissage. Le README ne fournit pas d'exemple de schéma, ce qui oblige à consulter la documentation externe, comme le wiki ou les dépôts de schémas. Une autre limite est l'absence de support direct pour des langues autres que le chinois. Le README mentionne le chinois traditionnel et la conversion vers le simplifié via OpenCC, mais rien pour le japonais ou le coréen. Si votre besoin est la saisie dans une autre langue, librime n'est pas adapté. Enfin, la dépendance à des bibliothèques comme marisa-trie et LevelDB peut être un frein pour des environnements embarqués ou des systèmes minimalistes. Dans ce cas, un moteur plus léger serait préférable. Pour un utilisateur qui veut simplement saisir du chinois, utiliser librime directement est inutile : il faut passer par un frontend, et autant choisir un frontend complet comme fcitx5-rime.

Alternatives : des approches différentes

La principale alternative à librime est de ne pas utiliser de moteur séparé, mais de s'appuyer sur les méthodes de saisie intégrées aux systèmes d'exploitation, comme le pinyin de Microsoft Windows ou le pinyin de macOS. Ces méthodes sont optimisées pour leur plateforme, mais elles ne sont pas extensibles. Une autre alternative est IBus, qui fournit une infrastructure de saisie pour Linux, avec des moteurs spécifiques pour le chinois. IBus est plus simple à intégrer, mais il est moins flexible que librime en ce qui concerne les schémas personnalisés. Pour les développeurs qui veulent une solution en JavaScript, il existe des bibliothèques comme Chinese Input Method, mais elles sont moins matures. La différence fondamentale avec librime est la philosophie : librime met la conception de la méthode au premier plan, avec un DSL dédié, tandis que les alternatives proposent des méthodes fixes. Si vous voulez créer une méthode de saisie originale, librime est unique ; si vous voulez juste une saisie fonctionnelle, une alternative intégrée est plus simple.

Maintenance et licence : ce que le README révèle

Le projet est sous licence BSD-3-Clause, ce qui est permissif et favorable à une intégration commerciale. Le README crédite les bibliothèques utilisées, avec leurs licences respectives : Boost, LevelDB, marisa-trie (BSD-2-Clause et LGPL), OpenCC (Apache 2.0), yaml-cpp (MIT). Cela signifie que les dépendances ont des implications de licence différentes, mais la combinaison reste compatible avec un usage propriétaire, à condition de respecter les conditions de chaque licence. Le projet semble actif : la dernière version stable est 1.17.0 datée de juin 2026, et des nightly builds sont disponibles. Le dépôt a été poussé en août 2026. La maintenance est donc régulière. Cependant, le README ne mentionne pas de politique de migration entre versions majeures. Pour un intégrateur, il faut prévoir de suivre les évolutions du DSL YAML, qui peut changer. Le coût de mise à niveau peut être non négligeable si vous avez des schémas personnalisés.

Conclusion éditoriale

librime s'adresse aux développeurs qui veulent construire un frontend de saisie personnalisé, que ce soit pour un environnement de bureau, mobile ou même un éditeur de texte. Il convient également aux utilisateurs avancés qui souhaitent expérimenter avec des schémas de saisie originaux. En revanche, si vous cherchez une solution clé en main, préférez un frontend comme ibus-rime ou fcitx5-rime. Avant de l'adopter, vérifiez la compatibilité de vos dépendances (Boost, LevelDB, marisa-trie, OpenCC) et le coût de maintenance des schémas YAML. Le projet est actif, avec une version 1.17.0 récente et des nightly builds, mais la documentation se limite souvent au README et aux fichiers de build. Testez sur un cas réel, comme la conversion du chinois traditionnel vers simplifié, pour valider votre intégration.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes