大規模コードベースのローカライズとLLM:4,500のUIキーに対する開発者のワークフロー

開発者が、約4,500のUIキーを含む500KBのen-US.jsonファイルで構成される大規模なゲームプロジェクトのローカライズプロセスを記録しました。抽出、翻訳、品質向上を処理する多段階のLLMワークフローを使用しました。
初期の抽出と翻訳の試み
まず、Claudeを使用してコードベースをスキャンし、ハードコードされたUI文字列を抽出してi18n標準に移行し、ロケールファイルを作成しました。イタリア語への翻訳では、最初にClaudeとGemini Pro(Gemini CLIとAntigravity経由)を試しました。どちらのクラウドモデルも許容できない品質の翻訳を生成しました。Gemini Proは大きなファイルでエラーが発生し、10の小さなチャンクに分割する必要がありました。
ローカルモデルへの移行とコンテキストの突破口
次に、LM Studio経由でローカルにTranslateGemmaを試し、キーごとに翻訳しました。わずかに改善されたものの、品質はまだ許容できるものではありませんでした。重要な洞察は、UIの単語はしばしば曖昧であり、翻訳には曖昧さの解消と使用コンテキストが必要だということでした。
これを解決するために、Claudeに戻って2つ目のファイルを生成しました。4,500のキーそれぞれについて、Claudeはコードの使用状況を調査してコンテキストを提供しました:文字列が表示される場所、その機能(ボタンラベル、説明、入力ヒント)、ゲームプレイでの効果などです。
最終的な翻訳パイプライン
以下のステップで自動化された翻訳パイプラインを構築しました:
- 生成されたコンテキストと共にキーをバッチ処理。
- 機能的な(文字通りのものではない)翻訳に焦点を当てたプロンプトを使用。
- プレースホルダーとタグの保持を強制。
- LM Studio経由でローカルモデルにリクエストを送信。
TranslateGemmaはコンテキストが豊富なプロンプト形式を処理できなかったため、モデルを切り替えました。M1 Mac Mini(16GB統合メモリ)でテストしました。
モデルのパフォーマンスと結果
モデルのパフォーマンスと結果
Qwen 3 4Bは良好に動作しましたが、Qwen 3 8Bが最適なポイントで、文法ミスが少なく、より良い言い回しを生成しながら、ローカルで実行可能な範囲に収まりました。最終的なパイプラインは4,500以上のキーを複数の言語に翻訳でき、彼らのマシンではロケールごとに約8時間かかります。量子化モデルを使用しているため、バックグラウンドで実行しながら作業を続けることができます。
開発者は、このアプローチがリリースに十分な品質を生み出し、これまで見てきた多くの自動翻訳プロジェクトよりも優れていると感じたと述べています。
📖 詳細はこちら: r/LocalLLaMA
👀 See Also

開発者が6つのClaude AIエージェントを構築し、15のサイドプロジェクトを管理
フルタイムのエンジニアとして働く開発者が、6つの専門化されたClaudeエージェントを作成し、カスタムプラットフォームなしでClaude Code、マークダウンファイル、git worktreeを使用して15のサイドプロジェクトの日常業務を処理している。

OpenClawによるメール自動化:トリアージ、要約、下書き作成
なし

複数のAIエージェントを調整するためのステートマシンアプローチ
ultrathink.artのチームは、複数のAIエージェントを調整するには、従来のメッセージキューではなく、明示的な状態遷移、ハートビートタイムアウト、リトライ制限、タスクチェーンが必要であることを発見しました。彼らは、エージェント間の受け渡し時に品質ゲートを必須化し、低品質な出力を防ぎました。

開発者がClaudeでAIテキストベースゲームを作るプロセス
開発者が、ClaudeのようなAIモデル上でネイティブに動作するテキストベースゲームを作成するワークフローを共有しています。ファイルの調和、ルールの洗練、ゲームをPDFプロンプトとしてパッケージ化する手法を含みます。彼らはStarCraftをテーマにしたテキストRTS「Kreep」をリリースしました。