# WM Keyboard is an Android keyboard built for Bangla first, with the whole intelligence layer kept on the device > wasi-master/wmkeyboard is a Kotlin and Jetpack Compose Android input method with local prediction, glide typing, phonetic transliteration for a dozen scripts, a 75 plus tool toolbox covering clipboard, translate, calculator and scanner, and an AI panel that runs on device models. It ships as an APK, a Google Play listing and an F-Droid package under the MIT licence, with three tagged releases in the first week of October 2026. **wasi-master/wmkeyboard** — A modern, privacy-first Android keyboard: offline intelligence, 600+ languages, themes, tools and an addon ecosystem. - Repository: https://github.com/wasi-master/wmkeyboard - Website: https://wmkeyboard.pages.dev - Stars: 624 · Forks: 34 - Language: Kotlin - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/wasi-master-wmkeyboard ## The premise is that a keyboard should not report what you type The slogan in the banner is the shortest version of the project: type anything, share nothing. The subtitle calls it private, offline and yours. The reasoning in the Why I built this section is worth reading in the author's own framing, because it explains the scope. A keyboard is the one app that sees everything you write, including messages, passwords and the half-typed thoughts you deleted before sending. The argument is that the popular keyboards decided that was a business model, and that better prediction came at the price of a copy of your keystrokes going to somebody else's server. The competitor set the author is aiming at is described as forks of the same decade-old Android code, with honest intentions but no glide typing without a proprietary blob, no real toolbox, and nothing for the language he actually types in. Bangla is described as an afterthought everywhere, either a phonetic engine bolted on with no prediction, or a layout with no smart features behind it. The three goals that follow are specific. Type Bangla the way Avro taught a country to type it. Carry the features used all day, clipboard, snippets, translate, calculator and scanner, without leaving the text field. And keep all of that on the phone. The implementation detail that makes this more than a promise is that the keyboard is written from scratch in Kotlin and Jetpack Compose, keyboard surface included, and the whole intelligence layer runs offline. The repository description adds that it supports 600 or more languages, themes, tools and an addon ecosystem, and the topic list names the IME, input method, privacy and Material You angles. ## Phonetic input, with the scripts that usually get skipped The prediction section is the technical heart of the project, and it opens with the mechanism: type a word the way it sounds in Latin letters and the keyboard finds the word you meant. Every one of these runs on the device, with no network and no delay. The table of engines is the clearest statement of the scope. The Bangla entry is Avro-compatible, with a lenient index where asI, achi and achhi all reach the same word. The Hindi entry is a phonetic engine with a map of how people actually romanise Hindi. The Urdu entry folds the input to the consonant skeleton the script itself spells with, and the Arabic, Tamil, Telugu and other rows are phonetic layouts, with Arabizi digits included. There is Pinyin with a T9 nine-key variant, Romaji to kana with conversion candidates, and Vietnamese Telex. The Avro compatibility is the substantive claim, because Avro is the input method a generation of Bangla speakers learned on a different operating system. A phonetic engine that accepts the same spellings is the difference between a keyboard that is learnable in an afternoon and one that is not. The lenient index is a smaller but cleverer point. A phonetic engine that only matches the exact spelling a dictionary contains will fail on the misspellings that real typing produces, so asI, achi and achhi have to converge on the same output. That is a decision about error tolerance in the phonetic layer rather than in the predictor, and it is the kind of detail that only appears in a keyboard built by someone who types that language daily. The count is worth stating carefully. The table names a dozen or so script families, and the description claims 600 or more languages, which is a different claim about dictionary and layout coverage rather than about distinct phonetic engines. ## One prediction engine behind every script The last paragraph of the prediction section is the part that turns a collection of layouts into a keyboard. The same prediction engine sits behind every one of them, so glide typing, autocorrect and next-word suggestions work in Bangla exactly as they do in English. The typing section names the mechanism: a trie-lattice beam decoder shared by tapping and glide, with n-gram context ranking, and a prediction that learns, locally. That sharing is the interesting engineering decision. A trie-lattice beam decoder is the standard way to do phonetic decoding: candidate words are laid out in a lattice, and a beam search keeps the most promising paths while expanding. Sharing one implementation across scripts means the glide path and the tap path go through the same decoder, so a glide in Bangla is not a separate feature bolted onto an English keyboard but the same machinery with a different candidate generator. The n-gram context ranking on top is what turns a decoder into a predictor that offers the next word. And the fact that it learns locally means the keyboard builds a model of your vocabulary on the device, which is the privacy story and the usefulness story arriving together: a local model is both the reason nothing leaves the phone and the reason the suggestions get better. The repository layout backs the claim that this is a real application rather than a demo. There is an app/ directory, a feature/ directory for the feature modules, core/ for shared code, native/ for the native layer, build-logic/ for the Gradle convention plugins, a benchmark/ directory, config/ and tools/ directories, plus feature/ specific infrastructure in play/, fdroid/, fastlane/ and scripts/. The docs are a separate site, with a Gemfile for what is a static site generator, and the site lives at wmkeyboard.pages.dev. ## The toolbox is the reason the feature chips exist The screenshots in the README are organised around one idea: you should not have to leave the text field to do the small things. The features named in the tour are the clipboard, snippets, translate, calculator and scanner, and the screenshots describe a clipboard with history, pins and one-time codes, a wall of feature chips around the keyboard, and a panel for the calculator, dictionary and toolbox. There is emoji search and themes, and a grid of the whole feature set. The clipboard with one-time codes is a detail worth noticing, because it is a security feature implemented inside a keyboard. A one-time code, such as a second factor, is short lived and frequently pasted. A clipboard manager that keeps history is a genuine risk, since a keyboard that keeps a copy of everything you copy is a keyboard that stores your passwords, and building the one-time code path into the clipboard is an attempt to make the common case safe rather than only offering a manual purge. The AI panel is described as rewriting, translating and fixing, right on your phone, with on-device models, and the screenshots state that everything runs on the phone, including voice typing and AI, in airplane mode. That is a meaningful claim for a keyboard, because it means the language model runs locally and the features do not degrade to a network call when you are offline. The counterpoint is that a keyboard with a local model, a clipboard history, a snippet store and a scanner is a lot of capability in the most privileged app on an Android device, and the privacy argument is that it is all local. The security documentation in the repository, SECURITY.md, is the place to check what that claim is built on. ## Three distribution channels, and one of them is reproducible builds The install story is unusual for an Android keyboard, and it comes down to the three badges at the top of the README. There is a GitHub releases link for the latest release, with the download count badge pointing at the release assets. There is a Google Play listing under the package name com.wasimaster.wmkeyboard. And there is an F-Droid listing for the same package. The F-Droid channel is the one that deserves a note. F-Droid builds from source in a controlled environment and publishes the build metadata, which means the APK can be produced from the source in the repository rather than taken on trust from a vendor. For a keyboard, that is not a minor distinction, because the application is installed with the ability to read everything you type and to see other applications. The repository backs that up with an fdroid/ directory containing the packaging metadata, a fastlane/ directory for the store submission automation, and a play/ directory for the Google Play configuration, alongside the release-notes/ directory. The build system is a Gradle project with build.gradle.kts, settings.gradle.kts, build-logic/ for the convention plugins and a gradle.properties file, with the gradlew and gradlew.bat wrappers at the root. The primary language is Kotlin, the licence is MIT, and the homepage is wmkeyboard.pages.dev, which is the documentation site rather than a marketing page. The README navigation lists install, a tour, languages, privacy, editions, FAQ, and a build it yourself section, so the project expects people to compile it as well as install it. ## A 0.6 line shipping several releases a week The release cadence is the most striking fact in the metadata. The three most recent tags are v0.6.2 from 2026-10-20, v0.6.1 from 2026-10-16 and v0.6.0 from 2026-10-14, so the 0.6 line arrived and then iterated within a single week, and the repository was last pushed on 2026-10-20, the same day as the newest tag. The version numbering is worth reading with care. There is no 1.0, and the versions are 0.6.x rather than 0.1 or 0.2, which suggests an API that has stabilised in shape but is still explicitly pre-release in the semver sense. A keyboard that people install as their daily input method is a different risk category from a library, because a bad update reaches your typing surface immediately. The repository is not archived, so the code is being worked on, and the presence of FEATURES.md, docs/, release-notes/, scripts/ and tools/ directories suggests the project takes its own documentation and release process seriously, which is a good sign for something shipping this fast. There is also a Telegram group badge and a support page, and the description mentions an addon ecosystem, which is the kind of thing that changes the maintenance story of a project like this: once third parties can extend the keyboard, the surface that needs reviewing grows beyond the code in this repository. The concrete next step for an evaluator is therefore narrow. Install the F-Droid build next to your current keyboard, type a paragraph of the language you care about, try the glide path and the phonetic path, and see whether the local prediction holds up with your vocabulary rather than with the dictionary's. ## Conclusion Use WM Keyboard if you type in Bangla, or in another script that your current keyboard only supports through a phonetic engine bolted on, and you are willing to install an input method that can see everything you type. Do not adopt it as a general enterprise keyboard without reading the privacy claims yourself, because an input method is a privileged app by construction. Before you switch your daily driver, install the F-Droid build alongside your current keyboard, test glide typing and the Bangla phonetic engine with the vocabulary you actually use, and check the release notes for the 0.6.x line, where three tagged versions landed between 2026-10-14 and 2026-10-20. ## FAQ ### What is WM Keyboard? It is an open source Android keyboard written from scratch in Kotlin and Jetpack Compose, with prediction, glide typing, transliteration, emoji search and a toolbox of more than 75 tools. The project says the whole intelligence layer runs on the phone and never phones home. ### How do I install WM Keyboard? There are three routes in the README: a prebuilt APK from the GitHub releases page, a Google Play listing, and an F-Droid package, all under the package name com.wasimaster.wmkeyboard. The F-Droid route builds from source in a controlled environment, which matters for an app that can read what you type. ### How does the Bangla input work in WM Keyboard? It uses an Avro-compatible Bangla phonetic engine, so typing a word the way it sounds in Latin letters produces the intended word. The index is lenient, with asI, achi and achhi all reaching the same output. ### Does WM Keyboard send my typing to a server? The project states that everything runs on the device, with no network and no delay for the prediction features, and that the AI panel uses on-device models. The privacy section of the README and the SECURITY.md file in the repository are the places to check the details of that claim. ### What can the WM Keyboard toolbox do? It includes a clipboard with history, pins and one-time codes, snippets, translation, a calculator, a dictionary, a scanner, emoji search and themes, all reachable from feature chips around the keyboard without leaving the text field. ### How often is WM Keyboard released? The three most recent tags are v0.6.2 from 2026-10-20, v0.6.1 from 2026-10-16 and v0.6.0 from 2026-10-14, and the repository was last pushed on 2026-10-20. The 0.6 line is still pre-1.0 and the project ships quickly. ## Sources - [License: MIT](https://github.com/wasi-master/wmkeyboard/blob/main/LICENSE) - [Project website](https://wmkeyboard.pages.dev) - [README](https://github.com/wasi-master/wmkeyboard/blob/main/README.md) - [Releases](https://github.com/wasi-master/wmkeyboard/releases) - [wasi-master/wmkeyboard on GitHub](https://github.com/wasi-master/wmkeyboard) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wasi-master-wmkeyboard