---
title: "Separate Ticket record language from worker response language"
state: "closed"
created_at: "2026-06-08T03:29:11Z"
updated_at: "2026-06-08T08:21:55Z"
queued_by: "workspace-panel"
queued_at: "2026-06-08T05:51:29Z"
---

## Background

Profiles/Manifests currently provide `worker.language`, which controls normal Pod prose responses. This is not the same as the language used for durable Ticket records.

Ticket records are authored by multiple paths:

- LLM role Pods writing Ticket comments/reviews/decisions;
- typed Ticket tools generating state-change/intake/close events;
- Panel/CLI generated notices/resolutions;
- scaffold/default Ticket bodies.

This project wants to distinguish:

- response language: how a Pod replies to the user in conversation;
- Ticket record language: the language used for durable Ticket `item.md`, `thread.md`, `resolution.md`, and generated Ticket event bodies.

Currently `.yoi/ticket.config.toml` has no language setting. Role profiles can set `worker.language = "Japanese"`, but that does not provide a backend/tool-level policy for machine-generated Ticket text.

## Goal

Add an explicit Ticket record language configuration separate from Pod response language.

## Requirements

- Add a Ticket config setting for durable Ticket record language.
  - Candidate shape:

```toml
[ticket]
language = "Japanese"
```

  - Avoid overloading `[worker].language` or Profile settings for this purpose.
- Define the boundary clearly:
  - `worker.language`: conversation/prose responses by a Pod.
  - `ticket.language`: durable Ticket records and generated Ticket event/resolution/scaffold text.
- Make typed Ticket tool/backend generated text consult `ticket.language` where practical.
- Ensure LLM role prompts can receive or reference Ticket record language so comments/reviews/decisions use the configured Ticket language even if the Pod response language differs.
- Preserve existing behavior when `ticket.language` is absent, using the current/default language policy.
- Update `.yoi/ticket.config.toml` scaffold and parser.
- Update project `.yoi/ticket.config.toml` to set the desired Ticket record language.
- Avoid translating protocol literals, file paths, commands, logs, identifiers, or quoted external text merely because Ticket language is set.

## Design questions

- Should the config key be `[ticket].language`, `[records].language`, or `[backend].language`?
  - Prefer `[ticket].language` because this is record-generation policy, not storage backend mechanics.
- Should tool-generated default bodies/resolutions be localized immediately, or should this ticket only thread the config through and update the most visible generation paths?
- How should existing Tickets be handled? Do not rewrite existing records unless explicitly requested.

## Acceptance criteria

- Ticket config can specify a Ticket record language independently of Profile/worker language.
- Role launch prompts/tool instructions expose the Ticket record language to Intake/Orchestrator/Coder/Reviewer where they write Ticket records.
- Typed Ticket-generated events/resolutions/scaffold have a clear policy for using the configured language.
- Absence of `ticket.language` preserves current behavior.
- Existing Tickets are not bulk-translated or rewritten.
- Tests cover config parsing/scaffold/default behavior and at least one generation/role prompt path.
- `target/debug/yoi ticket doctor`, focused tests, `cargo fmt --check`, and `git diff --check` pass.