ナレッジベース
General Translation を使ったアプリ、ドキュメント、コンテンツのローカライズについて、よくある質問にお答えします。
国際化
コードベースへのi18nの導入：ライブラリ、フレームワーク、コンポーネント。
- TanStack Start に i18n を追加するには？TanStack Start には組み込みの i18n がないため、サーバーリクエストごとにロケールを解決し（通常は URL プレフィックスまたはクッキーから）、レンダリング前にメッセージを読み込むライブラリを追加します。Paraglide JS、react-i18next、Lingui は自分で用意した翻訳をレンダリングするのに対し、General Translation の実験的な gt-tanstack-start は、JSX 内にインラインで記述したテキストから翻訳を生成することもできます。動画
- strings.xml で Android アプリをローカライズするには？デフォルトの文字列はすべて res/values/strings.xml に置き、values-es や values-b+zh+Hant+TW のようなロケール修飾子付きフォルダーに言語ごとの strings.xml を追加して、stringResource または getString でテキストを読み込みます。翻訳は手作業、Play Console、または General Translation の CLI で行えます。CLI は各 values フォルダーを自動で書き出し、対象言語ごとに複数形を再構築します。動画
- Next.js Pages Router アプリに i18n を追加するには？next.config.js に locales と defaultLocale を含む i18n ブロックを追加すると、Next.js は /es や /fr を配信し、ブラウザの言語に基づいて訪問者をリダイレクトし、ロケールを getStaticProps と getServerSideProps に渡します。メッセージのレンダリングはライブラリが担います。General Translation の gt-next なら、JSX にインラインで書いた文言から翻訳の生成まで行えます。動画
- Flask や FastAPI のアプリを翻訳するには？ユーザー向けの文字列をマークし、リクエストごとのロケールを（通常は Accept-Language から）決定して、そのロケールの翻訳を読み込みます。Flask アプリでは通常 Flask-Babel と gettext カタログを使い、FastAPI アプリでは Babel をミドルウェアに組み込みます。General Translation の CLI を使えばこれらのカタログを埋めることができ、実験的な SDK である gt-flask と gt-fastapi を使えば、カタログを使わずにインラインの t() 文字列を翻訳できます。動画
- Vue アプリを翻訳するにはどうすればよいですか？Vue アプリを翻訳するには、各テンプレート文字列をアクティブな言語に応じて参照される形にし、すべての対象言語に翻訳します。General Translation の gt-vue プラグインは <T> コンポーネントでラップされたコンテンツを翻訳し、npx gt translate は対象言語ごとに 1 つのカタログを書き出します。動画
- React アプリを翻訳するには？React アプリを翻訳するには、まずコンポーネントを国際化してユーザーの言語でレンダリングできるようにし、次にすべての文字列をサポート対象の各言語に翻訳します。General Translation の gt-react は <T> コンポーネント内の JSX をインプレースで翻訳し、npx gt translate は言語ごとに 1 つのファイルを書き出します。動画
- React Native アプリを翻訳するにはどうすればよいですか？コンポーネント内のテキストをマークし、言語ごとに翻訳ファイルを生成して Intl ポリフィルを追加し、デバイスの言語に対応するファイルを読み込みます。General Translation の実験的な gt-react-native では、テキストを <T> でラップするだけで、Babel プラグインがポリフィルを追加し、npx gt translate がファイルを書き出します。動画
- Node.js アプリを翻訳するには？各リクエストの言語を（通常は Accept-Language ヘッダーから）検出し、すべての文字列をその言語で返します。General Translation の gt-node では、withGT でリクエストごとにロケールを関連付け、getGT で文字列を翻訳します。翻訳は、デプロイ前に npx gt translate --publish で生成しておきます。動画
- Next.js App Router アプリに i18n を追加するには？まず gt init を実行して、対応する App Router プロジェクトに General Translation を設定します。次にソースコンテンツをマークし、翻訳を生成して、言語の切り替えが機能することを確認します。gt-next はテキストを翻訳の文脈とともに JSX 内に保持し、生成、レビュー、継続的な更新は CLI、ダッシュボード エディター、Locadex が担います。このガイドでは、ローカルファイルを明示的に使うセットアップ方法も紹介します。動画
- JSX の外にある文字列はどのように翻訳しますか？プレースホルダーやモジュールスコープの定数など、JSX の子要素ではない文字列は、それぞれレンダリングされる場所で翻訳関数に渡します。General Translation の useGT フックはこの翻訳関数を返します。また、msg と useMessages を組み合わせれば、コンポーネントの外で定義された定数も翻訳できます。動画
- Cursor や Claude Code でアプリを国際化するには？Cursor または Claude Code で General Translation の Setup for Agents プロンプトを使い、機能と対象言語を選んで、エージェントに実装と検証を任せます。ブラウザでのサインイン、機械可読なドキュメント、MCP ツールにより、セットアップから翻訳、レビューまでがシームレスにつながります。継続的なローカライゼーションは、Locadex を使ってプルリクエスト経由で自動化できます。動画
- 言語切り替え機能のベストプラクティス：UX、SEO、アクセシビリティ各言語は Deutsch や 日本語 のようにその言語自身の名称で表記し、国を表す国旗は使わないでください。各選択肢からは、クロール可能なリンクで同じページの該当言語版へ遷移させ、選択内容はクッキーに保存します。ローカライズされた URL は決して自動リダイレクトしないでください。動画
- 翻訳されていないハードコードされた文字列を見つけるにはどうすればよいですか？CI でリンターを実行し、ユーザー向けの文字列リテラルを検出します。たとえば JSX なら eslint-plugin-i18next の no-literal-string ルール、Android なら Android Lint の HardcodedText チェック、Rails なら erb_lint の HardCodedString リンターが使えます。さらに、疑似ロケールでアプリを一通り操作し、静的チェックでは追跡できないテキストを洗い出します。動画
- 疑似ローカライゼーションとは？疑似ローカライゼーションは、原文をアクセント記号付きで約40%長く水増しし、括弧で囲んだ改変版に置き換えるテストです。これにより、ハードコードされた文字列、切り詰め、フォントの表示崩れ、文の連結といった問題を、翻訳を用意する前に発見できます。Android にはこの用途向けに en-XA と ar-XB の疑似ロケールが用意されています。動画
- 国際化とローカライゼーションの違い（i18n vs. l10n）国際化（i18n）とは、1つのプロダクトで多数のロケールをサポートできるようにするためのコードと設計の作業です。たとえば、Intl を使った日付のフォーマットや、右から左に書くテキストへの対応などがこれにあたります。ローカライゼーション（l10n）は、プロダクトを特定のロケールに合わせて最適化する作業で、翻訳に加えて通貨、日付形式、単位、トーン、法的な細部などを扱います。動画
- ユーザーのブラウザ言語を検出するには？ブラウザが持つ優先順位付きの言語リスト（JavaScript では navigator.languages、サーバー側では q 値で並べ替えた Accept-Language ヘッダー）を読み取り、フォールバックを用意したうえで対応ロケールとマッチングします。なお、Safari や Chrome のシークレットモードでは 1 つの言語しか通知されません。また、IP ジオロケーションでわかるのは所在地であって、言語ではありません。動画
- ウェブサイトを多言語化するにはどうすればよいですか？翻訳をどこで管理するか（プロキシ、CMSプラグイン、サイトビルダー、または自前のコード）を選び、Googleの推奨どおり言語ごとに専用のURLを用意します。ページ全体に加えてタイトルとメタディスクリプションも翻訳し、hreflangで各言語版を関連付けます。また、訪問者を自動でリダイレクトするのではなく、言語切り替え機能を設置しましょう。動画
- String Catalog を使って iOS アプリをローカライズするには？Xcode で言語を追加し、SwiftUI の Text や String(localized:) などのローカライズ可能な API でユーザー向けテキストを記述してからビルドすると、Xcode がそれらの文字列を String Catalog（.xcstrings）に収集します。翻訳は Xcode 上または XLIFF 経由で行えます。リリースに合わせてカタログを更新し、Web サイトや Android アプリと用語を共有したい場合は、General Translation の CLI を使用してください。動画
- i18n の翻訳キーはどのように命名すべきですか？キーは英語の文言ではなく、テキストが表示される場所と意味に基づいて命名します（例: checkout.summary.title）。英語が同じでも、用途が異なるものにはそれぞれ別のキーを割り当ててください。たとえばドイツ語では、ボタンの Open は Öffnen、ステータスの Open は Offen と訳されます。動画
- 多言語アプリのローカライゼーションテスト チェックリスト本番環境のビルドで、サポート対象のすべてのロケールについて次の9項目をテストしてください：エラー状態やメールを含むジャーニー全体、言語の切り替え、複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、翻訳の配信、クロール可能な言語別URL。各項目には明確な合格条件を設けてください。動画
- react-intl の代替：General Translation と react-intl の比較General Translation なら、React チームは ICU メッセージ構文をそのまま使いながら、翻訳の生成、用語の共有、ダッシュボード でのレビューを追加できます。react-intl が提供するのはフォーマット機能と FormatJS のカタログツールですが、General Translation は翻訳そのものも生成します。動画
- i18nは自前で構築すべきか、General Translationを使うべきか自前のi18n（言語ごとの辞書と小さな t() ヘルパー）は、対応言語が1〜2つで文言も少ないうちは十分に機能します。しかしアプリが成長するにつれて、複数形規則、フォールバック、ファイルの同期を自分で作り直すことになり、そのうえ翻訳そのものも用意しなければなりません。General Translationのオープンソースライブラリがレンダリングを担い、General Translationがコードから翻訳を生成・更新します。動画
- i18next の代替：General Translation と i18next の比較テキストを React コンポーネント内にインラインで記述したまま、JSX 構造とプロダクトの文脈を活かして翻訳を生成したい場合は、General Translation を選びましょう。i18next を使い続けながら、General Translation で既存のカタログを翻訳することもできます。i18next はメッセージのレンダリングと複数形の選択を担いますが、翻訳の生成には別のサービスが必要です。動画
- General Translation と vue-i18n：どちらを使うべきかGeneral Translation を使うと、Vue チームはテンプレートに翻訳元の文言を直接記述し、CLI で翻訳を生成できます。gt-vue プラグインは、そのコンテンツをロケール対応の複数形や数値フォーマットでレンダリングします。キーで管理する原文ファイルの保守をなくしたいなら General Translation が適しています。一方、Nuxt の i18n モジュールと確立されたカタログのワークフローを利用しているチームには、引き続き vue-i18n が適しています。動画
- General Translation と Symfony Translation の比較：どちらを使うべきかSymfony Translation は PHP と Twig でメッセージをレンダリングします。General Translation は CI で YAML カタログを翻訳し、翻訳元の変更に合わせて常に最新の状態に保つほか、レビュー担当者が翻訳を編集できる ダッシュボード も提供します。Symfony のレンダリングはそのままに、リリースワークフローに自動翻訳を組み込めます。動画
- General Translation と Rails I18n：両方必要か？Rails I18n はメッセージの検索と、日付や数値の書式設定を担います。General Translation は翻訳を生成し、英語の変更に合わせて翻訳を常に最新の状態に保つほか、チームでレビューできるダッシュボードも提供します。両者を組み合わせれば、リリースのたびに翻訳済みの Rails カタログを出荷できます。動画
- General Translation と Paraglide JS：どちらを使うべきかコピーをインラインで記述したまま、React コンポーネントの構造、共有の用語集、ダッシュボード でのレビューを活かして翻訳を生成したいなら General Translation を選びましょう。コンパイル済みの型付きメッセージ関数と、メッセージ単位のツリーシェイキングを重視するなら Paraglide JS が適しています。Paraglide はカタログをレンダリングするライブラリであり、General Translation は翻訳元のコピーを翻訳の生成から継続的な更新までつなげます。動画
- General Translation と nestjs-i18n：どちらを使うべきか？nestjs-i18n は NestJS アプリでリクエストごとに言語を解決し、言語別の JSON または YAML カタログからメッセージをレンダリングしますが、翻訳そのものは行いません。General Translation の CLI はそれらのカタログを翻訳し、gt-node ライブラリは実行時にしか存在しないコンテンツを翻訳します。そのため、nestjs-i18n はそのままに General Translation を追加できます。動画
- General Translation と Mobility：どちらを使うべきか？Mobility は翻訳済みのモデル属性をデータベースに保存します。General Translation は、用語集とカスタムプロンプトを活用し、API を通じてそれらの翻訳を生成します。両者を組み合わせれば、Rails モデルをそのまま維持しながら、商品リストや投稿などのデータベースコンテンツを翻訳できます。動画
- General Translation と Lingui：どちらを使うべきか？Lingui と同様にテキストをインラインで記述しつつ、JSX の構造を文脈として翻訳を生成したい場合は General Translation を選びましょう。Lingui はインラインのメッセージをカタログに抽出し、翻訳は翻訳者や連携サービスに委ねます。General Translation の CLI はコードの変更に合わせて翻訳を更新し、チームは ダッシュボード でその翻訳をレビューできます。動画
- General Translation と Intlayer の比較：どちらを使うべきかIntlayer は各コンポーネントのコンテンツを、その隣に置いた型付きの宣言ファイルで管理し、すべての言語を並べて記述します。不足している言語は、設定した AI プロバイダーで補完できます。General Translation はテキストを単一の言語でコンポーネント内にインラインで記述し、コードの文脈をもとに他の言語を生成します。動画
- General Translation と GNU gettext：両方必要か？抽出とレンダリングには GNU gettext を引き続き使い、PO ファイルの生成と保守には General Translation を導入しましょう。General Translation は翻訳者向けメモやメッセージの文脈を生成に反映し、共通の用語を適用するほか、レビュー担当者向けに ダッシュボード エディターを提供します。既存の gettext 呼び出しやコンパイル済みのカタログには手を加える必要はありません。動画
- General Translation と Django の翻訳フレームワーク：両方必要なのか？Django の翻訳フレームワークと General Translation は併用できます。メッセージの抽出、言語の選択、レンダリングは Django が担当し、General Translation は製品の用語とダッシュボードでのレビュー内容を反映して、複数形を含む PO ファイルに翻訳を書き込みます。テンプレートや URL パターンはそのままで、翻訳はコードの変更に合わせて更新されます。動画
- General Translation と Babel・Flask-Babel の比較：どちらを使うべきかBabel はあらゆるロケールの日付、数値、通貨を書式設定し、gettext カタログを管理します。Flask-Babel はそれを Flask と連携させるライブラリですが、どちらも文字列の翻訳までは行いません。General Translation の CLI は、Babel の PO ファイルを複数形も含めて全言語分自動で埋めるため、Flask-Babel はそのままに、カタログを手作業で翻訳する手間から解放されます。動画
- General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。動画
- 翻訳ファイルなしでi18nは実現できますか？はい。General Translationの gt-react と gt-next ライブラリを使えば、翻訳キーも、言語ごとに管理するJSONファイルもなしで、ReactとNext.jsのi18nを実現できます。文言は <T> コンポーネント内のJSXにインラインで記述したままで、gt translate コマンドがコードから得た文脈をもとに、ビルド時に各言語の翻訳を生成します。さらにLocadexを使えば、プルリクエストを通じて翻訳を常に最新の状態に保てます。動画
- JSX の条件付きテキストはどのように翻訳すればよいですか？文を分割せずに、すべてのバージョンを翻訳します。三項演算子を使うと文が断片に分かれ、断片は意味を失ううえ、各言語の語順に沿った位置にも置けなくなります。General Translation では <T> の中で <Branch> を使い、文をひとつの単位として翻訳します。動画
ロケール別フォーマット
各ロケールにおける複数形、日付、数値、通貨、右から左に書くテキストへの対応。
- en-US や en-GB などのロケールコードとは？ロケールコードは言語を識別するコードで、必要に応じて文字体系やリージョンも示します。たとえば en-US は米国で使われる英語、zh-Hant-TW は台湾で使われる繁体字中国語を表します。ほとんどのソフトウェアは、ISO コードを組み合わせた BCP 47 タグを使用しています。General Translation は、gt.config.json で指定する翻訳元ロケールとターゲットロケールに BCP 47 コードを使用します。動画
- ロケールごとに数値、日付、通貨を書式設定するにはどうすればよいですか？各値はページのレンダリング時に、読者のロケールと JavaScript の Intl API を使って書式設定し、翻訳対象の文章からは切り離します。General Translation の <Num>、<Currency>、<DateTime>、<RelativeTime> コンポーネントは <T> の中でこの両方を行うため、1 つの翻訳ですべての値に対応できます。動画
- ICUメッセージ形式とは？ICUメッセージ形式は、変数、複数形、select による選択、序数を1つの翻訳可能な文字列で表現するための構文です（例：{count, plural, one {# file} other {# files}}）。各言語は必要な CLDR の複数形カテゴリだけを使用します。英語では one と other を使い、ポーランド語ではさらに few と many が加わります。動画
- CSS で RTL（右から左）言語をサポートするには？lang だけでは書字方向は変わらないため、html 要素に dir="rtl" と lang の両方を指定します。そのうえで、margin-left などの物理的な CSS を margin-inline-start などの論理プロパティに置き換えます。flex の行、グリッドの列、デフォルトのテキストの配置は自動的に反転しますが、translateX()、left、right は反転しません。動画
- React で複数形を扱うにはどうすればよいですか？React で複数形を扱うには、各言語の複数形ごとに文を 1 つずつ用意し、その言語の複数形規則に従って選択します。英語の複数形は 2 種類ですが、ロシア語は 4 種類、アラビア語は 6 種類あるためです。gt-react と gt-next に含まれる General Translation の <Plural> コンポーネントに翻訳元の形を渡せば、各対象言語に必要な形は General Translation が生成します。動画
翻訳
機械翻訳とAI翻訳、翻訳品質、文脈、用語集。
- 開発者向けのおすすめ AI 翻訳ツール：翻訳 API とローカライゼーションプラットフォームの比較ローカライゼーションのパイプラインをすでに自前で運用しているなら、翻訳 API を使いましょう。文脈の付与、一貫性チェック、レビュー、継続的な配信をまとめて管理したいなら、General Translation がおすすめです。DeepL、Google Cloud Translation、OpenAI、Claude は本番環境のパイプラインの基盤として使えますが、General Translation はアプリ、ドキュメント、サイト向けのパイプラインそのものを提供します。動画
- 翻訳メモリとは？AI時代にもまだ必要なのか翻訳メモリ（TM）は、過去の翻訳元と訳文のセグメントのペアを蓄積したデータベースで、翻訳ツールはこれを検索して完全一致、文脈一致、ファジーマッチを見つけます。AIを使う場合でも、承認済みの訳語を再利用し、過去の翻訳を文脈として参照できるようにしておくことは重要です。General Translation は、ファイルの以前のバージョンからマッチする翻訳を再利用し、チームによる編集も保持するため、TM を別途管理する必要はありません。動画
- YAML のロケールファイルはどのように翻訳すればよいですか？翻訳するのは文字列の値だけにし、キー、%{name} や {{name}} などのプレースホルダー、アンカーはそのまま残します。コロンを含む値や % または { で始まる値は引用符で囲み、各ファイルのロケールのルートキーまたはファイル名を設定し、対象言語に必要な複数形キーを追加します。General Translation の CLI は YAML の値をインプレースで翻訳し、キーには手を加えません。動画
- POファイルとPOTファイルはどのように翻訳すればよいですか？Plural-Formsヘッダーが求める各複数形を含め、すべてのmsgstrを埋めます。msgid、msgctxt、プレースホルダーは変更しないでください。msgfmt --checkを実行すると、ヘッダー、複数形の数、および書式フラグ付きエントリのプレースホルダーを検査できます。空のmsgstrがないかは別途確認してください。General TranslationのCLIは、POTテンプレートから言語ごとに翻訳済みのPOファイルを書き出します。動画
- Lottie アニメーションを翻訳するには？アニメーションのテキストレイヤーにある文字列（Lottie JSON の t.d.k[].s.t に格納）を翻訳し、各訳文がボックスに収まっているか、フォントが新しい文字体系に対応しているか、テキストがシェイプとして書き出されていないかを確認します。方法は、言語ごとに再エクスポートする、実行時にテキストを差し替える、スクリプトで JSON を編集する、のいずれかです。General Translation の CLI は dotLottie 1.0 の .lottie ファイルを翻訳し、レイアウトも再調整します。動画
- DeepL の代替：General Translation と DeepL の比較DeepL は機械翻訳 API で、送信したテキストやドキュメントごとに翻訳を返します。一方、General Translation はローカライゼーションプラットフォームです。API では利用者任せになる部分、つまりコードやチームから得られる文脈、あらゆるユーザー接点での用語の統一、ダッシュボードでのレビュー、リリースごとの継続的な翻訳までを担います。動画
- AI翻訳で用語の一貫性を保つにはどうすればよいですか？翻訳しない名称も含めた承認済み用語を一つの用語集にまとめてすべての翻訳リクエストに適用し、変数やコードは翻訳対象から外したうえで、結果をレビューします。General Translation では、コンテキストグループを使ってこれを実現します。コンテキストグループの用語集とカスタムプロンプトは、割り当てたすべてのプロジェクトに適用されます。また、翻訳してはならない値には Var コンポーネントを使用します。動画
- .NET アプリで .resx ファイルを翻訳するには？ニュートラルな .resx ファイルごとに、Resources.fr.resx のようなカルチャ名付きのコピーを作成し、各エントリの値だけを翻訳します。名前、コメント、{0} などのプレースホルダーは変更しないでください。.NET はカルチャごとにサテライトアセンブリをビルドし、fr-CA → fr → ニュートラルファイルの順にフォールバックします。General Translation の CLI を使えば、ニュートラルな翻訳元ファイルからこれらのカルチャファイルを生成できます。動画
- 翻訳をレビュー・編集するにはどうすればよいですか？General Translation では、レビュー担当者がダッシュボードで翻訳を見比べて編集し、ラベルとコメントでレビューの進捗を管理できます。保存した編集内容は、CLI でダウンロードするか、次回の Locadex による翻訳実行でプルリクエストに取り込めます。開発者は gt save-local を使って、レビュー済みのファイルの編集内容をプラットフォームに送り返すこともできます。動画
- Google Slides を翻訳するには？言語ごとにデッキを1部ずつコピーし、すべてのテキストボックス、表のセル、スピーカーノートのテキストを置き換えたうえで、はみ出したテキストのサイズを調整します。General Translation の Google Drive インテグレーションは、言語ごとに翻訳元と同じ場所に個別のコピーを作成して書き込み、フォーマット処理を実行して新しいテキストを各スライドに収めます。動画
- SRT 字幕のタイミングを崩さずに翻訳するには？SRT ファイルではキューのテキストだけを翻訳し、キュー番号、タイムコード、区切りの空行、書式タグは翻訳元のまま残します。そのうえで、1 行あたりの文字数と読み取り速度が配信先の要件を満たしているかを確認します。たとえば Netflix の英語ガイドでは、成人向け番組の上限を 1 行 42 文字、1 秒あたり 20 文字としています。動画
- Markdown と MDX の構文を壊さずに翻訳するには？実行可能なコード、インポート文、JSX コンポーネント名、機械が参照する識別子はそのまま残し、読者向けのテキストだけを翻訳します。General Translation は Markdown と MDX を直接処理でき、表示テキストを持つ props やフロントマターのタイトルも翻訳対象に含めます。ドキュメントが更新されても、一致する既存の翻訳を再利用します。公開前には、ローカライズされたファイルをレビューし、サイトのビルドを実行してください。動画
- i18n の JSON ファイルを翻訳するには？JSON ロケールファイルでは、文字列の値だけを翻訳します。複数形以外のキー、{{name}} などのプレースホルダー、タグは変更せずに残しますが、複数形のキーは言語によって異なる点に注意が必要です。たとえばポーランド語では inbox_few と inbox_many が必要になります。ファイル形式に対応したツールや API を使い、レビューの前に出力をパースして検証してください。動画
- AI翻訳は本番環境のアプリで使えるほど正確か？広く話されている言語であれば多くの場合は十分な精度がありますが、それは自社の対象言語、UI文字列、リスクの高いコンテンツで評価をクリアしてからの話です。WMT25では、Gemini 2.5 Proが16の言語ペアのうち10で人間による参照訳と同等以上の評価を得ました。しかし、文書単位のベンチマークからは、短いインターフェース文字列をそのままリリースできるかどうかまではわかりません。動画
- Google 翻訳の代替：General Translation と Google 翻訳の比較Google 翻訳は、単発のテキストをすばやく翻訳するのに便利ですが、製品を別の言語でリリースするには、各文字列を文脈に沿って翻訳し、用語を統一し、変数や複数形を正しく扱い、レビューを行い、リリースプロセスを整える必要があります。General Translation はコード内の各文字列の文脈を理解し、コードからレビュー、そして毎回のリリースまで、ローカライゼーションのワークフロー全体を自動化します。動画
多言語SEO
多言語サイト向けのロケールルーティング、hreflang、サイトマップ、翻訳済みメタデータ。
- 多言語サイトのサイトマップはどのように作成すればよいですか？各ページのすべての言語版を、それぞれ独立した url エントリとして記載します。サイトマップで hreflang を指定する場合は、各エントリに自身を含むすべての言語版の xhtml:link 代替リンクを追加し、必要に応じて x-default も指定します。また、50,000 URL または 50MB を超える場合はファイルを分割します。General Translation の gt-next はロケールごとに個別の URL を割り当てるため、それらをサイトマップに記載できます。動画
- SEO用のタイトルとメタディスクリプションはどのように翻訳すればよいですか？各言語版のタイトルとメタディスクリプションは、その言語で、対象市場で実際に検索される語句を使って作成します。こうした語句は直訳とは異なることがよくあります。そのうえで、Open Graph、カノニカル、hreflang、html lang、構造化データなど、関連するタグもローカライズします。General Translation の gt-next では、generateMetadata 内で getGT を使ってタイトルとディスクリプションを翻訳できます。動画
- 言語リダイレクトと SEO：URL、クッキー、Accept-Language のどれを使うべきかGooglebot は Accept-Language ヘッダーを送信せず、クロールの大半を米国の IP アドレスから行います。そのため、インデックスさせたいすべてのページの言語は URL で決めましょう。保存済みのクッキーの選択、次いで Accept-Language を使うのは、/ のような中立的なルートのリダイレクト先を決める場合だけにとどめ、その際は一時的な 302 または 307 を使います。動画
- 多言語SEOにおけるサブディレクトリ・サブドメイン・ccTLDの比較1つのプロダクトでサイトとリリースプロセスを共有するなら、example.com/de/ のようなサブディレクトリを使いましょう。国を示せるのは ccTLD だけで、サブドメインなら個別にホスティングできます。Google は ?lang= パラメータを推奨しておらず、.io や .ai のようなバニティドメインは汎用ドメインとして扱います。動画
- hreflang とは？設定方法を解説hreflang は、どの URL が同じページの言語版または地域版であるかを Google に伝え、検索結果に適切なページを表示させるための仕組みです。HTML の link タグ、HTTP の Link ヘッダー、またはサイトマップで追加し、すべてのリンクを相互に参照させたうえで、en-UK ではなく en-GB のような有効なコードを使用してください。動画
- 多言語対応の Next.js アプリで SEO を設定するには？各言語に /en/about や /es/about のようなプレフィックス付きの URL を割り当て、公開している言語ごとに html lang、自己参照のカノニカル、x-default を含む hreflang の代替リンク、翻訳済みのタイトルと説明文、サイトマップのエントリを出力します。未公開のバージョンには noindex を指定します。General Translation の gt-next は各言語を専用の URL にルーティングし、getGT でタイトルを翻訳します。動画
ワークフローツール
ローカライゼーションツールの選定と、継続的ローカライゼーションによる翻訳の同期。
- シート数ではなく使用量に応じて課金する翻訳ツールはどれですか？翻訳コストを依頼した作業量に連動させたい場合は、ユーザー数無制限で Starter のプラットフォーム料金が $0 の General Translation を選びましょう。Crowdin と Lokalise は有料プランで翻訳関連のロールを無制限に利用できますが、それ以外の一部のロールは課金対象です。Hosted Weblate は翻訳者を無制限に追加でき、ホストする文字列の容量に応じて課金されます。
- Weglot の代替: General Translation と Weglot の比較Weglot は、プラグイン、スニペット、またはプロキシを介してレンダリング済みのページを翻訳するウェブサイト翻訳サービスで、Weglot 2.0 では GitHub 上での JSON 翻訳ワークフローが追加されました。General Translation は、ソースコードの国際化、ファイル翻訳、共有の文脈、ダッシュボードでのレビュー、ロケールルーティングを組み合わせたローカライゼーションプラットフォームです。動画
- Payload CMS でコンテンツを翻訳するにはどうすればよいですか？Payload の設定に localization を追加し、各フィールドで localized を true に設定します。これで Payload はロケールごとに 1 つの値を保存できるようになりますが、値自体は自動では入力されません。General Translation の gt-payload プラグインを使うと「Translate」ボタンが追加され、各対象ロケールの値を書き込めます。ドラフトが有効な場合はドラフトとして、そうでない場合は直接書き込みます。公開は一切行いません。動画
- General Translation と Lingo.dev の比較：どちらを使うべきかLingo.dev は設定可能な翻訳エンジンを中核とし、CLI、React、GitHub 向けのツールを通じてそれらを利用します。General Translation はローカライゼーションプラットフォームで、ライブラリ、コードの文脈、共有用語、全プランで使える ダッシュボード でのレビュー、さらにコードの国際化まで担う Locadex を備えています。言語ペアごとにモデルを制御したいなら Lingo.dev を選びましょう。動画
- デプロイのたびに翻訳を最新の状態に保つにはどうすればよいですか？本番環境のビルド前に、翻訳をパイプラインのステップとして毎回実行します。こうすることで、新しいテキストは追加されたデプロイと同時に翻訳済みの状態でリリースされます。General Translation の gt CLI では、CI シークレットとして保存したプロジェクトの APIキーとプロジェクトIDを使い、npx gt translate でこれを実現します。動画
- Storyblok でコンテンツを翻訳するにはどうすればよいですか？Storyblok では、スペースに対象言語を追加し、翻訳可能な各フィールドに言語ごとの値を設定します。General Translation の Storyblok インテグレーションを使うと、ダッシュボードの「同期して適用」でこれらの値が下書きとして入力されるので、Storyblok 上でレビューして公開できます。動画
- Sanity でコンテンツを翻訳するには？各言語を個別のドキュメントとして保存するか、各フィールドにロケールごとの値として保存し、翻訳元をすべての対象ロケールに翻訳します。General Translation の gt-sanity プラグインは Sanity Studio に Translate アクションを追加します。デフォルトでは各翻訳が下書きとしてインポートされるため、レビューしてから公開できます。動画
- Mintlify のドキュメントサイトを翻訳するには？すべてのページの翻訳版を言語ごとのフォルダーに作成し、各言語を docs.json のナビゲーションに追加します。General Translation の AIエージェントである Locadex が、翻訳済みページと言語別ナビゲーションを追加するプルリクエストを作成し、以降の変更も翻訳します。動画
- Locadex エージェントは何をするのか？Locadex は General Translation の AI エージェントで、GitHub リポジトリ内のコードを国際化し、コンテンツを翻訳します。自動化はプルリクエストの作成時、コミットのプッシュ時、または手動で開始したときに実行され、すべての変更はプルリクエストとして届きます。動画
- 翻訳管理システム（TMS）とは？翻訳管理システム（TMS）とは、ソースコンテンツとその翻訳を保管し、翻訳メモリ、用語集、レビュー、機械翻訳、外部連携といった翻訳ワークフローを運用するソフトウェアです。翻訳メモリは、完全一致またはあいまい一致によって過去の翻訳を再利用します。代表的な例として Crowdin、Lokalise、Phrase、Smartling、Transifex があります。動画
- Transifex の代替ツール：General Translation と Transifex の比較マークした JSX を、その構造や開発者が付与した文脈とあわせて翻訳し、結果をバンドルに含めるか CDN から配信したい場合は General Translation を選びましょう。Transifex Native も文字列をコード内で管理しますが、公開は独自のコンテンツ配信サービスを通じて行います。Transifex は、同社の翻訳パートナー、品質スコア、またはスニペットベースの Web サイト翻訳を活用したいチームに適しています。動画
- Smartling の代替ツール：General Translation と Smartling の比較リリースの一環としてコードからアプリの翻訳を生成したい場合は、General Translation を選んでください。Smartling は翻訳管理システム、AI と人手による翻訳サービス、ウェブサイト翻訳プロキシを組み合わせた製品です。General Translation ではテキストをコンポーネント内に置いたまま、その文脈を翻訳に反映でき、チームは ダッシュボード でレビューを行えます。動画
- Reactアプリに最適なi18nライブラリは？React向けの主要なi18nライブラリは、General Translationのgt-react、react-i18next、Lingui、React Intlの4つです。いずれも翻訳のレンダリングと書式設定に対応していますが、JSXにインラインで記述したテキストから翻訳の生成まで行えるのはgt-reactだけです。i18nextのカタログやプラグインを引き続き使いたい場合はreact-i18next、メッセージを抽出してコンパイル済みカタログを生成したい場合はLingui、FormatJSとICU MessageFormatを使いたい場合はReact Intlを選びましょう。動画
- Phrase の代替ツール：General Translation と Phrase の比較アプリとドキュメントを同時にリリースするなら、General Translation は Phrase Strings の有力な代替となります。コードやコンテンツファイルから翻訳を生成し、共通の用語を適用したうえで、リリースワークフローの中で動作します。一方 Phrase は、ソフトウェアのローカライゼーションに加え、ドキュメント中心の TMS、ベンダー管理、幅広い翻訳エンジンの選択肢を備えています。動画
- next-intl の代替：gt-next と next-intl の比較next-intl は、言語ごとのメッセージカタログに用意した翻訳をレンダリングします。gt-next も翻訳をレンダリングしますが、それに加えて General Translation が JSX にインラインで記述したテキストから翻訳を生成します。どちらも MIT ライセンスで、App Router とサーバーコンポーネントに対応しています。既存の next-intl のカタログが問題なく機能しているなら、移行せずにそのまま使い続けながら、General Translation で翻訳できます。動画
- Lokalise の代替ツール：General Translation と Lokalise の比較General Translation は、JSX 内に読みやすいコピーをそのまま記述し、翻訳を開発プロセスに組み込みたいチームにとって、Lokalise の有力な代替手段です。Lokalise は、共有キー、デザインツールとの連携、モバイル向けの OTA（Over-the-Air）配信を軸に設計されています。General Translation は、アプリ内でマークされたコンテンツから翻訳を生成し、ダッシュボード または GitHub のプルリクエスト上でのレビューに対応しています。動画
- General Translation と Weblate の比較：どちらを使うべきかWeblate は、コミュニティやチームでリポジトリ内のファイルを翻訳するために作られた、セルフホスト可能な Git ベースのローカライゼーションプラットフォームです。General Translation は、マークされた JSX と共有されたプロダクトの文脈を用いて、翻訳の生成を開発とリリースに組み込みます。既存の gettext ファイルをそのまま使い続けることも、インライン記述を導入して翻訳元カタログの保守そのものをなくすこともできます。動画
- General Translation と Tolgee の比較：どちらを使うべきか？Tolgee は、キーベースのメッセージ、インコンテキスト編集、AI 翻訳を、セルフホスト可能な 1 つのプラットフォームで提供します。General Translation は読みやすい文言をコンポーネント内に直接記述し、マークされた JSX から翻訳を生成します。そのため、メッセージキーを管理しなくても、新しい文言をすべての言語でリリースできます。動画
- General Translation と TMS（Crowdin、Lokalise、Phrase）の比較翻訳の生成、コードから導出した文脈、レビューをプロダクトのリリースと連動させたい開発チームには General Translation が適しています。既存のカタログとレンダリングライブラリをそのまま使うことも、翻訳キーを使わずにインライン JSX を記述することもできます。TMS は、言語ベンダー、CAT エディター、XLIFF でのやり取りを中心とした翻訳プログラムに適しており、そのインテグレーションを使えばファイル転送を自動化できます。動画
- General Translation と Locize：どちらを使うべきか？Locize は i18next の開発者が手がける翻訳管理システムで、CDN から翻訳を配信し、稼働中のアプリから新しいキーを収集できるほか、AI 翻訳やインコンテキストエディターも備えています。ただし、i18nライブラリとそのキーは引き続き自分たちで管理する必要があります。General Translation は、i18nライブラリそのものとして翻訳まで担うことも、既存の i18next ファイルを翻訳することもできます。動画
- General Translation と i18n-tasks：どちらを使うべきか？i18n-tasks は、Rails I18n の不足キーや未使用キーを検出し、ロケールファイルを整理し、Google Translate、DeepL、OpenAI、Yandex、watsonx を使って不足キーを補完できる Ruby gem です。General Translation は、用語集、カスタムプロンプト、ダッシュボードでのレビューを活用してロケールファイル全体を翻訳します。両者は役割が異なるため、多くのチームにとっては併用も有効です。動画
- Crowdin の代替ツール：General Translation と Crowdin の比較テキストをコンポーネント内に置いたまま、ビルドとあわせて翻訳を生成したいなら General Translation がおすすめです。Crowdin はリソースファイル、翻訳者、レビューワークフローを中心に翻訳プロジェクトを管理するツールで、エンジニアがそれらをアプリに接続し、プロダクトの変化に合わせて保守していく必要があります。なお、オープンソースのコミュニティ翻訳やベンダー主導の翻訳プログラムでは、Crowdin は今も有力な選択肢です。動画
- 開発者にとって最適なローカライゼーションソフトウェアとは？開発者にとって最適なローカライゼーションソフトウェアは、コード内の記述箇所でそのままコンテンツを翻訳し、プロダクトの文脈を活かしながら、すべての言語を常に最新の状態に保ちます。General Translation は、オープンソースのライブラリ、コンテキストグループ、そしてプルリクエストを作成する AI エージェント Locadex によってこれを実現します。動画