国際化コンサルテーション：問題を修正し、次の計画を立てる
i18nが難しいことはすでにご存知でしょう。私はその症状を見てきました：崩れるRTLのレイアウト、ボタンからはみ出すドイツ語のテキスト、間違った言語のAPIレスポンス、そして開始後数週間で同期が取れなくなる翻訳。私は魔法の解決策を売りません。あなたのチームが直面している特定の混乱を解きほぐし、同じ方法で二度と壊れないシステムを構築するお手伝いをします。
「もっと早く計画すべきだった」
今あなたが支払っているアーキテクチャの代償
英語でリリースしました。うまくいきました。そして「ランディングページだけ」とフランス語を追加しました。そして今、あなたがここにいるのは、次の理由からです。
lang属性のチェックがコードベース全体の47ファイルに散らばっている
プロダクトマネージャーは「コピーをA/Bテストできますか？」と尋ね、エンジニアリングは「書き直しなしでは無理です」と答えます
3つの異なる翻訳ワークフローがありますが、どれも確実に機能していません
実際に壊れたもの：
- コンポーネントに文字列がハードコードされていたため、Next.jsアプリに後からi18nを組み込むのに6か月以上を費やしているチーム
- 開発者がどのファイルを更新すべきか分からないため、翻訳ファイルが同期から外れてしまう
- 誰も翻訳パイプラインを信頼していないため、リリース前に「ローカリゼーション凍結」期間が発生する
- ワークフローが非常に面倒なので、翻訳されたコンテンツを変更することに抵抗があります
私が提供できること：
- i18nの採用を段階的に行えるリファクタリング戦略（「すべてを止めて書き直す」ことは要求しません）
- 開発をブロックせずに翻訳を同期させるためのプロセス設計
- 10言語以上に対応する際に、現在のアプローチがどこで破綻するかを特定するためのアーキテクチャレビュー
i18nは機能ではなく、アーキテクチャそのものです。後から追加しようとするのは、家を建てた後に「地下室が必要だ」と決めるようなものだからです。
その地下室を掘るのを手伝うか、そもそも本当に必要かを一緒に見極めます。
RTLがすべてを台無しにする
あなたのUIはアラビア語、ヘブライ語、ウルドゥー語に対応していません。
dir="rtl"を切り替えた結果、レイアウトが崩壊するのを目の当たりにしました：
私が見てきたこと：
- 200以上のコンポーネントを持つデザインシステムで、RTLを適切に扱えるのはわずか12個だけ
- 論理プロパティの代わりにfloat: leftを使用するチームが、新機能ごとにRTLのバグを発生させている
- ポップオーバーやモーダルでは、コンポーネント固有のRTLオーバーライドが必要となる
- 「RTLサポート」を謳いながらも、レイアウトの方向を反転させるだけで配置ロジックを破綻させてしまうフレームワーク
私が提供できること：
- CSSの論理的プロパティの移行（margin-leftの代わりにmargin-inline-startを使用）
- 出荷前にRTLに関する潜在的な問題を特定するためのデザインシステム監査
- RTLを優先したスタイリングのためのフレームワーク固有のガイダンス（Tailwind、shadcn、MUI）
すべてのコンポーネントでRTLのバグを手動で修正するのは持続可能ではありません。常に問題解決に追われるのではなく、体系的にRTLをサポートできるようにします。
「ドイツ語のテキストが私たちのボタンを崩してしまった」
翻訳を考慮せずに構築されたUI
英語は収まる。ドイツ語は収まらない。あなたのデザインはこう想定していました：
ところが、ドイツ語・フィンランド語・タイ語に翻訳してみると、こうなりました：
ボタンが途中で切れる
各行に水平スクロールがあるテーブル
判読不能なブロックに折り返されるテキスト
コンテナの幅が固定されているため、非ラテン文字のテキストが途中で切れてしまう
私が提供できること：
- コンテンツの長さに合わせて伸縮するエラスティックUIパターン
- 文字数計画（ドイツ語は30%拡大し、タイ語はスペースを使用しないことを考慮する）
- CJK、アラビア語、デーヴァナーガリー文字を問題なく扱える文字体系
収まらない1万語分の翻訳費を払う前に、翻訳に耐えるUIづくりをお手伝いします。
i18nが重要である理由について講義を聞く必要はありません。午前2時にRTLのポップオーバーをデバッグし、文字数制限について製品チームと議論し、実際に機能する翻訳パイプラインを設計した経験のある人が必要です。
誰も教えてくれなかった注意点
経験したチームからの苦労話
これらは理論上の話ではありません。実際に本番環境で問題が発生したものです：
複数形の難しさ
英語：「1 item」対「2 items」
ポーランド語：「1 przedmiot」/「2 przedmioty」/「5 przedmiotów」（3種類の複数形）
アラビア語：6種類の複数形
あなたの count === 1 ? 'item' : 'items' というロジックが、もはや機能しなくなったからです。
日付/時刻の混乱
toLocaleDateString()で日付をフォーマットしました。その結果、日本のユーザーのCSVエクスポートで「2025年2月9日」と表示され、Excelが正常に動作しなくなりました。
API言語の不一致
フロントエンドがフランス語をリクエストしています。認証トークンがロケールを含んでいないため、APIは英語を返します。その結果、混合言語のUIとなり、ユーザーはバグだと考えています。
疑似ローカライゼーションテスト
本番環境に移行する前に、[Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] でテストを行いませんでした。その結果、ポーランドのサイトが機能しなくなりました。
目に見えない前提
翻訳が必要なのは文字列だけだと思っていました。しかし、日付、数字、通貨、並べ替え、検索—すべてにロケール固有の動作があることに気づきました
私が提供できること：
- ICU MessageFormat実装（複数形、性別、文脈を処理）
- API i18nパターン（言語ネゴシエーション、フォールバック戦略）
- 翻訳会社が気づく前にこれらの問題を捉えるQAプロセス
ワークフローが難しい部分
毎日リリースする際に8言語をどのように同期させていますか？
技術的な問題は解決しました。しかし、今度はプロセスで行き詰まっています：
開発者が新しい英語の文字列を含むコードをマージします。翻訳は2週間遅れます。ユーザーは半分しか翻訳されていないUIを目にします
どの文字列が削除しても安全か分からない（使用されていますか？翻訳されていますか？エージェンシーと進行中ですか？）
プロダクトチームがコピーを更新したいと考えています。「Submit」を「Send」に変更すると12言語で問題が発生するかどうか、誰も分かりません。
翻訳ファイルが何週間も本番環境と同期されないまま放置される
チームが私に尋ねる質問：
実際に壊れたもの：
- Gitにチェックインされた翻訳ファイルが本番環境の文字列と乖離している
- 誰も何を変更しても安全かわからないため、「スペイン語ファイルに触れないでください」という警告
- 英語で開始された機能が、6ヶ月後に翻訳されました（もし翻訳されていれば）
私が提供できること：
- 翻訳パイプラインの設計（i18nライブラリを使用する時期、TMSを使用する時期、AIを使用する時期）
- ソース文字列と翻訳を同期させるためのGitワークフロー
- 新しい文字列が翻訳用にマークされていない場合にPRをブロックする自動化
技術は解決可能です。ワークフローがボトルネックです。私は英雄的な努力なしで維持できるワークフローをデザインします。
一緒に仕事をしたチーム
グローバル製品、地域の専門知識
LINE（日本、台湾、タイ）
3つの主要な東アジア市場で事業を展開するメッセージングプラットフォーム。CJKの文字処理、プラットフォームエコシステムの統合、日本、台湾、タイでユーザーエクスペリエンスの期待値が異なることに関する課題に取り組みました。
KakaoTalk（韓国）
韓国の主要なメッセージングプラットフォーム。UIにおける言語の丁寧さの期待やプラットフォーム統合のニーズなど、韓国市場特有の製品要件に対応しました。
Change.org（196か国、20以上の優先言語）
コンテンツの速度と品質の両方が重要なグローバルな請願プラットフォーム。多様な市場にわたるユーザー生成の政治的/社会的コンテンツの翻訳ワークフローをナビゲートするのを助けました。
Airbnb（220以上の国、60以上の言語）
複雑なi18n要件を持つグローバルマーケットプレイス。複数の言語における信頼性と安全性に関する課題や、市場全体でのプラットフォームコンセプトの文化的適応について助言しました。
Intercom（30以上の言語、グローバルB2B SaaS）
グローバル企業のお客様に提供している顧客コミュニケーションプラットフォーム。リアルタイムのサポートツールとナレッジベースのローカリゼーションに向けた製品の国際化に取り組みました。
Lilith Games（中国、日本、韓国、米国、EU）
世界中で配信されるタイトルを持つモバイルゲームパブリッシャー。コンテンツのローカリゼーションと地域のプラットフォーム要件に関する市場固有の課題に対処しました。
進出した市場：
東アジア（日本、韓国、中国）：
CJKタイポグラフィ、プラットフォームエコシステム統合、縦書きテキスト対応
東南アジア（タイ、ベトナム、インドネシア）：
マルチスクリプト対応、モバイルファーストなユーザーの期待
MENA（アラビア語圏）：
RTLのレイアウト要件、フォーマルな言葉遣いと口語的な言葉遣いの期待、コンテンツの文化的適応
ヨーロッパ：
24の公用語、複数国での同時製品ローンチ
南北アメリカ：
地域言語のバリエーション（ラテンアメリカスペイン語対スペインスペイン語、ブラジルポルトガル語）、バイリンガル市場
理論上ではなく、実際のユーザーが依存する製品を提供することで、何が機能し、何が失敗するのかを目の当たりにしてきました。
壊れているものを修正しましょう
i18nが重要である理由について講義を聞く必要はありません。午前2時にRTLのポップオーバーをデバッグし、文字数制限について製品チームと議論し、実際に機能する翻訳パイプラインを設計した経験のある人が必要です。
アーキテクチャと戦略のレビュー（1〜2週間）：
次の3言語を追加したときに何が壊れるか、そしてそれを修正するのにいくらかかるかをお伝えします
市場投入サポート（4〜8週間）：
日本/MENA/EUでのサービス立ち上げを計画中で、過去に同様の経験を持つ専門家をお探しですね。
継続的なパートナーシップ：
2言語から20言語にスケールアップする際の組み込みコンサルティング
私は理論を扱いません。トリアージ、ロードマップ、そして出荷を行います。