多言語ポートフォリオ：グローバルな視聴者へのリーチ

なぜ言語が重要なのか

ウェブに対する考え方を変えた数字がある：インターネットユーザーの75％は、母国語で商品を購入することを好む。たとえ英語を理解していても、彼らは母国語のコンテンツをより信頼する。より長く滞在する。より深く関わってくれる。

ポートフォリオにとって、この洞察には重みがある。サンパウロにいる採用担当者が私の作品を読むとき、私のスキルを評価するために翻訳する必要はない。東京にいる潜在的な協力者は、そのサイトが自分のことを考えて作られたと感じるはずだ。言語は理解力だけではない。尊敬、信頼、そして自分の居場所がここにあるという感覚なのだ。

英語だけのポートフォリオは、意図しないメッセージを送ることになる："ここはまず英語を話す人のためのもので、それ以外の人は二の次"。私はそれを覆したかった。ブラジル、スペイン、日本、フランスからの訪問者に私のサイトを訪れてもらい、"ああ、この人はわかっている "と思ってもらいたかった。

翻訳とローカライゼーション：重要な違い

翻訳とローカライゼーションは同じものではありません。

翻訳は言葉をある言語から別の言語に変換する。機械的なものだ。「連絡ください」はスペイン語で「Contáctame」になる。完了。

ローカライゼーションは、体験全体を特定の文化に適応させます。文脈、期待、慣習を考慮します。ローカライズされたサイトは、単に言葉を入れ替えるだけではありません。ネイティブの感覚です。

ブラジルの開発者が "データパイプライン "について読むとき、"canalizações de dados "ではなく、"data pipelines "を見ることを期待する。ブラジルの開発者が "データパイプライン "について読むときは、"data pipelines "ではなく、"canalizações de dados "と読むだろう。それを翻訳するのは気まずく、慇懃無礼にさえ感じるだろう。同様に、"dashboard "は、サンパウロ、東京、パリの開発者が実際にそう呼んでいるので、"dashboard "のままである。

ローカライゼーションとは、いつ翻訳してはいけないかを知ることである。つまり、日本の読者は英語では「Next.js」や「TypeScript」を期待しているが、日本語ではナビゲーションのラベルを期待していることを理解することだ。フランスのマーケターが会話の中で "marketing de croissance "ではなく "growth marketing "を使うことを理解することだ。

この洞察がシステム全体を形作った。私は翻訳ツールを作っていたのではありません。私は、翻訳を戦略的に使用するローカリゼーション・エンジンを構築していたのです。

課題

手作業でのローカライゼーションはスケールしません。ブログの投稿やプロジェクトの更新、UIの変更のたびに翻訳者を雇うのはボトルネックになります。さらに悪いことに、多言語での公開を完全にやめてしまうほどスピードが落ちてしまう。メンテナンスの負担が勝ってしまうのだ。

私には3つの特性を持つシステムが必要だった：

1. スピード。 新しいコンテンツは、数日ではなく数分でローカライズされなければならない。
2. インテリジェンス。 システムは何を翻訳し、何を保存すべきかを知っている必要がある。
3. 回復力。 不完全な翻訳は決してサイトを壊してはならない。

解決策

このアーキテクチャは、ロケールを考慮したルーティングのためのnext-intlと、高品質の自動翻訳のためのDeepLの翻訳APIを組み合わせたものです。カスタム翻訳パイプラインは、ニュアンスを処理します。

訪問者の体験:

誰かが到着すると、システムはブラウザの言語を検出します。もしポルトガル語に設定されていれば、ポルトガル語のコンテンツで/pt-BR/blogが表示されます。日本の訪問者には、日本語のテキストで/ja/projectsが表示されます。URL構造はクリーンで読みやすく、検索エンジンにもフレンドリーです。

特定のページがまだ翻訳されていない場合、訪問者にはエラーではなく英語版が表示されます。このフォールバックは静かに行われます。ページが壊れたり、「近日中に翻訳します」というメッセージが表示されたりすることはありません。コンテンツだけです。

コンテンツのワークフロー:

すべて英語で一度書きます。翻訳スクリプトがコンテンツをDeepLで処理し、ローカリゼーションルールを適用して、ロケール固有のファイルを生成します。パイプライン全体は30秒以内で実行されます。

翻訳スクリプトの仕組み

このスクリプトは、UI文字列（ボタン、ナビゲーション、エラーメッセージ）と長文コンテンツ（ブログ記事、プロジェクトの説明、aboutページ）の両方を処理します。フロントマターの構造を保持し、Markdownフォーマットを維持し、コードブロックはそのまま残します。

プロセス：

1. 英語のソースファイル（MDXまたはJSON）を読み込みます
2. 構造を保持したまま翻訳可能なコンテンツを抽出
3. テキストをターゲット言語で DeepL API に送信
4. ローカリゼーションルールの適用（技術用語、製品名の保持）
5. ロケール固有のファイルを記述します（例：post.pt-BR.mdx）

地域化ルールの実際

このシステムは、何を翻訳し、何を保存するかについて、明確なルールに従っている：

常に翻訳する:

• ナビゲーションとUIラベル
• 記事の内容と説明
• フォームフィールドとエラーメッセージ
• アクションへの呼び出し

常に英語で表記する:

• 製品名: Next.js、TypeScript、DeepL、Cursor
• 会社名: Nike、Meta、Rocket Internet
• 専門用語: API、dashboard、data pipeline、template
• コード例とファイルパス

言語固有の適応:

• ポルトガル語（ブラジル）: "painel"ではなく"dashboard"、"modelo"ではなく"template"
• スペイン語: "vendedores "ではなく "marketers"、"canalizaciones de datos "ではなく "data pipelines"。
• 日本語：商品名は英語、一般的な借用語はカタカナ
• フランス語: "tableaux de bord "ではなく "dashboard"、"Contactez-moi "のような自然なCTA。

これらのルールは、各ロケールの技術に精通した読者にとって自然に感じられる翻訳を生成します。コンテンツは、翻訳されたものではなく、読者のために書かれたもののように読めます。

結果

訪問者向け:

• 初日から5ヶ国語に対応
• ブラウザの設定に基づく自動言語検出
• すべてのページと言語で一貫した体験
• 行き止まり、壊れたページ、または「コンテンツが利用できません」メッセージなし

検索エンジンのために:

• 各言語のユニークでインデックス可能なURL（/en/blog、/ja/blog、/pt-BR/blog）。
• 正確な言語インデックスのための適切な hreflang タグ
• 複数の国にまたがるローカル検索結果での視認性向上

継続的なメンテナンスのために:

• 新しいコンテンツを30秒以内にローカライズ
• 英語の単一ソース
• 言語ごとの手動ファイル管理が不要
• 翻訳中でも安全に公開可能

学んだこと

このシステムを構築したことで、ローカライゼーションは単なる技術的な問題ではなく、製品の決定事項であることを学びました。何を翻訳するか（そして何を翻訳しないか）というすべての選択は、読者に対する理解を反映したものなのです。

最大の洞察は、ユーザーの専門知識を尊重することです。日本の開発者は「TypeScript」を日本語に翻訳する必要はない。彼らが必要としているのは、その言語で自然に感じられるコンテンツなのだ。このバランスをうまくとることが、翻訳されたサイトとネイティブなサイトの違いなのだ。

このポートフォリオは、言語ごとに別々のコードベースを維持するオーバーヘッドなしに、世界中のオーディエンスにリーチできるようになった。さらに重要なのは、彼らの言語と文脈が私にとって重要であることを訪問者に示すことだ。皆のポートフォリオが同じに見えるこの分野では、それが重要なのだ。

翻訳についてのメモ

このサイトの翻訳は、DeepLのAPIを使用して生成された後、上記のローカリゼーション・ガイドラインに基づいてレビューされ、改善されます。自動翻訳は出発点であり、完成品ではありません。

あなたの言語で読みにくいものに気づいたり、改善の提案がある場合は、お問い合わせフォーム を通してフィードバックをお待ちしています。ローカライゼーションは継続的なプロセスであり、ネイティブスピーカーは自動翻訳が見逃すニュアンスをキャッチします。