翻訳の罠：多言語サイト構築で学んだ「尊重」について
ポートフォリオに5つの言語を追加することは技術的な挑戦だと思っていた。それは共感のレッスンだった。
ブラジルで育った私は、字幕付きのアメリカのテレビ番組を見て英語を学んだ。不自然な翻訳を覚えている。「Cool」は「legal」になった。スラングは教科書的なポルトガル語に平坦化された。言葉は正しかった。感覚が間違っていた。
20年後、私はポートフォリオ用の翻訳スクリプトを作成した。1時間以内に、「Next.js dashboard」を「painel do Next.js」に変換した。
身震いした。ブラジルの開発者は誰も「painel」とは言わない。私たちは単にdashboardと言う。
私は字幕翻訳者たちと同じことをしていた。意味を適応させる代わりに、言葉を変換していた。
なぜこれが重要なのか
調査によると、インターネットユーザーの75%は、英語を理解していても母国語のコンテンツを好む。理解の問題ではない。信頼の問題だ。「これは私のような人のために作られた」という感覚。
ポートフォリオにとって、その感覚は重要だ。東京の採用担当者が私のサイトを訪れたとき、頭の中で翻訳するのではなく、私の仕事を評価してほしい。パリの誰かが私のプロジェクトについて読むとき、言語ではなくアイデアについて考えてほしい。
英語だけのポートフォリオはメッセージを送る：「これは英語話者が最優先、他の人は二の次」。私はそれを逆転させたかった。
ローカリゼーションコミュニティが教えてくれたこと
あの「dashboard」のミスが私をローカリゼーションの沼に落とした。i18nエンジニアのブログ記事を読み、GitHubのディスカッションを掘り下げ、大手テック企業がどのように翻訳を扱っているかを研究した。
パターンはすべての情報源で一貫していた。
技術系の聴衆は国境を越えた共通の語彙を持っている。ブラジルの開発者は「data pipeline」と言い、「canalização de dados」とは言わない。日本のエンジニアは「TypeScript」をTypeScriptのまま使う。フランスのマーケターは辞書の同等語ではなく「growth marketing」を使う。
これらの用語は英語で学ばれた。英語で議論される。翻訳すると明確さではなく混乱を生む。
私のスクリプトは徹底しすぎていた。英語のままにすべきものを翻訳していた。
翻訳対ローカリゼーション
この区別がプロジェクトの核心的な洞察となった。
翻訳は言葉を変換する。ローカリゼーションは体験を適応させる。
翻訳されたサイトは辞書がそう言うから「painel de controle」と言う。ローカライズされたサイトはブラジルの開発者が実際にそう言うから「dashboard」と言う。
翻訳されたサイトはすべての用語を変換する。ローカライズされたサイトはいつ止めるべきかを知っている。日本の開発者は日本語のナビゲーションを必要とするが、技術用語は英語を期待する。そのバランスが、コンテンツを翻訳されたものではなくネイティブに感じさせる。
私はアプローチを書き直した。ナビゲーションラベルは翻訳する。製品名は英語のまま。技術用語は英語のまま。説明的なコンテンツは自然に翻訳する。
構築したルール
十分なミスを修正した後、パターンが浮かび上がった。それを文書化した：
英語のまま維持： Next.js、TypeScript、Claudeなどの製品名。dashboard、data pipeline、growth marketing、e-commerceなどの業界用語。スキルセクションと資格名。
翻訳する： ナビゲーション項目、フォームラベル、ナラティブコンテンツ、セクション見出し。
言語別の適応：
ポルトガル語では、「painel」ではなく「dashboard」を使用、「modelo」ではなく「template」を使用。ブラジルの開発者はこれらの用語を英語で学び、毎日使っている。
スペイン語では、「cuadros de mando」ではなく「dashboard」を使用、「vendedores」ではなく「marketers」を使用、「canalizaciones de datos」ではなく「data pipelines」を使用。
日本語では、製品名は英語のまま（ネクストジェイエスではなくNext.js）。ダッシュボードのような一般的な外来語にはカタカナが使える。
フランス語では、「tableaux de bord」ではなく「dashboard」を使用、「spécialistes du marketing」ではなく「marketers」を使用。
これらのルールは今、プロジェクトのドキュメントに記載されている。コンテンツを翻訳するたびに、これらをチェックする。
腑に落ちた瞬間
初めて日本語でサイトを読み込んだとき、何かが変わった。
私は日本語を話せない。数文字を認識する以上のことは読めない。しかし、そこにあった：私のポートフォリオ、私のプロジェクト、私が知らない言語で表現されていた。
ナビゲーションには「プロジェクト」と書かれていた。本文は日本語で流れていた。しかし「Next.js」は「Next.js」のままだった。「TypeScript」は「TypeScript」のままだった。バランスは正しく感じられた。
各聴衆のために書かれたコンテンツ、彼らに向けて翻訳されたのではなく。その区別が私が学んだすべてを捉えている。
これをしないコスト
私が見るほとんどのポートフォリオは英語だけだ。それでいい。英語はテックの共通語だ。
しかし、誰かがあなたのサイトに来て精神的な翻訳作業をしなければならないとき、あなたは摩擦を追加した。彼らはより早く離脱するかもしれない。理解が減るかもしれない。信頼が減るかもしれない。その認知負荷は見えないが現実だ。
多言語サイトは言う：「あなたのことを考えた。あなたのために作った。あなたの文脈は重要だ。」
すべてのポートフォリオが同じフレームワークで動き、似たようなプロジェクトを見せる分野では、その配慮が際立つ。
技術的な部分、簡潔に
システムはルーティングにnext-intlを使用し、初期翻訳にDeepLのAPIを使用する。MDXファイルを処理し、フロントマターを保持し、ローカリゼーションルールを適用するスクリプトを書いた。パイプライン全体は30秒以内で実行される。
しかし自動翻訳は最初のステップに過ぎない。DeepLが初期バージョンを生成した後、Claudeに各翻訳をローカリゼーションのベストプラクティスに照らしてレビューしてもらう。Claudeは英語のままにすべき用語を特定し、不自然な表現を修正し、技術用語が各言語で開発者が実際に使うものと一致するようにする。
そのスピードと品質の組み合わせが重要だ。ローカリゼーションに何時間もの手作業がかかったら、やめていただろう。
技術的な詳細はプロジェクトページを参照。この投稿は旅についてだ。
学んだこと
私はリーチについて考えて始めた。より多くの言語、より多くの訪問者、より良いSEO。それらは真実だが、ポイントではない。
本当のレッスンは共感だった。グローバルな聴衆のために構築することで、私が共有しない文脈を持つ人々について考えざるを得なくなった。
ポルトガル語については優位性があった。ネイティブスピーカーだ。不自然さをすぐに見つけられる。日本語とフランス語については、ローカリゼーションコミュニティが文書化したものに頼らなければならなかった。ブログ記事やスタイルガイドが、技術系の聴衆が実際にどのようにコミュニケーションするかについて言っていること。
その外部知識への依存は謙虚にさせる。自分のデフォルトが普遍的だと思い込んではいけない。人々がいる場所で会わなければならない。
常設の招待
このサイトの翻訳は完璧ではない。自動翻訳は出発点だ。ネイティブスピーカーはアルゴリズムが見逃すニュアンスをキャッチする。
ポルトガル語、スペイン語、日本語、フランス語で何かおかしいと感じたら、お問い合わせフォームから教えてほしい。感謝する。
ローカリゼーションは決して終わらない。構築者と聴衆の間の継続的な会話だ。グローバルな聴衆のために構築することは、あなたよりも自分の文脈をよく知っている人々からのフィードバックにオープンであり続けることを意味する。