What gets written here

Most software isn’t written by people who use it in Japanese. That’s not a complaint. It’s structural. You can’t see a gap you’ve never stood in front of.

I’m a Japanese developer in Tokyo. I read global software the way a Japanese user reads it, and the same holes keep turning up. CJK that breaks when a name carries an unusual character. The 特定商取引法 disclosure page that foreign SaaS almost never has. Japanese that starts out polite and drifts into machine translation halfway down the screen. An IME edge case that only shows up when you are actually typing Japanese, which the people who shipped it never were.

This page is where I write those down.

Not marketing. Teardowns and fixes. When I chase a half-width kana bug through some project’s text-shaping and it ends in a one-line change, the fix isn’t the interesting part. The path is. So that’s what goes here: the trace, the thing I got wrong on the way, and the diff at the end.

# What I won’t do

I write about what I actually touched. If I didn’t trace it myself, I won’t pretend I did. Some of this is open questions I don’t have the answer to yet, and I would rather say so in the piece than round up to a clean conclusion. No revenue promises, no one-weird-trick. The receipts sit on GitHub, and you should check them.^[1]

Why in the open, and why faceless: because the work is the identity, not a name. Take away the face and what is left is the voice and the merged commits. Both are checkable. That is the whole point.

# Adding a piece

Anyone can. There is no account here and no editor. A post is a Markdown file in a public repo with a small header:

---
title: How a half-width kana broke a search box
date: 2026-07-01
description: One sentence that answers the question up front.
lang: en          # en | ja
tags: [cjk, ime]
type: tech        # tech | post
---

Write the file, open a pull request. Same rule I hold myself to: write what you actually found.