7言語対応：ローカライゼーションが信頼性機能である理由

Tactic Remoteが7言語の完全サポートを開始しました：英語、簡体字中国語、日本語、韓国語、スペイン語、ドイツ語、フランス語です。これは「文字列を翻訳APIに通しました」というお知らせではありません。ネットワーク構成、ターミナル出力、システムレベルの操作を扱う開発者ツールのローカライゼーションには、一般的なコンシューマーアプリの翻訳とは異なる基準が求められます。

この記事では、技術的アプローチ、ローカライゼーションを信頼性エンジニアリングとして扱うことを教えてくれたバグ、そして国際的な採用状況について紹介します。

7つの言語

言語の選定はプライベートベータ期間中のユーザーデータとリクエスト量に基づいています：

ユーザー需要があり、かつ技術的な正確性を検証できるネイティブスピーカーの開発者にアクセスできる言語を優先しました。開発者ツールのローカライゼーションにはドメインの専門知識が必要です。「session」や「tunnel」や「hook」を日本語に翻訳するには、辞書的な定義だけでなく、その用語の技術的な意味を理解する必要があります。

文字列翻訳を超えて

iOSローカライゼーションの標準的なアプローチは単純です：ユーザー向けの文字列を.stringsまたは.xcstringsファイルに抽出し、翻訳を提供し、システムに表示を任せます。私たちもこれを行っていますが、興味深いエンジニアリングは文字列置換の下のレイヤーにあります。

ロケールに応じた入力処理

ローカライゼーションに対する私たちの哲学を変えたバグ：ドイツ語ロケールのユーザーがセットアップ時にIPアドレスを入力できませんでした。

ドイツ語ロケールのiOSキーボードは、デフォルトでカンマを小数点区切りとして使用します。ドイツ語ロケールのユーザーが数字キーボードの「.」キー領域をタップすると、カンマが入力されます。192.168.1.100のようなIPv4アドレスが192,168,1,100として入力され、バリデーションが不正な形式として拒否していました。

これは翻訳のバグではありません。ロケールの動作バグです。UI文字列は正しく翻訳されていましたが、キーボードレイアウトの前提により入力メカニズムが壊れていました。IPアドレス入力フィールドでカンマからピリオドへの正規化を行い、ネットワークアドレス入力に対して常にピリオドキーを表示するカスタムキーボード構成を提示することで修正しました。

修正前、このバグ1つでドイツ語ロケールのユーザーのセットアップ失敗の推定23%を占めていました。デプロイ後、ドイツ語ロケールの初回実行完了率は1リリースサイクル内に英語のベースラインと同等になりました。

複数形と文法的一致

カウント付きの文字列補間は、ローカライゼーションの典型的な落とし穴です。英語はシンプルです：「1 session」対「2 sessions」。他の言語にはより複雑な複数形ルールがあります：

• 日本語と韓国語には文法的な複数形がなく、数量に関係なく同じ形式が使用されます。
• フランス語は2以上でほとんどの名詞を複数形にしますが、一部の表現は異なる振る舞いをします。
• ドイツ語の複合語は文法格と複数性に基づいて形式が変わることがあります。

私たちはiOSのstringsdict複数形ルールシステムを使用しています。これはCLDR複数形カテゴリ（zero、one、two、few、many、other）をサポートしています。カウントを含むすべてのユーザー向け文字列は、単純な文字列結合ではなく、複数形対応のフォーマットを通して処理されます。

右から左への対応準備

現在の7言語にRTLレイアウトを必要とする言語はありませんが、UIアーキテクチャはそれを考慮しています。すべてのレイアウト制約はleft/rightではなくleading/trailingアンカーを使用しています。テキストの配置は.naturalに設定されています。これにより、アラビア語やヘブライ語のサポートを追加する際（どちらも活発な開発者コミュニティを持つ言語です）、レイアウトの作業は最小限で済みます。

MDXコンテンツのローカライゼーション

Tactic RemoteのウェブサイトとドキュメントはMDXで構築されています。ドキュメントコンテンツのローカライゼーションには、アプリの文字列ローカライゼーションとは異なる戦略が必要でした。

各MDXドキュメントは、ファイル名のサフィックス規則を使用してロケール固有のバリアントを持つことができます：product-update.mdx（英語デフォルト）、product-update.zh-CN.mdx（中国語）、product-update.ja.mdx（日本語）など。コンテンツルーターがユーザーの優先言語を検出し、適切なバリアントを提供します。ローカライズ版が存在しない場合は英語にフォールバックします。

このアプローチには意図的なトレードオフがあります：すべてのドキュメントページをすべての言語に翻訳するわけではありません。技術的なセットアップガイドやAPIリファレンスは英語のまま残します。コードサンプル、コマンドライン指示、構成値が含まれており、言語に依存しないためです。ローカライゼーションの労力は、言語の壁が実際に理解を妨げるコンテンツに集中させています：製品のお知らせ、概念の概要、オンボーディングフロー。

現在、MDXコンテンツの34%が少なくとも1つの非英語バリアントを持っています。ページのトラフィックとサポートチケットの相関に基づいて優先順位を付けています。特定の言語グループからのサポート質問が不釣り合いに多いページは、次にローカライズされます。

信頼性としての議論

ローカライゼーションを信頼性機能として扱うのには具体的な理由があります：ロケール関連の入力バグによりセットアップを完了できない開発者は、ネットワークエラーにより接続できない開発者と同じ状態にあります。製品はその人にとって壊れています。根本原因が「英語のキーボードレイアウトを前提とした」のか「TCPのバグがある」のかは、ユーザー体験を変えません。

この枠組みは、エンジニアリングプロセスに実践的な影響を与えます：

ロケール固有のテストマトリクス。 CIは6つの非英語ロケール構成でクリティカルパステスト（セットアップフロー、接続確立、承認フロー）を実行します。ドイツ語ロケールのIP入力におけるリグレッションはマージ前に検出されます。

ローカライゼーションバグはコア機能をブロックする場合、重大度1でトリアージされます。 誤訳されたラベルは表面的な問題です。ロケールに依存する入力の失敗は本番インシデントです。

リリース前の文字列フリーズ。 各リリースの72時間前に英語の文字列をフリーズし、翻訳者に安定したターゲットを提供します。翻訳はチーム内のネイティブスピーカーの開発者により検証されます。言語学者だけではありません。

国際的な採用状況

多言語サポートのリリース以降、ユーザーベースに測定可能な変化が見られます：

• 英語以外のロケールユーザー が6週間で週間アクティブユーザーの18%から41%に増加しました。
• 簡体字中国語ユーザー は現在2番目に大きな言語グループで、週間アクティブの15%を占めています。
• 日本語ユーザー はすべての言語グループの中で最も平均セッション時間が長く、全体の47分に対して52分です。
• セットアップ完了率 はすべてのロケールで英語のベースラインとの差が2パーセントポイント以内になりました。ローカライゼーション作業前は、一部のロケールで英語より15-20%低い完了率でした。

セットアップ完了率の収束は、私たちが最も重視する指標です。ローカライゼーションが単に翻訳されたラベルを追加するのではなく、信頼性のギャップを埋めていることを検証するものです。

今後の予定

同じ基準に基づいて言語サポートを拡大しています：ユーザー需要とネイティブスピーカーの技術レビュアーへのアクセス。

• ユーザー需要とネイティブスピーカーの技術レビュアーの可用性に基づいて、追加言語を評価中です。
• 翻訳のコミュニティ貢献ワークフローを構築しており、マージ前に技術的正確性を確保するレビュープロセスを設けています。

言語検出とフォールバックの仕組みの詳細については、ローカライゼーションアーキテクチャを参照してください。未対応言語の翻訳に貢献したい場合は、サポートページからお問い合わせください。