Skip to content

失敗 (ドキュメント翻訳)

失敗タブは、ドキュメント翻訳専用です。これは、セグメントがロケールに対して正常に翻訳できなかった場合にSQLiteに書き込まれた失敗レコードを読み取ります。たとえば、空または無効なモデル出力、翻訳後の検証エラー (AST mismatch、プレースホルダーの漏洩、および同様の品質チェック)、または進行を妨げた致命的な状態などです。

これにより、どのソースセグメントが、どのロケールとモデルで、どのようなエラーテキストが記録されたかという疑問に答えることができます。

使用するタイミング

  • translate-docsまたはsyncがエラー、部分的なロケール、または混乱するログで終了した後、ターミナル出力だけをスクロールするのではなく、失敗をソートしてフィルタリングします。
  • 再作業の優先順位付けをしたい場合: # 失敗でソートすると、再試行で繰り返し失敗したセグメントが最初に表示されます。これらは、ソースMarkdownで簡素化または再フォーマットする強力な候補です。
  • 正確なセグメント (ファイルパス、行ヒント、ソースハッシュ、完全なソーステキスト) が必要な場合、リポジトリ内の正しい段落を編集します。

ソース編集が重要な理由

密なインラインマークアップ (`code`と混在する太字、ネストされた強調、多くのスパンを持つ長い文) は、モデルが構造チェックに合格する翻訳を返すことを困難にします。複数の記録された失敗を持つセグメントは、未変更のテキストで翻訳を再実行するよりも、ソースを書き換えたり分割したり (または例をフェンスで囲まれたコードブロックに移動したり) することで改善されることがよくあります。これは、複雑なMarkdownと失敗した品質チェック と一致しています。

タブの使用方法

  1. ダッシュボードで失敗を開きます。
  2. 概要ストリップを読みます。失敗したセグメントと、12、または3+ の失敗レコードを持つセグメントのカウントが表示されます。
  3. 部分的なファイル名ロケールモデル品質エラー (値はキャッシュから取得されます)、致命的なエラーのみ、およびオプションのソースハッシュソーステキスト、またはエラーメッセージサブストリングでフィルタリングし、適用をクリックします。
  4. ソート: # 失敗 (デフォルト) またはソート: ファイルパス + 行番号を選択します。
  5. テーブルの上部または下部にあるページネーションを使用します。行をクリックして完全なソーステキストを展開します。モデル列には、失敗モデルと、利用可能な場合は、後の成功したキャッシュエントリからのモデルが表示されます。
  6. 🔗リンクコントロールは、ai-i18n-tools dashboardが実行されているターミナルにファイル/行ヒントをログに記録します。
  7. プロジェクトのソースファイルを修正し、translate-docsまたはsyncを再度実行します。成功した実行後にリストが古く見える場合は、ai-i18n-tools sync --force-updateを実行してダッシュボードを再読み込みします。

UIと並行してファイルベースのデバッグを行うには、再試行中にcacheDirの下にFAILED-TRANSLATIONの詳細を書き込むためにtranslate-docs --debug-failedを使用します。キャッシュの動作とtranslate-docsフラグ を参照してください。

失敗とMarkdownの問題

失敗Markdownの問題
記録されるタイミング翻訳中 (ロケールごと)翻訳前 (ソーススキャン)
典型的な原因不適切なモデル出力、検証エラーペアになっていない強調、閉じられていないコードスパン、リンク外の太字
修正ソースを編集して再翻訳ソースMarkdownを修正してから再翻訳

翻訳前の静的チェックについては、Markdownの問題 を参照してください。

MITライセンスの下で公開されています。