i18n(ja): fix defects found in dedicated review of large reference files - #23580
Conversation
Reviewed 7 large top-level files that had never gotten a dedicated defect-review round (system-variables.md, tikv-configuration-file.md, pd-control.md, optimizer-hints.md, sql-tuning-best-practice.md, sql-plan-management.md, latency-breakdown.md), comparing each 1:1 against its English source. sql-tuning-best-practice.md had zero genuine defects; the other 6 needed fixes: - optimizer-hints.md: 3 hint-name/placeholder headings were translated as Japanese prose instead of being kept as the literal identifier (STRAIGHT_JOIN(), RESOURCE_GROUP(resource_group_name), SET_VAR(VAR_NAME=VAR_VALUE)), inconsistent with every sibling heading in the file; plus one dropped に particle. - tikv-configuration-file.md: 6 sites using the HTML entity `>` where EN uses a literal `>` (or `\>` in one MDX-escaped case), missed by the earlier corpus-wide entity sweep (PR pingcap#23570) since this file was never included in it. - pd-control.md: 8 dropped は particles (code-span subject followed by a bare comma instead of は before the verb, breaking 8 config- option descriptions), plus one mistranslation from a garden-path reading of an awkward EN sentence ("factors in" parsed as a noun instead of a verb). - sql-plan-management.md: a dropped は particle, an ungrammatical ずつ usage, a missing colon before a trailing code span, a missing "/" between PREPARE and EXECUTE (2 occurrences), and 3 more `>` entity-vs-literal mismatches on one line. - latency-breakdown.md: the term "PointGet" was inconsistently rendered (獲得中/取得中/バッチPointGet) in 3 places instead of matching this file's own heading convention of keeping PointGet / Batch PointGet in English; plus one verb-to-noun fix for parallel list structure (提案する -> 提案, matching コミット/適用). - system-variables.md: two duplicated-word typos (照合照合順序 -> 照合順序); a genuine Scope/Range label collision affecting 126 variable entries where both the Scope field and a numeric Range field were labeled "範囲:" in the same entry, making them indistinguishable (unified the Scope label to the already-used alternate "対象範囲:" only where it collided with a Range field, not the ~169 non-colliding entries using either label, which is pure notation variance out of scope here); 18 zero-width-space (U+200B) MT artifacts removed; 2 dropped が/を particles in the tidb_restricted_read_only cross-effect bullet list; one value description rephrased from an imperative command ("...しないでください") to a declarative description ("...しません"), matching EN's descriptive (not imperative) phrasing and the style of sibling value descriptions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
test seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughJapanese documentation wording, terminology, scope labels, SQL Plan Management descriptions, and HTML entity rendering were corrected across six Markdown files. Product behavior, metrics, configuration semantics, and system variables were not changed. ChangesJapanese documentation updates
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🔵 Low · up to This documentation-only PR corrects Japanese translation defects and is mergeable with owner follow-up for localized Markdown formatting issues: one code fence may render outside its list item, and several changed list markers are flagged by documentation linting. Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: bb341c89-175b-4c24-b5e7-f4a803e33beb
📒 Files selected for processing (6)
latency-breakdown.mdoptimizer-hints.mdpd-control.mdsql-plan-management.mdsystem-variables.mdtikv-configuration-file.md
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review.
…23580 - patrol-region-worker-count: reworded to clearly state the setting controls the NUMBER of operators run concurrently by the checker, matching EN's "controls the number of concurrent operators created by the checker" (the previous wording stacked 同時実行数 directly onto オペレーター, which read ambiguously). - max-store-down-time: changed "復元できないと判断する" (decides it cannot be restored) to "ダウンとみなす" (considers it Down), matching the canonical Down-state terminology already used consistently in tidb-scheduling.md's own description of this exact transition (Disconnect -> after max-store-down-time -> Down). Declined 2 other findings from the same review: - An info-level comment noting the repo's established three-space list-marker convention needs no change - agreed, no action needed. - A nested code-block indentation (2-space vs 4-space) nitpick in pd-control.md - EN itself has the identical indentation at this exact position, so this is a pre-existing EN-side formatting choice this PR didn't touch, not a JA-only defect. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ロックタイム読み取り操作 (katakana+kanji hybrid coinage) was accurate
but unnatural/hard to parse at a glance. Changed to ロック取得時の
読み取り操作 ("read operation at the time of lock acquisition"),
which reads as ordinary Japanese technical prose instead of an ad-hoc
term, per user feedback while reading the rendered translation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Also fixes an ambiguous shared-suffix construction found while reviewing the previous fix. "Lock Time PointGet" / "Lock Time Batch PointGet" (heading text, body references, and the cross-link between the two sections) renamed to "ロック取得時のPointGet" / "ロック取得時のBatch PointGet". PointGet and Batch PointGet are genuine TiDB executor/operator names shown in EXPLAIN output, so they stay in English; "Lock Time" is a plain descriptive modifier (not part of the identifier), so it reads more naturally translated, consistent with the prior fix to the generic phrase "lock-time read operations" -> ロック取得時の読み取り操作. Scoped entirely to this one file - the term has no cross-file references or links, so the anchors (#lock-time-point-get, #lock-time-batch-point-get) are left unchanged and still resolve. Also fixes: "`execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は" read ambiguously, as if 期間 (duration) applied only to the second term. Repeated 期間 after both code spans (2 occurrences, one per Lock Time [Batch] PointGet section) so both durations are unambiguously named. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"第 1 次元の優先度均等化により重点を置いています" left it unclear
whether により was the causal conjunction ("due to") or part of "に、
より" (comparative "more"), reads as a garden path. Changed to
"第 1 次元の均等化をより重視しています", matching EN's "pays more
attention to the priority equalization of the first dimension"
unambiguously.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Preemptive fix to avoid a conflict with the separate number+counter spacing sweep (PR pingcap#23578) touching the same lines. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
EN itself mixes "standardized" and "normalized" for the same concept in this file (e.g. line 203 "standardized SQL statement" vs line 398 "normalized SQL statement" for sql_digest), but this file's own JA translation already uses 正規化 16 times for the same concept (lines 103, 205, 390, etc.) and only these 4 sites (2 in one sentence, plus the 2 "Notes" bullets near the end) used the outlier 標準化. Unified to 正規化 to match this file's own dominant, more technically precise convention (TiDB's "SQL normalization" is a specific documented process, not generic standardization). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"作成構文を除き、〜同じ削除構文とステータス変更構文を共有します" was a literal calque of "Apart from X, share the same Y" that read ambiguously in Japanese. Restructured into an explicit contrast (creation syntax differs, deletion/status-change syntax is the same) per user feedback. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"generates a group of hints to fix an execution plan" was translated
as 修正する ("to correct/amend"), a false friend for "fix" in the
"fix in place / pin" sense. Combined with the following "実行計画は
変更されません" (does not change), this read ambiguously - as if the
binding corrects the plan once and then leaves it at that corrected
state, rather than pinning the plan so future executions of the same
query stay consistent. Changed to 固定する (to fix/pin in place) and
reworded the following clause to 変わらなくなります (becomes
unchanging going forward) to make the cause-and-effect unambiguous.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file distinguishes the EN verb "bind" (バインドする/される) from
the EN noun "binding" (バインディング), but this line used the verb
stem バインド as a noun 4 times where EN uses the noun "binding" 4
times ("creating a new binding deletes all previous bindings ...").
Fixed on this already-touched line; other any similar noun-usage
outliers elsewhere in the file are out of scope for this PR.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Follow-up to 6cbefaa. Full-file scan for standalone バインド (noun) not part of バインディング, cross-checked against EN word choice at each site. 9 more sites fixed where EN uses the noun "binding" (binding creation, remove/delete a binding, retain the binding, the binding fails, applied to the created binding) but JA had the verb stem used as a noun instead - including one heading (#### SQL文に従ってバインドを削除する -> バインディングを削除する) that was inconsistent with its own parent heading (### バインディングを削除する) two lines above it. Left untouched: all verb-form uses (バインドします/バインドする/ バインドされた/バインド可能, matching EN's verb "bind"/adjective "bound"), and バインド値 (bind values), which EN itself calls "bind values" as a distinct fixed term, not "binding values". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"バインディングは失敗します" (the binding fails) read ambiguously, as if an existing binding fails at runtime, when the actual meaning (in context of the CREATE BINDING workflow this paragraph describes) is that the binding creation attempt fails. Added の作成 for clarity, per user feedback. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"...使用されることが多い。" ended in plain/da-style, inconsistent with every surrounding bullet in this variable's description (and the file overall), which use です/ます polite style. Changed to "...多いです。". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Follow-up to the sql-plan-management.md sweep (28cefe3). Checked every other file mentioning バインディング/バインド corpus-wide for the same defect class (verb stem バインド used as a noun where EN says "a binding"/"bindings"). Found and fixed 4 more sites in sql-statements/sql-statement-drop-binding.md, matching EN's "You can remove a binding..." / "remove a binding according to...". Checked and confirmed clean or unrelated (different "binding" concept, e.g. binding a USER to a resource group): sql-statement-create-binding.md, sql-statement-show-bindings.md, glossary.md, statement-summary-tables.md, identify-slow-queries.md, tidb-resource-control-ru-groups.md and other resource-group docs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
pd-control.md (2)
1115-1115: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winUse the same scheduling expression for
write-peer-priorities.Line 1115 uses 「ホットリージョンのスケジュールにおいて」, while the two preceding entries use 「ホットリージョンをスケジューリングする際に」. Use the same construction for all three priority settings.
Committable replacement
- `write-peer-priorities`は書き込みピアタイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`byte`と`key`です。As per path instructions: “For every actionable issue, provide a GitHub committable suggestion block containing the exact replacement text whenever the fix can be safely and completely applied to contiguous lines in the diff.”
Source: Path instructions
219-219: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueUse consistent scheduling terminology for
write-peer-priorities.- `write-peer-priorities`は書き込みピアタイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`byte`と`key`です。Source: Path instructions
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: c4825a91-6fb3-4fd8-9915-11caf446635a
📒 Files selected for processing (4)
latency-breakdown.mdpd-control.mdsql-plan-management.mdsystem-variables.md
Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review.
[LGTM Timeline notifier]Timeline:
|
What is changed, added or deleted? (Required)
This PR fixes genuine translation defects found in a dedicated 1:1 review (against the English source) of 7 large top-level files that had never previously gotten a dedicated defect-review round:
system-variables.md,tikv-configuration-file.md,pd-control.md,optimizer-hints.md,sql-tuning-best-practice.md,sql-plan-management.md,latency-breakdown.md.sql-tuning-best-practice.mdhad zero genuine defects. The other 6 files needed fixes:STRAIGHT_JOIN(),RESOURCE_GROUP(resource_group_name),SET_VAR(VAR_NAME=VAR_VALUE)), inconsistent with every sibling heading in the file; plus one droppedにparticle.>where EN uses a literal>(or\>in one MDX-escaped case), missed by the earlier corpus-wide entity sweep since this file wasn't included in it.はparticles (a code-span subject followed by a bare comma instead ofはbefore the verb, breaking 8 config-option descriptions), plus one mistranslation from a garden-path reading of an awkward EN sentence ("factors in" parsed as a noun instead of a verb).はparticle, an ungrammaticalずつusage, a missing colon before a trailing code span, a missing "/" betweenPREPAREandEXECUTE(2 occurrences), and 3 more>entity-vs-literal mismatches on one line.All changes verified against the English source (
release-8.5branch) line by line; line counts preserved in every file.Which TiDB version(s) do your changes apply to? (Required)
What is the related PR or file link(s)?
AI agent involvement
Do your changes match any of the following descriptions?
Summary by CodeRabbit