Working in Korean with toker

toker is an interface for using Claude Code in Korean. A request can begin in Korean, pass through local translation into English, and continue through the coding agent. The answer comes back through another translation step so the conversation can be read in Korean.

The project explores a practical question: can the language used to explain a task remain comfortable for the person, while the exchange sent to the model is handled in English? Answering that means paying close attention to everything that crosses the translation boundary.

1. Keep the intent in view

A coding request contains more than a description of a feature. It may include constraints, exceptions, examples, and a particular reason for making the change. Losing one of those details can alter the task while leaving the translated sentence perfectly readable.

toker starts with the idea that Korean should remain a useful working language throughout that exchange. The person should be able to explain a problem, read the response, and answer a follow-up question without repeatedly rewriting the conversation by hand.

There is also an efficiency question behind the project. An exchange in English may change the token budget of a task, but the value of that change depends on the entire workflow. Translation time, retries, output length, and the effort needed to check the result all belong in the comparison. The design needs to keep them visible enough to evaluate.

2. Add a boundary around the existing agent

The coding work is still carried out by Claude Code. toker handles input, translation, conversation presentation, and the connection to that existing agent. This keeps the language layer focused on a specific responsibility.

The main exchange has four steps:

1. The person writes a request in Korean.
2. A local translation step prepares an English request.
3. The coding agent carries out its conversation and tool workflow.
4. The response is translated for Korean presentation.

That separation makes the boundary easier to inspect. A translation problem can be examined as a translation problem. A coding action still needs to be understood through the agent's execution and permission behavior. Making the language more familiar does not remove that responsibility.

3. Decide what must remain unchanged

A request often mixes prose with code, identifiers, command names, and pasted output. These pieces need different treatment. A function name may be a precise reference to something in a repository, and a command flag may change what an operation does.

toker separates fenced code blocks from the surrounding prose and preserves those blocks directly. Its command handling also separates a slash command and its leading flags from the arguments that need translation. That lets the instruction text change language while the command itself stays recognizable to the coding agent.

On the response side, inline code and other protected spans can be temporarily masked during translation and restored afterward. Markdown presentation is handled separately from the prose conversion. These boundaries reduce the amount of technical content that a translation model is asked to rewrite.

They also make the remaining uncertainty easier to name. Plain prose can still contain an important identifier or a subtle condition. A set of protected spans helps, but the quality of the full translated request still needs to be checked.

4. Handle the translator's own failure modes

A translation model can respond to an instruction instead of translating it. For a coding workflow, that is a particularly awkward failure: an explanation or an attempted answer can replace the request that was supposed to reach the agent.

The implementation uses translation-specific instructions, delimited source text, and examples of the expected transformation. It also checks suspicious output patterns and can retry with stricter instructions. These are practical signals, with limits; a heuristic cannot establish that every part of the original meaning survived.

When input translation fails or still looks unreliable, the boundary can pass the original text through. When response translation fails, it can preserve the original response. This favors keeping the conversation available, and it has an important consequence: using English throughout the exchange is not guaranteed on every path.

Local translation also needs to be understood within the full coding workflow. The translation step runs locally, while the coding agent has its own communication with the upstream service. A fallback that preserves the original language can become part of that communication. Claims about privacy or token savings have to account for that complete path.

5. Preserve the conversation around the code

Coding work develops through a sequence of decisions. A later request can depend on an earlier constraint, a question that was answered, or a change that has already been made. The language layer has to remain useful across that continuing conversation.

toker includes a persistent connection to the coding process, along with session reset and resume behavior. It also handles structured questions from the agent so that questions and options can be presented in Korean and the choice returned to the conversation.

Permission handling is another boundary to keep explicit. A translated question can make an action easier to understand, but the actual execution policy depends on how the wrapper and the coding agent are configured. Readable wording and enforceable permissions are separate responsibilities.

I want the interface to make those distinctions easier to follow. The person should be able to understand what is being asked, what text was passed onward, and what work the agent actually performed.

6. Make the answer readable in a terminal

Returning Korean text introduces a second interface problem: presentation. Korean and English characters occupy different amounts of terminal space, so character count alone does not describe the width of a line or a table cell.

The implementation shares display-width handling across the input and output interface. Its Markdown renderer presents headings, emphasis, inline code, and tables using formatting suited to the terminal, while the translation boundary keeps fenced code separate.

This work is small compared with the coding agent, but it affects every response. A correctly translated table is difficult to use if its columns drift. A technical answer becomes harder to scan if formatting markers and prose run together. Language support includes the way a result is laid out and read.

7. Measure the whole exchange

The useful test for toker is a complete coding task. A smaller message sent to the model is one possible result; preserving the request and returning understandable work are essential parts of the same evaluation.

I would compare equivalent tasks on a few concrete questions:

• Did the translated request preserve the constraints and exceptions?
• Did executable content and important identifiers remain intact?
• What happened to token use and elapsed time across the whole exchange?
• How much checking or correction did the person need to do?

Those questions set a more useful standard than a blanket savings claim. A translation that changes the task creates extra work, even if the individual request is shorter. A workflow that saves tokens also needs to remain understandable when it retries, falls back, or asks for a decision.

That is the direction I want to explore with toker: a language layer whose transformations can be examined, and a coding conversation that stays clear as it moves between Korean and English.

The source code is not publicly available yet.