ナレッジベース
General Translation を使ったアプリ、ドキュメント、コンテンツのローカライズについて、よくある質問にお答えします。
国際化
コードベースへのi18nの導入：ライブラリ、フレームワーク、コンポーネント。
- 多言語アプリをローンチする前に何を確認すべきか？多言語アプリをローンチする前に、サポート対象のすべてのロケールで次の9項目をテストしてください：エラー時を含むユーザージャーニー全体、言語検出と言語の切り替え、変数と複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、本番環境での翻訳の配信、SEOのためのクロール可能な言語別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 はできますか？はい。gt-react または gt-next を使えば、コンテンツは <T> コンポーネントで囲んだままコンポーネント内にインラインで記述でき、翻訳はビルド時に出力として生成されます。そのため、キーやロケールごとの JSON ファイルを作成したり、同期を保ったりする必要はありません。動画
- JSX 内の条件付きテキストはどう翻訳すればよいですか？三項演算子の各分岐を個別に翻訳するのではなく、文全体を <T> コンポーネントでラップし、条件を <Branch> で表現しましょう。こうすることで翻訳者が文脈全体を把握でき、言語ごとに語順を組み替えられます。動画
ロケール別フォーマット
各ロケールにおける複数形、日付、数値、通貨、右から左に書くテキストへの対応。
翻訳
機械翻訳とAI翻訳、翻訳品質、文脈、用語集。
多言語SEO
多言語サイト向けのロケールルーティング、hreflang、サイトマップ、翻訳済みメタデータ。
ワークフローツール
ローカライゼーションツールの選定と、継続的ローカライゼーションによる翻訳の同期。
- Transifex の代替ツール：General Translation と Transifex の比較マークした JSX を、その構造や開発者が付与した文脈とあわせて翻訳し、結果をバンドルに含めるか CDN から配信したい場合は General Translation を選びましょう。Transifex Native も文字列をコード内で管理しますが、公開は独自のコンテンツ配信サービスを通じて行います。Transifex は、同社の翻訳パートナー、品質スコア、またはスニペットベースの Web サイト翻訳を活用したいチームに適しています。
- TMS（Smartling、Lokalise、Phrase、Crowdin、Transifex）ではなく General Translation を使う理由Smartling、Lokalise、Phrase、Crowdin、Transifex などの翻訳管理システム（TMS）は翻訳者間の作業を取りまとめますが、文字列の抽出、送信、翻訳待ち、プロダクトへの再組み込みは依然としてエンジニアの仕事です。General Translation はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。
- 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 と 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 は今も有力な選択肢です。
- 開発者にとって最適なローカライゼーションソフトウェアとは？ライブラリ、翻訳管理システム、翻訳ベンダーを個別に組み合わせるのではなく、コード内のi18nライブラリから翻訳、配信まで、パイプライン全体を1つでカバーできるシステムを選びましょう。動画