ja: the phrases that were carried over word for word

[yasumorishima]

Each of these phrases was translated token by token, in English order, so the Japanese carries the words and not the work they were doing. Where a phrase is split across several t: entries the fix moves material between them — the same thing the merged navigation work (#752, #773) had to do — and the en phrase(...) comments are left alone.

	was	now
{x | x > 2}	集合 すべて x そのようなこと x は 大なり 2	集合 すべての x ただし x は 大なり 2
P(A | B)	A 与えられた B	A 条件は B
a labelled row	行 1 ラベルを使って 第1式	行 1 ラベルは 第1式
f|_a^b	f 評価される b 同じ式が評価されるマイナス a	f 次の点で評価 b マイナス 同じ式を次の点で評価 a
round()	ラウンド値	丸めた値
fenced-group	フェンスグループ	括弧のまとまり

Why each one:

• そのようなこと is “such a thing”. It translates the words of “such that” and none of its work, which is to attach a condition to what was just named; ただし is the word Japanese mathematical prose uses for that.
• 与えられた is the past participle “given”, and a Japanese past participle modifies the noun after it — so B was being described rather than named as the condition. 条件は names it.
• ラベルを使って is “using a label”, which says the row does something with one. The label is simply what the row is called.
• 評価される is the passive “is evaluated” with nothing to say where, and 同じ式が評価されるマイナス put the minus last, so the subtraction arrived after the thing being subtracted.
• ラウンド値 is “round” in katakana with 値 stuck on the end, and フェンスグループ is an English term in katakana that carries no Japanese meaning.

One deliberate choice worth flagging: 集合 stays in front of the variable rather than moving to the head-noun position Japanese would normally give it. In a speech stream it tells the listener what they are about to hear, and the first argument can run long — {x ∈ ℤ : x > 5} is already in the test suite.

Each phrase is swept across every file that carries it, including the sibling branches the audit did not flag: unicode.yaml has two more givens, SharedRules/general.yaml a second evaluated at, and definitions.yaml the intent mappings for such-that, given and conditional-probability. The copy of such that in unicode-full.yaml is left alone, since that file is waiting on a MathPlayer seed.

Measurements

audit-translations ja, against this branch's merge base:

	before	after
untranslated text	3415	3400
rule differences	30	30
missing / extra rules	0 / 0	0 / 0
missing / mismatched / extra definitions	0 / 0 / 0	0 / 0 / 0

The drop is exactly the number of rule lines promoted. definitions.yaml entries carry no case marker, so they do not move that count.

Tests

Five new in ja.rs, plus one updated: set_builder_member_symbol had pinned the old reading. To check that the tests hold the readings rather than merely passing, I pushed a branch reverting every reading and nothing else — exactly those six went red.

This does not conflict with #778; I measured git merge-tree in both orders.

[moritz-gross]

@yasumorishima Merging main fixed some of the CI issues for me. though I still don't understand what went wrong in the first place. maybe try merging main again here as well?

[moritz-gross]

hmmm, now we have 103 files changed in total, as the ja branch was outdated to main anyway. This should be fine right?
I mean, what's the plan on when to merge this back into main anyway? I feel like the progress on Japanese has been enough to ship it.

[yasumorishima]

Merged main (374ea588) in — no conflicts, and nothing of mine moved: git diff between the pre-merge commit and the merge for Rules/Languages/ja and tests/Languages/ja is empty, and the branch's diff against main is still only the ja files plus the four-line registration in tests/languages.rs.

Test (no-unsafe, Rules.zip), the job that was failing, passes on the merged head in 6m28s. Rules-minimized.zip, both builds, both clippy runs, the Python tests and the rules zip are green as well; Build and fuzz is still running.

I do not know what the original failure was either. What I could measure at the time is in #781: the panic was RefCell already borrowed from speech.rs, the failing test was not fixed — en::alphabets::cap_cyrillic in one run and zh::tw::alphabets::cap_cyrillic in another on this same branch — and Rules-minimized.zip passed in the same runs. With one green run I cannot tell whether the merge removed the cause or only changed the timing, so I would not read this as a diagnosis.

[moritz-gross]

can you please make your messages easier to read? While I agree on the technical side, this heavily looks like it is written by Claude. I'm also using AI agents in my workflow, but I think that messages in discussions here on GitHub should remain human-authored (and potentially AI-translated).

so I think we can merge this. on the question regarding the integration into main: have you heard anything from Neil on what the plan is when that should happen, or what the conditions for that are?

[yasumorishima]

On the 103: yes, but one part of it was not fine until a minute ago, so let me give the measurements on the head I just pushed (ce129706).

Against main this branch is 15 files, +11,136, −0 — the whole Rules/Languages/ja and tests/Languages/ja tree plus four lines in tests/languages.rs, since ja is not in main at all yet.

Against the base branch ja it is the 103 you see. 95 of those files come from main, and on every one of them this branch is byte-identical to current main: git diff main HEAD -- <those 95 paths> prints nothing. So merging reverts nothing of main's and introduces nothing of mine outside ja. The remaining 8 files are this PR's own work, +80 −22.

The part that was not fine: my branch predated your merge of #778, so until now the diff against ja also looked as though it took the verified navigation strings back out. I have merged ja in as well, and git diff ja HEAD -- Rules/Languages/ja/navigate.yaml now shows nothing at all — #778 is untouched. Thank you for asking about the file count; that is what surfaced it.

On when to merge ja into main — that is your call, and here is the state I can measure on this head with audit-translations ja:

• Missing rules 0, extra rules 0, rule differences 30 — the same 30 as before, the ones I changed deliberately carry # audit-ignore.
• Untranslated text 3,400, but that is a review-status count rather than English reaching a user: of the lowercase t:/ot:/ct: values, 3,271 are already Japanese and exactly 6 are pure ASCII, those six being - - -, 1, 2, 3, . and ..
• 2,816 of the 3,400 sit in unicode-full.yaml, which I have deliberately left alone because NSoiffer said he would seed it from the MathPlayer Japanese data.
• That file is also where the readings I would least like to ship still live: ∋ 会員を含む, ∌ 会員は含まない, ∍ 会員を含む — 会員 is a club member — and ∅ 空のセット, ∖ セットマイナス, ≺ プリセット (U+227A, which is "precedes", not a preset). None of those six characters is in unicode.yaml, so replace_single_char falls through to unicode-full.yaml and a user hears them today.
• "Missing definitions 1" is FunctionApplicationWord; en is the only language in the repository that defines it, so ja is not behind the other translations there.
• 104 tests under tests/Languages/ja.

So the rules files are in a state I would be happy to see shipped. The one thing I would want decided before or soon after a merge is those six unicode-full.yaml readings, since they reach users now and the seed has not arrived. If you would like, I can send a small PR that changes only those six and leaves the rest of the file for the seed — otherwise I will leave the file as it is.

[yasumorishima]

Sorry, that was far too long. I'll keep these short.

No, I haven't heard anything from Neil about the timing or the conditions for merging ja into main. He has only said two related things to me. In #715 he mentioned he has Japanese data from MathPlayer that could seed the unicode files, and in #720 he said he will approve changes that stay inside the Japanese directories, since he can't review the language himself.

[moritz-gross]

next time I talk to him, I'll ask. Thanks for all your work!