翻訳レビュー、一度に一つの言語ずつ
translation-checkはすべてのキーが存在し、正しいプレースホルダーを持つことを証明します。このスキルは実際の言葉を読み取ります。
1. 範囲とコンテキスト
- 対象テキスト: 変更によって追加または編集されたキー（ロケールファイルをベースブランチとdiffする）、または要求された場合は名前空間全体またはファイル全体。参照値と各言語の値を並べて取得します。
- 出現場所: コード内での各キーの使用箇所を見つけます（
git grep "<key>"）。ボタン、タイトル、メール、エラー、ツールチップのいずれか？使用可能なスペースはどのくらいか？他のキーと一緒に文の中にあるか、{{count}}、名前、日付を受け取るか？ - プロジェクトルール:
AGENTS.mdと.claude/translations.json。避けるべき単語、翻訳しない製品名やプラン名、フォーマリティ、読者が誰か（顧客、ディーラー、管理者）を確認します。 - 既存の用語集: 同じ用語がその言語のファイル内で既にどのように翻訳されているか。そのロケールフォルダ内で
git grepで用語を検索します。一貫性はあなた自身の好みに勝ります。
2. 各言語を個別にレビュー
各言語について、すべてのテキストを以下について確認します：
- 意味: 参照と同じ内容を伝えていること。何も追加せず、何も省略せず、誤った同源語がないこと。プレースホルダーは正しい文法的役割で使用されていること。
- 自然さ: その言語の製品コピーとして自然に読めること、英語をそのまま直訳したものでないこと。語順、冠詞、大文字化に注意（ドイツ語の名詞は大文字、他の言語では英語のタイトルケースは使用しない）。
- 用語: 同じものはどこでも同じ名前で呼ばれていること（レポート、注文、クレジット、VIN、プラン名）、ステップ1の用語集と一致していること。
- フォーマリティ: 製品全体で一貫した文体であること。例：ドイツ語のSieまたはdu、ウクライナ語のви、フランス語のvous、チェコ語のVy、ポーランド語のPan/Paniまたは中立形。混在させないこと。
- 変数を含む文法: 実際の数に対する複数形が正しいこと（uk、pl、csにおける1、2、5、21、22、25）。前置詞の後の格。プレースホルダーが名詞である場合の性の一致。
- 長さ: ボタン、タブ、バッジは参照とほぼ同じ短さに保つこと。狭い場所で約40%以上長いものはフラグを立てること。
- 地域の慣習: 単位（uk/bgではкм、кВт、к.с.）、小数点のカンマ、日付の順序、通貨の位置、引用符（deでは„…“、frでは« … »、ukでは«…»）。
- プロジェクトルール: 禁止語句、ブランド名の綴り、プラン名。
3. 報告
言語ごとにグループ化し、各指摘に対してキー、現在のテキスト、問題点、提案テキストを示します：
uk — 2件の指摘
- reportPage:upgrade.cta — "Оновити до Complete звіту" — 語順が英語のまま。Completeはプラン名 → "Перейти на звіт Complete"
- ...
de — 指摘なし
- 自信を持って判断できる言語を述べてください。判断できない言語については、推測せずにその旨を述べ、ネイティブチェックを提案してください。
- 修正を求められた場合：ロケールファイルに提案を適用し、再度
i18n:translation-checkを実行し、変更とともにコミットしてください。 - PRレビューでは、意味が間違っている場合や禁止語句が含まれている場合を除き、これらをNitsとして投稿してください。その場合はImportantとします。