kawaii-gcc: rewriting the GCC compiler's error messages

The compiler's messages are just a translation catalogue

The mechanism is simpler than the project name suggests. GCC's user-facing output is localised through gettext, which means the strings you see when a compilation fails live in a compiled message catalogue file, a .mo file, installed under the locale directories. The kawaii-gcc project takes that catalogue and replaces it with one whose messages are written in a cute style.

The README states the approach plainly: it makes the output messages from the GCC compiler look kawaii by editing the localization file of GCC. Nothing is patched inside the compiler binary, no source build of GCC is required, and no compiler flag is involved. You install a file in the right directory and tell the system which locale to use.

That is what makes the project a good first taste of localisation tooling. The vocabulary is gettext, the artefacts are .po source files and .mo compiled files, and the same pipeline that a translator uses for a real product is used here for a joke. A Japanese-language README is the primary documentation, with README-zh.md for Chinese readers, and the README opens by inviting people to contribute more kawaii messages, since the message set is the community-editable part of the project.

The Makefile turns .po sources into .mo catalogues

The build is a Makefile, which is also the project's primary language. The default target assembles four catalogues:

all: zh-origin zh_CN-kawaii zh_TW-kawaii ja-kawaii

%: src/%.po | build
	msgfmt -o build/$*.mo $<

Each .po file is compiled to a .mo with msgfmt, and the build directory is created as a prerequisite by a separate build target. The naming is revealing: zh-origin, zh_CN-kawaii, zh_TW-kawaii and ja-kawaii are four separate catalogues, so the origin set and the themed variants are kept apart rather than patched in place.

The variants are assembled by concatenating a patch file over the origin file, with the patch taking precedence:

src/zh_CN-kawaii.po: src/zh-origin.po src/zh_CN-kawaii-patch.po
	msgcat -o src/zh_CN-kawaii.po --no-wrap --use-first src/zh_CN-kawaii-patch.po src/zh-origin.po

So the workflow is: take the upstream message set, write a patch that replaces selected strings, and merge. The --no-wrap option keeps the long themed messages on one line, and --use-first means the patch wins wherever both files define the same message. A clean target removes the merged .po files and the build directory, which tells you the merged files are generated artefacts and the patch plus origin files are the sources of truth.

Installing on Ubuntu: language packs, gettext and one file

The Linux instructions are the most complete in the README, and they run on an Ubuntu example. First the Japanese language packs for the terminal, then the toolchain and gettext:

sudo apt-get install language-pack-ja language-pack-gnome-ja language-pack-ja-base language-pack-gnome-ja-base
sudo apt-get install gcc gettext g++

The locale catalogue for the compiler is a separate package, and the version has to match your compiler. The README asks you to check the main version number with gcc -v, gives 12.3.0 as an example, and says the main version number is therefore 12. With that number in hand you install the matching locale package:

sudo apt-get install gcc-12-locales

Then the file itself. The default location is /usr/share/locale/ja/LC_MESSAGES/gcc.mo, but the README warns that the file may be missing or named gcc-12.mo instead, and asks you to back up any file you find. The prebuilt catalogue is downloaded straight into place:

sudo wget https://github.com/Bill-Haku/kawaii-gcc/raw/main/prebuilt/gcc.mo -O /usr/share/locale/ja/LC_MESSAGES/gcc-12.mo

If you would rather compile the catalogue yourself, msgfmt does it from the .po source, and the README notes that gcc.po is the ja_JP localisation file while gcc-zh.po is the zh_CN one.

LANG and LANGUAGE decide whether you see the kawaii text

The last step is the one people miss. Dropping a file into the locale directory does nothing on its own, because gettext only reads a catalogue when the active locale asks for it. The README asks you to add two exports to your shell profile and reload it:

export LANG="ja_JP.UTF-8"
export LANGUAGE="ja_JP.UTF-8"

The Japanese variable is what the project documents for the Japanese build. The Chinese README covers the zh_CN case, and the macOS section of the README shows the same two variables set to zh_CN.UTF-8 in a bashrc and in a fish config.

Two consequences follow. The first is that the setting is per shell session and per user, which is why it belongs in a profile file rather than in a script. The second is that the language choice is a side effect: setting LANG for the whole session also changes the language of other tools in that session, not only GCC, so a machine set to ja_JP.UTF-8 will produce Japanese output from many other programs too. The README's own test command is the way to see the result:

gcc test.cc -Wall

The project ships a test.cc file, and the -Wall flag is there to make the compiler emit all of its warning messages, which is what gives the themed catalogue something to print.

Windows through Cygwin, macOS through OrbStack

The README covers two non-Linux routes. On Windows the toolchain comes from Cygwin: run setup-x86_64.exe, choose Install from Internet, then use the View filter and select gcc-core, gcc-g++ and gettext under the ALL/Devel panel. You add the bin directory of the Cygwin install to the Path environment variable, remove any mingw entry from that path, and set a LANG environment variable to ja_JP.UTF-8. The gcc.mo file from the prebuilt directory is moved into the share/locale/ja/LC_MESSAGES directory of the install, keeping the name gcc.mo, and backing up an existing file is recommended.

On macOS the documented path is OrbStack, a Linux virtual machine. You enable the desired locales with locale-gen by uncommenting the language in /etc/locale.gen and running sudo locale-gen, set LANG and LANGUAGE in the shell configuration, and add aliases in the host zshrc so that the host gcc command reaches the Linux toolchain:

alias gcc='orb gcc'
alias g++='orb g++'

The README also notes that the compiled output targets Linux, so binaries are run with orb ./, and that Arch Linux users of the AUR kawaii-gcc package can paste configurations into a zh_CN directory. A native macOS GCC is not covered, which is the point of the virtual machine route.

Where the joke stops: system paths, version numbers and upgrades

Three practical limits are worth knowing before you install this on a machine that matters. The first is that the catalogue lives in a system directory, /usr/share/locale, and the README's own commands write there with sudo. That is a modification to the operating system's package area, and it will be undone by an upgrade of the gcc-N-locales package or the language packs, which is why backing up the original file matters and why a container or a throwaway VM is the friendlier place to try it.

The second is the version coupling. The example installs gcc-12.mo into a path for GCC 12, and the README has to explain the naming rules, use the existing name if there is one, try gcc-<MAIN VERSION NUMBER>.mo first and rename to gcc.mo if that does not work. A mismatch between the catalogue and the compiler is a file that is never read, which shows up as English messages rather than as an error.

The third is that the messages are not the compiler's own. Only the catalogue is themed, so flag parsing, error positions and the shape of the output stay exactly as they were, and the jokes are the strings GCC chooses to print. The catalogue also has to track GCC's message set. When upstream adds or renames a message, a catalogue that has not been updated simply falls back to the original English for that string, so the joke thins out as the compiler moves. Nothing in the README documents a mechanism for that resync beyond the invitation to contribute.

GPL-3.0, v0.7.0 and the last push in August 2026

The project is licensed under GPL-3.0, with a LICENSE file at the repository root, and the top-level tree is small: a Makefile, a src/ directory of.po files, a prebuilt/ directory of compiled catalogues, a test/ directory, an img/ folder and the two READMEs. The distribution is a handful of files rather than a build system, and the release list shows tags v0.7.0 dated 2026-08-24, v0.6.0 from 2025-02-15 and v0.5.0 from 2025-02-13. The last push was on 2026-08-24, the same day as the 0.7.0 tag.

A 0.x version number is the honest signal about the state of the catalogue, and it pairs with the fact that the README's Linux path was written for a specific Ubuntu release and a GCC 12 layout. Expect the file naming to be the part that needs attention on a newer distribution, and expect the message set to lag behind a recent GCC.

Credit where it is due: the README says the project was inspired by gcc-hentai, describes it as a Chinese project, and explains that the author created a Japanese version, added new text, edited the instructions and recorded a video. The upstream project is Chinese, and this repository was created to offer a Japanese version and share it with Japanese users.

Editorial conclusion

Adopt kawaii-gcc on a personal Linux box or a demo machine where a failing build is a private moment rather than an incident, and follow the README path of installing a language pack, dropping the .mo file into the locale directory and exporting LANG and LANGUAGE. Do not adopt it on a shared build server, where the messages are read by people who did not choose the language, or as a way to localise GCC for a team, since the catalogue is a themed translation rather than a translated product. Before you install, back up the existing gcc.mo or gcc-12.mo file, confirm your GCC main version with gcc -v, and expect your distribution's package upgrade to overwrite the file you dropped into /usr/share/locale.

Frequently asked questions

Official sources

1. Bill-Haku/kawaii-gcc on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases