ローカライゼーション

Coroidは、自社製品の翻訳に使用するのと同じエンジンで他の製品も翻訳します。対応言語数は13種類に上ります。カタログファイルはリポジトリ内にそのまま保存され、変更が加わるとそれぞれがタスクおよびpull requestとして登録されます。新規、変更、または破損した文字列のみがモデルに送信されます。

ローカライゼーション機能はメインメニュー内に専用の項目があります。ここでは各プロジェクトの対応言語を一覧で確認でき、各プロジェクトごとにワークベンチが用意されています。まだ多言語対応していないプロジェクトは以下から開始します。国際化ウィザード。

すべてのプロジェクトを一ページに表示#

ローカライゼーション画面には、閲覧可能なプロジェクトが表示されます。各行にはプロジェクトのソース言語、対応言語数、文字列数、および全言語での翻訳完了率が示されるバーが含まれています。

各プロジェクト横の小さな地球儀には、言語ごとにビーズが配置されます。言語の翻訳が完了している場合は緑色、文字列が不足または変更されている場合は水色のリング、一部の文字列に破損がある場合は琥珀色で表示されます。

翻訳が未実施のプロジェクトには「まだ国際化されていません」と記載されます。オーナーや管理者はこの行から、またはプロジェクトを国際化ページ上部からウィザードを起動できます。

ワークベンチ#

プロジェクトを開くとワークベンチが表示されます。左側に各セクションが、その隣に開いているセクションが並びます。

提案、貢献者、自動化処理については提案機能を活用して翻訳を維持。

ワークベンチはデフォルトブランチ上のカタログファイルを読み込みます。ファイルが変更されると、次にプロジェクトを開いた際にCoroidが再読み込みします。それまでの間は概要に「読み込み中」と表示されます。Coroidはこの処理のためにリポジトリ内のコードを実行することはありません。カスタムアダプターを使用するカタログは表示されませんが、その文字列は引き続きタスクとしてチェックされます。

概要：言語ごとに1行で表示#

概要画面にはまず4つの合計値が表示されます：文字列数、言語数、翻訳完了率、作業が必要な文字列数です。その下には各言語が3つの段階を経て表示されます：

1. 国際化。その言語のカタログが存在し、文字列が格納されています。
2. ローカライゼーション。現在のソーステキストからすべての文字列が翻訳されます。
3. 検証。どの文字列にも破損がなく、ソースのプレースホルダーが保持され、該当言語に必要な複数形も正しく設定されています。

言語の次のステップは、その行が停止している位置で決まります。緑色の停止地点は完了、水色のリングは作業が必要な停止点、琥珀色は破損した文字列があることを示します。

「ローカライゼーション」の下にあるバーは先頭から読み取られます。人がレビューした文字列は濃い緑色、モデルが生成した文字列は薄緑色、注意が必要な文字列は琥珀色、不足している文字列の部分は空白で表示されます。バーの下のテキストには「不足している文字列が42件」といった Gap が記載され、該当する文字列が開かれます。

米国英語から英国英語など、別の言語からルールに基づいて派生した言語には「派生版で最新状態」と表示されます。これは各ルールがすべての文字列に適用されたことを意味します。

不足している部分を翻訳#

オーナーや管理者には概要画面の上部に1つの操作が表示されます。翻訳作業が必要な文字列数（不足、ソースでの変更、破損）が表示されます。この機能はワークベンチ内で2回に分けて翻訳を実行します：

1. 翻訳メモリ。組織内の別のプロジェクトで既に同じソーステキストで翻訳済みの文字列は、その翻訳内容が再利用されます。人の翻訳がモデルの結果より優先されます。この処理ではモデルへの呼び出しが行われず、費用も発生しません。
2. 翻訳モデル。リポジトリに組み込まれたエンジンが翻訳ゲートウェイを通じて残りの文字列を翻訳し、返信内容をプレースホルダーや複数形と照合してチェックします。

実行中は合計値の下のパネルに作成された文字列数と消費された料金が表示され、各言語のバーには文字列が届くにつれて縞模様のインクが塗りつぶされていきます。翻訳を中止を選択すると実行が終了し、作成された内容は保持されます。

翻訳結果はすぐにリポジトリに反映されるわけではありません。以下で待機状態になります。コミット他の変更内容と共にコミットし、機械翻訳としてマークされます。これにより確認が可能になります。文字列まずは文字列を確認してください。すでに編集済みの文字列や貢献者が提案した文字列は、該当する人物に割り当てられます。

文字列#

文字列この一覧には、各文字列のソーステキストと特定言語での値が表示されます。開くと修正が必要：翻訳が未完了、ソースが変更された、破損している、またはソースと同一の文字列です。別の言語やカタログを選択するか、キーやテキストで検索してください。

文字列を選択すると、すべての言語での表示内容を確認できます。プレースホルダーやマークアップはロックされたチップとして表示され、翻訳時にも正確に保持される必要があります。選択した言語の詳細には、その値を記述した人物、不具合の内容、複数形メッセージの場合はその言語で必要な複数形の種類も記載されます。

編集してコミット#

オーナーや管理者は「Strings」内で翻訳を修正しますStrings文字列を選択し、編集該当言語で編集し、変更内容を保存します。エディターにはソースのプレースホルダーが挿入可能なチップとして表示され、入力中に変更内容をチェックします。プレースホルダー、言語で必要な複数形、用語集に登録された用語、文字数などが対象です。保存時にCoroidがデフォルトブランチと照らし合わせて再度検証を行います。

提案エディター内で、その文字列の翻訳を提案します。他のプロジェクトで既に使用されている翻訳が翻訳メモリにあればそれを利用し、そうでなければTranslatorモデルが生成します。選択してくださいこれを使用これを使ってエディターに挿入しますが、変更内容を保存するまで何も保存されません。

保存された変更内容は文字列の下にあるバーに一時的に表示され、そこで各内容をレビューしたり破棄したりできます。コミットコミットにより、承認済みの貢献者提案や機械翻訳とともにそれらすべてが1つのタスクにまとめられます。このタスクでは指定されたエンジンを使って正確に該当値が適用され、1つのpull requestが開かれます。1回のコミットで処理できる変更数は最大5,000件で、残りの変更は次回の処理を待ちます。このpull requestがマージされるまで、文字列には未コミットまたは適用中。

コミット済みの機械翻訳はエンジンのキャッシュ内で引き続き機械翻訳として保持されるため、それは依然として機械翻訳人がレビューするまで有効です。

編集を利用するには設定ファイルで貢献機能を有効にする必要があります；国際化ウィザードデフォルトでこれらを有効にします。貢献者もまたより適切な表現を提案できます自身のサイト上で利用可能です。

ファイルの交換#

「交換」の下で交換代理店や翻訳ツール、スプレッドシート用の文字列をダウンロードし、その翻訳内容を再度インポートできます。

エクスポート機能により、作業が必要な文字列やすべての文字列を抽出できます。プレースホルダーや複数形メッセージもそのままの形で保持されます。

インポート時には、データが保存される前にすべての行が表示されます。新しい翻訳や変更内容を承認できます。Coroidは、プロジェクトに存在しないキー、元のテキストが変更された後に作成された翻訳、破損したプレースホルダー、および対象言語で必要な複数形が欠けているメッセージを除外します。承認された行は、次に適用される変更となります。コミット、以下で行われた編集と同様に文字列。

JSON、.stringsファイル、Androidファイルには格納されている言語が記載されていません。Coroidはファイル名から言語を特定します。例えばstorefront-de.json、またはユーザーに確認を求めます。

すべての変更をチェック#

この翻訳の品質管理におけるチェックは、タスクQAおよびプルリクエスト時に実行され、変更が影響する文字列のみを対象とします。pull requestがマージされると、ウィザードがデフォルトでこれを有効化します。設定は機能が有効かどうかを表示し、品質管理画面で開きます。概要画面では直近のチェック結果を表示の下にある検証最新の実行結果を開きます。

各問題は、固有のコードを持つ「ファインディング」として記録されます：

チェック設定でどのコードをブロック対象とするかを指定できます。用語集、文字数制限、禁止用語のルールも、設定ファイルで指定されている場合には独自のコードを報告します。

翻訳処理でタスクがブロックされた場合、開発エージェントは毎回同じ方法で修復します。つまり、該当タスク用の翻訳セッションを開始し、変更された文字列に対してエンジンを実行するのです。ターゲットカタログを手動で編集することは決してありません。

Translatorモデル#

翻訳機能はAIのプロファイル内で独自の役割を担っています。TranslatorArchitect、Developer、QA、Reviewerと並んで設定されます。デフォルトでは翻訳モデルであるHy-MT2を使用し、組織のポリシーが許可する場合にはGPT-6 Lunaをフォールバックとして利用します。他の役割と同様に、AIプロファイル内でこのマッピングを変更可能です。

エンジンは文字列をサイズごとにバッチ処理し、各応答がプレースホルダーや複数形ルールに準拠しているかを検証します。不適合な文字列があれば再試行またはエスカレーションを行います。

コスト#

すべてのプランで翻訳機能が利用可能です。翻訳リクエストはCoroidの翻訳ゲートウェイを経由し、エージェント実行と同様に組織へのモデル利用料として課金されます。翻訳タスクも他のタスクと同様にプランのエージェント時間にカウントされます。

デフォルトのTranslatorルートを使用した場合、1,000文字列あたり1言語につき約2セントの翻訳コストがかかります。2,000文字列のカタログを10言語に翻訳する場合、測定結果では約0.33ドルかかりました。

• 変更分のみにコストが発生します。エンジンはソーステキストをキーにしたキャッシュを保持するため、変更されていない文字列は再度送信されることはありません。
• 各タスクおよび各実行には翻訳制限が設けられています。タスクのセッションは既定で1ドルの支出制限に達すると停止します。Translateワークベンチでの実行は5ドルで停止します。プロジェクトでは「設定→アクセスと支出」でより低い制限を設定できます。設定→アクセスと支出。
• 翻訳メモリの利用には費用がかかりません。組織が他で既に翻訳した文字列は、モデル呼び出しなしで再利用されます。
• 閲覧には費用がかかりません。ワークベンチおよび翻訳チェック機能はカタログを読み取るだけで、モデル呼び出しは行いません。

Coroid外での翻訳#

エンジンはコマンドラインツールです。coroid-i18n独自のCI環境で同じ固定バージョンをOpenRouterキーと共に実行可能です。Coroid内ではタスクが常に翻訳ゲートウェイを利用するため、支出や制限は一元的に管理されます。

関連項目#

• プロジェクトの国際化
• 提案機能を活用した翻訳の保守
• 品質ポリシーとゲート
• チェック項目、実行、および発見事項
• AIプロファイル