Skip to content

Translate the Japanese navigation command prefixes - #752

Open
yasumorishima wants to merge 1 commit into
daisy:jafrom
yasumorishima:ja-navigate-prefix
Open

Translate the Japanese navigation command prefixes#752
yasumorishima wants to merge 1 commit into
daisy:jafrom
yasumorishima:ja-navigate-prefix

Conversation

@yasumorishima

Copy link
Copy Markdown
Contributor

say-command still set the four prefixes to the English words, so a Japanese
synthesiser said them in English: "move 右", "zoom イン", "read 右",
"describe 右". They are now 移動 / ズーム / 読み上げ / 説明, the way ru, nb,
fr, hu and sv already translate theirs.

This is safe because of $CommandOffset (ec36e05): the offset is the length
of the English $NavCommand stem, not of the spoken prefix, so the suffix test
still matches. ja already carried the right offsets (5/5/5/9) — see #740 for
the two languages that do not.

Word order

Japanese puts the target before the verb, and the particle belongs to the
verb, so a $Particle is now set beside the prefix (に for move, を for read
and describe) and emitted inside each direction branch:

command before after
MoveNext move 右 右 に 移動
ReadNext read 右 右 を 読み上げ
ZoomIn zoom イン ズーム イン
ZoomInAll zoomインを最大にしました ズームインを最大にしました

Keeping the particle inside the branch matters: a command whose suffix matches
nothing (MoveCellUp, MoveStart, …) still falls back to the bare verb, the
way it does in en.

The Zoom commands keep the English order on purpose. ズーム + イン is the
ordinary loanword, and the concatenation that produces
ズームインを最大にしました needs the prefix first. The two suffix sets are
disjoint — Zoom only produces In/InAll/Out/OutAll and the others only
Next/Previous/Current/LineStart/LineEnd — so splitting the branch loses
nothing.

Two rules that would have contradicted it

Reviewing the change surfaced two other rules in the same file speaking the
same words in the other order, so they move too:

  • current (ReadCurrent / DescribeCurrent) never goes through
    say-command; it said 読み上げ 現在 and now says 現在 を読み上げ.
  • move-next-no-auto-zoom-at-edge-math used 右に for all three verbs, which
    gives read and describe the wrong particle. The direction and its particle
    are now part of each verb branch: 右に移動 / 右を読み上げ / 右を説明,
    followed by できません.

Checks

  • audit-translations ja: untranslated text 3577 → 3574; missing rules 0,
    extra rules 0. Rule differences 28 → 30, both of them in navigate.yaml and
    both intended — diffing the audit output against ja shows exactly one
    "variable difference" (the added $Particle) and one "structure difference"
    (the reordered branch).
  • Adds tests/Languages/ja/navigate.rs, the first navigation tests for ja.
    They assert the command prefix with starts_with, because what follows it
    comes from NavigationParts and is not what this touches.

Wiring the new test module in needs one line in tests/languages.rs, which is
the only change outside Rules/Languages/ja and tests/Languages/ja.

🤖 Generated with Claude Code

`say-command` still set the four prefixes to the English words, so a Japanese
synthesiser read them out as English: "move 右", "zoom イン", "read 右",
"describe 右". They are now 移動 / ズーム / 読み上げ / 説明.

`$CommandOffset` (from ec36e05) already makes this safe: the offset is the
length of the English `$NavCommand` stem, not of the spoken prefix, so the
suffix test still matches. ja already carried the correct offsets (5/5/5/9).
ru, nb, fr, hu and sv translate their prefixes the same way.

Word order is the other half. Japanese puts the target before the verb, and
the particle belongs to the verb, so a new `$Particle` is set beside the
prefix (に for move, を for read and describe) and emitted inside each
direction branch: 右 に 移動, 右 を 読み上げ. Keeping the particle inside the
branch means a command whose suffix matches nothing still falls back to the
bare verb, the way it does in en.

The Zoom commands keep the English order: ズーム + イン is the ordinary
loanword, and the concatenation that produces ズームインを最大にしました
requires the prefix to come first. The two suffix sets are disjoint (Zoom only
produces In/InAll/Out/OutAll, the others only Next/Previous/Current/LineStart/
LineEnd), so splitting the branch loses nothing.

Two other rules in the same file spoke the same words in the other order and
would have contradicted this, so they move too:

- `current` (ReadCurrent / DescribeCurrent) said 読み上げ 現在; it now says
  現在 を読み上げ.
- `move-next-no-auto-zoom-at-edge-math` said 右に for all three verbs, so
  read and describe got the wrong particle; the direction and particle are now
  part of each verb branch (右に移動 / 右を読み上げ / 右を説明 できません).

audit-translations ja: untranslated text 3577 -> 3574; missing rules 0, extra
rules 0. Rule differences 28 -> 30, both in navigate.yaml and both intended:
one "variable difference" for the added `$Particle`, one "structure
difference" for the reordered branch.

Adds tests/Languages/ja/navigate.rs, the first navigation tests for ja. They
assert the command prefix with starts_with, because the description that
follows comes from NavigationParts and is not what this change touches.
Wiring it up needs one line in tests/languages.rs, which is outside
Rules/Languages/ja and tests/Languages/ja.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016JCoREgn1pJzcbdnUx4iuh
@yasumorishima

Copy link
Copy Markdown
Contributor Author

The one red check here is not from this PR.

  • Failing test: Languages::en::alphabets::cap_cyrillic, in Test (no-unsafe, Rules.zip)job. The panic is 'RefCell already borrowed' at src/speech.rs:2799, i.e. re-entry while the full unicode table is being loaded, not a speech mismatch.
  • The same tree passes that same job on my fork: success.
  • This PR only touches Rules/Languages/ja/navigate.yaml, tests/Languages/ja/navigate.rs and one line of tests/languages.rs; it does not touch anything the Cyrillic alphabet test reads.
  • I have seen the same job fail non-deterministically before, on 2026-08-29, where the two runs of one commit disagreed (one red, one green) with this identical panic.

I could not find an existing issue for it (searched RefCell already borrowed and cap_cyrillic). Happy to open one with these two runs as evidence if that would be useful — I did not want to file it uninvited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

1 participant