imewlconverter: converting IME dictionaries between Sogou, Rime, Gboard and 20 other formats

The dictionary lock-in problem imewlconverter attacks

Input method editors accumulate a personal dictionary over years. Sogou stores cell dictionaries as .scel files, Baidu uses .bdict, QQ Pinyin uses .qpyd and .qcel, and each of those is a binary container with its own layout. When you switch to Rime, or move from an Android phone to a desktop, the entries do not come along. Retyping a few thousand names, place names and technical terms is not realistic.

imewlconverter exists to sit between those formats. The README describes it as an input method dictionary conversion program supporting more than 20 input method tools and dictionaries, with batch conversion, a command line mode, and builds for Windows, Linux and macOS. The intended user is someone who owns a dictionary file and wants the same entries in a different editor, not someone building an IME from scratch. The repository also ships a Windows GUI project and a macOS project alongside the command line tool, so the same core handles both paths.

How the conversion pipeline is structured

The repository separates the core from the front ends. src/ImeWlConverter.Core holds the conversion logic, src/ImeWlConverterCmd is the command line tool, and there are separate projects for the Windows and macOS applications. The command line tool is the one the README documents in detail, and it is the one that runs on all three platforms.

Conversion is expressed as a pair of format codes. You pass -i for the input format, -o for the output format, -O for the output file, and then one or more input files. The README's format table lists the codes, for example scel for Sogou cell dictionaries, sgpy for Sogou text format, sgpybin for Sogou backup dictionaries, qqpy for QQ Pinyin text, qpyd and qcel for QQ Pinyin binary dictionaries, bdpy and bdict for Baidu, rime for Rime, gboardbin for Gboard user_dict_3_3, and self for a custom format.

The table also marks direction. Several codes are import only: qpyd, qcel and bdict have a tick in the import column and a cross in the export column. That asymmetry is the single most useful thing to read before planning a migration, because it decides whether a format can be a destination or only a source. The integration test suite mirrors this split: the README says it covers import tests (many input formats to a unified CSV) and export tests (unified CSV to many output formats), which implies the pipeline normalises through an intermediate representation rather than converting pairwise.

Installing imewlconverter and running a first conversion

The command line tool is built from source. The README requires .NET SDK 10.0 or newer and suggests confirming it with dotnet --version. There is no published package command in the README; the install path is clone, build, run.

git clone https://github.com/studyzy/imewlconverter.git
cd imewlconverter
dotnet build src/ImeWlConverterCmd

After the build, the README states the tool lands at src/ImeWlConverterCmd/bin/Debug/net10.0/ImeWlConverterCmd.dll and is run through dotnet. Checking help is the fastest way to confirm the build worked.

dotnet src/ImeWlConverterCmd/bin/Debug/net10.0/ImeWlConverterCmd.dll --help

A first real conversion takes a Sogou .scel cell dictionary and writes Sogou text. The README uses a bundled test file for this example.

dotnet src/ImeWlConverterCmd/bin/Debug/net10.0/ImeWlConverterCmd.dll \
  -i scel -o sgpy -O 唐诗300首.txt \
  "src/ImeWlConverterCoreTest/Test/唐诗300首【官方推荐】.scel"

Swapping the output code to rime and the extension to .yaml produces a Rime dictionary from the same input. The README also documents dotnet run --project src/ImeWlConverterCmd -- with a -- separator, which avoids tracking the DLL path. A Makefile is provided as the recommended build route, with make build-cmd for Debug and DOTNET_CONFIG=Release make build-cmd for Release. If you would rather not build, the repository contains a Dockerfile that downloads a release tarball, though it pins runtime 3.1 and VERSION v2.7.0, which is far behind the v3.4.3 release listed for this repository.

Filters, batch mode and the GNU-style argument change

Raw conversion is rarely enough. The README documents a filter flag that runs after reading and before writing, with pipe-separated rules such as len:1-100, rm:eng and rm:num. That combination drops single-character and very long entries and strips entries containing English or digits, which is a common cleanup when a cell dictionary mixes in junk.

dotnet ImeWlConverterCmd.dll -i scel -o ggpy -O output.txt -f "len:1-100|rm:eng|rm:num" input.scel

Batch handling has two shapes. Passing several files after the flags merges them into one output file. Passing a glob with an output argument ending in a slash writes one output file per input into that directory. The README shows both forms.

One migration trap is documented explicitly: from v3.0.0 the command line arguments moved to GNU style. Older invocations such as -i:scel no longer match, and the README points to docs/MIGRATION.md. Anyone copying a command from an older blog post will hit this.

Where imewlconverter fails or is the wrong tool

The export column is the hard boundary. If your destination is a QQ Pinyin .qpyd or .qcel file, or a Baidu .bdict file, the table marks export as unsupported. You can read those formats and write something else, but you cannot produce them. A migration into one of those three formats has to go through a text format the target editor can import.

The platform story is uneven. The README states the software supports Windows, Linux and macOS, and the Makefile builds command line, macOS and Windows projects. But the Windows GUI project path contains spaces, and the documented first-use path for every platform is the command line tool. A Linux desktop user who wants a window has no documented option in the README; the GUI is a Windows and macOS concern.

Version drift in the Dockerfile is a real risk. It pins mcr.microsoft.com/dotnet/core/runtime:3.1 and downloads imewlconverter_Linux_Mac.tar.gz for VERSION v2.7.0, while the repository's latest release is v3.4.3. Anyone using that image is running an old converter with old format support, and the argument syntax changed at v3.0.0, so the entrypoint's default -h and any flags you pass may not behave as the current README describes. The Dockerfile is also not mentioned in the README's install section, so it is not the maintained path.

Finally, the README does not document rollback, and it does not describe what happens to entries whose encoding cannot be represented in the target. The integration tests exist, but the README does not state coverage per format pair, so a successful exit code is not by itself proof that a specific pair round-trips.

How this differs from writing a Rime dictionary by hand or scripting it

The obvious alternative is a small script: parse your source file, emit the target format. For Sogou .scel or Baidu .bdict that means reverse-engineering a binary container before you write a single line of output. imewlconverter already carries readers for those containers, plus the code tables behind them.

The second alternative is the editor's own import. Rime, for instance, consumes YAML dictionaries, and some editors accept plain text. That works when your source is already text. It does not help when the source is a .scel, .qpyd, .qcel or .bdict file, which is exactly the case the format table is built around.

The third alternative is a different converter project. The related search terms around this repository include Palminput and KBLAutoSwitch, but neither is described in the README, so no comparison can be made from it. What can be said is that imewlconverter's distinguishing property is breadth of format codes in one tool, and the direction flags on each code. If your pair is import-only on both sides, no converter helps and you need an intermediate text format.

Maintenance, licence and what upgrading costs you

The repository is not archived, and its last push was on 2026-09-15. Releases are frequent: v3.4.1 on 2026-05-12, v3.4.2 on 2026-05-28, v3.4.3 on 2026-06-29. That cadence suggests active work, and the presence of a CLAUDE.md, CODEBASE_ANALYSIS.md and an openspec directory suggests the maintainers are also investing in tooling around the codebase.

The licence is GPL-3.0. For a command line tool you run locally to convert your own dictionary, that is unremarkable. It matters if you want to embed the converter in a closed product or ship a modified binary without source. This is a description of the licence identifier, not legal advice; read LICENSE and get your own counsel if you plan to redistribute.

Upgrade cost is concentrated in the argument syntax. The move to GNU-style flags at v3.0.0 means any script you wrote before that version needs rewriting, and docs/MIGRATION.md is the reference. Format codes themselves have been stable enough that the README's table still lists scel, sgpy and rime as the everyday codes. The .NET 10 requirement is the other cost: an older SDK will not build src/ImeWlConverterCmd.

Editorial conclusion

Adopt imewlconverter if you are moving a personal dictionary out of Sogou, QQ Pinyin, Baidu or Microsoft Pinyin and into Rime, Gboard or a plain text file, and you are comfortable running a .NET command. Do not adopt it if you need a GUI on Linux, a binary-only install, or a format whose code is absent from the table. Verify first that the code for your source and target appears in the --list-formats output and that the export column is ticked, because several formats import only.

Frequently asked questions

Official sources

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