翻訳の復旧

Glossia は翻訳されたコンテンツを公開する前に検証します。復元はその要件を維持します：再試行は依然存在のソース構造と必要なプレースホルダーを保ち、すべての組み立てられたファイルが設定された検証コマンドをパスします。

Markdown 翻訳

Glossia は翻訳された Markdown ドキュメントを再レンダリングしません。ソースをパースするだけと、そのプロースを検出します：パラグラフ、見出し、リスト項目、テーブルセル、コンポーネントと HTML のユーザー固有属性（title, details, alt, label, description, summary, placeholder, aria-label, caption）、および HTML の <summary> のテキスト。各翻訳はソースが占めた正確なバイト数に書き戻されるため、コード、リンク先、コンポーネント、GitHub アラート、明示的な見出しアンカー（例如 {#install}）、リストマーカー、そして空行はバイト単位で完全に同一のままです。

各段落または見出しは 1 文ごとに変換されます。インラインフォーマットは番号付きタグ <gN>...</gN>（リンクや強調された単語の周りに）および <gN/>（変更してはいけないコンテンツ、例えばインラインコードやコンポーネントなど）に変換されます。モデルはターゲット言語の語順に合わせてタグを移動させることもできますが、すべてのタグは正確に 1 回だけ残す必要があります。各リクエストは、参照のために周囲のソースドキュメントおよび同じファイルからの最新の翻訳を含みます。

タグを落下したり発明したりするユニットは、理由を付して座自行で再度送られます。[最大 3 回]. 有効で帰ってきたユニットは保持されます。スプライシング後、Glossia は結果をパースし、その構造をソースと比較します。自動的に見出し、リスト、または強調に単純化される翻訳は、そのプロースをエスケープします。これはより多くのモデル呼び出しを不要にします。

カタログ翻訳

Gettext カタログは翻訳前にストリングにパースされます。リクエストは最大 8 つのストリングを持ち、8,000 バイトのバッチャリングターゲットを持ちます。1 つのより大きなストリングはそのままにされます。モデルは同じ数のストリングを同じ順序で配列を返します。Glossia は差し込み変数をチェックし、空の翻訳を検出拒否します。

ヘッダーはターゲットローカルの複数ルールを使用してコードで構築されます。ソースメッセージ識別子、コメント、およびカタログ構造はパースされたソースから来ます。もしバッチが誤ったコンテンツを返す場合、Glossia はそれを一度再試行してから、より小さなバッチに分割します。成功した隣接するバッチは再度翻訳される必要がありません。

プロバイダーのスロットリング

Glossia は同じクレデンシャルとモデルを使用する翻訳リクエストを調整します。レート制限応答は共有のクールダウンを延長し、新しいリクエストの間隔を増やします。成功したトラフィックはスロートリングなしで 1 分後にその区間を徐々に減少させます。すでに実行中のリクエストは処理できる состоялся。

プロバイダーの再試行ヒントは最小遅延です。繰り返された失敗も含めて、バックオフを延長します。最大 30 秒の基準遅延プラスジャッタ。より長いプロバイダーヒントは優先権があり、5 分のキャップがあります。Together のx-ratelimit-reset ヘッダーはretry-after と一緒に認識されます。

8 つの不成功のリクエスト試みの後、リポジトリ実行は新しいファイルの開始を停止します。遅延された継続は翻訳ブランチを継承し、未完了の作業を再開始します。以前の試みはセッション履歴で可視化され、継続を介してリンクされます。遅延は 1 分から 5 分まで増加し、最大で 6 回の自動継続があります。新しいアクティブなセッションが優先され、キャンセルされたセッションは決して復活しません。検証失敗のみはプロバイダーの復元スケジュールしません。

エンジンリリース後の復元

エディション: Enterprise。 このセクションの Kubernetes ロールアウトの確認とエンジンリリース後の復元には、分離された翻訳ランナーが必要です。このページの他のセクションで説明する Markdown、カタログ、プロバイダーの復元と永続的な進捗は Community でも利用できます。

セッションには 2 つの独立したバージョンがあります：翻訳されるリポジトリコミットと、実行する翻訳エンジンイメージ。Kubernetes では、各ジョブはそれがスケジューリングしたウェブレプリカの正確なイメージダイジェストを固定します。ジョブはウェブロールアウトに耐え、翻訳のHalfway でコードを切り替えられません。ロールアウトの直前にスケジュールされたジョブは、ウェブアプリケーションが更新されてからも以前のエンジンで完結できるため。セッション詳細はエンジンダイジェストを表示します。古いセッションはこの系譜 プロヴァナンスなしに「記録されていない」を表示します。

Glossia は 5 分ごとに、その Deployment が完全にロールアウトされたかチェックします。その健全なリリースからのみワーカーがエンジン復元をスケジュールできます。もしプロジェクトの最新セッションがそのロールアウトが完了する前にキューイングされて、古い記録されたエンジンダイジェストで実行され、その後 6 時間の内に失敗した場合、Glossia は現在のリリースで継続を作成できます。キュー時間を使用することは、ロールアウト後にのみ起動し、容量を待っているジョブにも当てはまります。異なるイメージダイジェストのみは、関連する Deployment 後の普通の失敗の再试行的トリガしません。完了したファイルと開いている翻訳プルリクエストは引き継がれ、未完了の作業のみが再度翻訳されます。キューされたリリース継続は、ロールアウトが進行中に最大 15 分まで待ちます。Kubernetes API や権限失敗は、継続的ロールアウトと誤解されるのではなく、明示的なエラーで起動を停止します。

復元は意図的に狭い範囲です：セッションは記録されたアイテム検証失敗で終了し、最後の試みの中のすべての失敗したアイテムは、Markdown 構造、保持されたコンテンツ、あるいは Markdown ユニット失敗を報告していなければなりません。中断または部分的にキャンセルされた試みは合格しません。プロバイダーのエラー、消耗したクレジット、拒否されたクレデンシャル、公開失敗、ソースリードエラー、外部検証コマンド失敗、および不明な原因は、Deployment によって再試行されません。成功した、アクティブな、キャンセルされた、代替された、およびバージョン-less セッションもそのままにされます。より新しいセッションは常に勝ち、ユーザーがキャンセルしたとしても。

セッションは別のエンジンリリース上でテキスト継続を得るかの max 1 つを持ち、系譜の中で最大 3 つのリリース継続があります。新しいエンジンが依然として失敗する場合、その同じイメージ上で再試行されません。ロールバックを含む。系譜は以前に試されたエンジンダイジェストを保持し、ランチャーはキューされたジョブを作成する前にそれらをチェックし、ありす。既存のプロバイダー復元制限はリリース継続間の生け残りされます。変更可能なイメージタグとリリース識別子が構成されていない Deployment は、自動エンジン復元を有効にしません。

永続的な進捗

完了したファイルとロックファイルはバッチで翻訳ブランチに公開されます: 25 ファイルごと 1 コミット、または 15 分ごと、そして実行終了時に最終コミット。各プッシュはリポジトリのプルリクエストチェックを実行するため、バッチ分割は大きな実行で 1 ファイルあたりのチェック実行を開始しないように維持します。プロジェクトには 1 つのみの翻訳プルリクエストが存在します: デフォルトブランチへの新しいコミットは既存のオープンなものを続き、以来的変更のみ翻訳します。そのプルリクエストが統合または閉じると、次の実行は新しいものから開始します。未完ファイルから、ローカル検証されたセグメントと復元バッチはまた 7 日間データベースに保存されます。これらのチェックポイントはワーカープロセスの停止を生き残ります。それらはアカウント、プロジェクト、ドキュメント入力、有効なクレデンシャルとモデル、コンテキスト、およびセグメントまたは修復試行に範囲化されます。

再開実行は入力がまだ一致するのみでセグメントを再利用できます。常に最終組み立_document_ドキュメントを再度検証します。拒否されたモデル応答はチェックポイントではありません。ドキュメント水準の検証失敗は個別の修復試行を開始します。なぜなら検証器は単一の責任あるセグメントを同定できない場合があるためです。

期限切れのチェックポイントと非アクティブなプロバイダーペース記録は、スケジュールされたセッション復元ワーカーで削除されます。それらは運用記録です; ユーザーはそれらをリポジトリに追加する必要も、L10N.md でそれらを構成する必要もなくともありません。