# General Translation Knowledge Base: 開発者にとって最適なローカライゼーションソフトウェアとは？ URL: https://generaltranslation.com/ja/kb/best-localization-software.mdx Docs index: https://generaltranslation.com/llms.txt Description: 開発者にとって最適なローカライゼーションソフトウェアは、コード内の記述箇所でそのままコンテンツを翻訳し、プロダクトの文脈を活かしながら、すべての言語を常に最新の状態に保ちます。General Translation は、オープンソースのライブラリ、コンテキストグループ、そしてプルリクエストを作成する AI エージェント Locadex によってこれを実現します。 Category: ワークフローツール Last updated: 2026-10-21 Authors: Jackie Chen Published: 2026-05-04 開発者にとって最適なローカライゼーションソフトウェアとは、コード内の記述箇所でそのままコンテンツを翻訳し、各翻訳にプロダクトの文脈を与え、コードの変更に合わせてすべての言語を最新の状態に保ち、さらにその言語を読める人が結果をレビューできるものです。General Translation は、この4つすべてを1つのシステムで実現する開発者向けローカライゼーションソフトウェアです。 General Translation は、オープンソースの国際化 (i18n) ライブラリ、AI ネイティブな翻訳プラットフォーム、そしてプルリクエストを通じてコードの国際化とコンテンツの翻訳を行う AI エージェント Locadex を組み合わせたものです。コードと翻訳がつながっているため、各翻訳はコードの文脈を引き継ぎ、リリースを重ねても一貫性を保てます。 ## Video The video is narrated in English, with English captions. [What is the best localization software for developers?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-best-localization-software.mp4) (44 秒) General Translation covers the whole pipeline, from your code to translation and delivery. Run `npx gt init` and wrap the content in a `` component, put one command in your build that writes the translations, and connect your repository so Locadex can open a pull request with new translations when you push. ## アプリのローカライゼーションソフトウェアはどのように選べばよいですか？ ローカライゼーションソフトウェアは、アプリのテキストがどこにあるか、文言がどのくらいの頻度で変わるか、そして特定の種類の製品でしか満たせない要件があるかどうかを基準に選びます。テキストが React や Next.js のコンポーネント内にあり、リリースのたびに変更されることが多いなら、General Translation のように、コード内と CI で翻訳を行う開発者優先のツールを選びましょう。特定の要件がある場合は、ほかの製品が適しています。翻訳会社が XLIFF や Office ファイルで作業するなら Phrase、ネイティブモバイルアプリのテキストをアプリストアでのリリースなしで更新する必要があるなら Lokalise、自社サーバー上でプラットフォームを運用する必要があるなら Weblate または Tolgee、1つの文書を別の言語にしたいだけなら Google Translate です。 ローカライゼーションソフトウェアが担う役割は3つあり、どの選択肢でも一部は利用者側に任されます。国際化は、各ロケールの日付、数値、複数形をレンダリングできるようにコードを整える作業です。翻訳は、各言語でテキストを書く作業です。ツールは、コードの変更に合わせて翻訳を同期させ続ける役割を担います。i18nライブラリ、翻訳管理システム、翻訳ベンダーがこれらの役割を分担すると、どのツールも製品の一部しか把握できなくなります。 ## ローカライゼーションの各アプローチはどう違うのか？ | アプローチ | 得意なこと | 自分で対応する必要があること | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | i18nライブラリ単体 (`i18next`、`react-intl`、`next-intl`) | 翻訳のレンダリングや値のフォーマットを担う成熟したランタイム | キーファイルへの文字列の抽出、コンポーネントのリファクタリング、すべての翻訳の作成と保守 | | Google Translate | テキストや文書全体を高速かつ汎用的に翻訳できる | 文字列を周囲の UI やトーンを考慮せず 1 つずつ翻訳するため、複数形、配信、レビューは自分で対応する必要がある | | AI API の直接利用 (OpenAI API、Claude API) | 指示に沿った自然な翻訳 | 文字列ごとの文脈の用意、リリースをまたいだ用語の統一、複数形とロケールのフォーマット、レビュー、配信 | | 翻訳管理システム (TMS) 。Phrase、Lokalise、Crowdin など、コードベースの外で文字列を管理するもの | 翻訳者やベンダーが文字列を編集・レビューできる場所を一元化できる | 文字列のファイルへのエクスポートと翻訳結果のインポート、エクスポートした一覧には含まれない文脈の補完、コードの変更に合わせたエクスポートの更新 | | General Translation (ライブラリ、コンテキストグループ、Locadex) | [``](/docs/react/reference/components/t) が JSX をインプレースで翻訳し、コンテキストグループ (用語やトーンに関する共有の指示) が新しい翻訳に適用され、`gt` CLI または Locadex が変更のたびに翻訳する | コンテンツを [``](/docs/react/reference/components/t) でラップすること (または Locadex に任せること) 、および Locadex とチーム招待に必要な Starter プランまたはエンタープライズプラン | 翻訳者が完成済みの言語ファイルを納品しており、それをレンダリングするランタイムだけが必要な場合は、i18nライブラリ単体で十分です。1 つの文書を別の言語で読んだり送ったりするだけなら Google Translate、自社プロダクトのモデル呼び出しの一工程として翻訳を行うなら AI API の直接利用が適しています。翻訳会社との XLIFF ファイルのやり取りや、リリース済みネイティブアプリのテキスト更新など、General Translation にない機能が必要な場合は、翻訳管理システムを使用してください。文言がコード内にあり、リリースのたびに変更されることが多く、各変更をそのリリースと同時にすべての言語で提供したい場合は、General Translation を使用してください。 ## 有料のローカライゼーションソフトウェアを導入する価値はあるのか、それとも JSON ロケールファイルを自分で管理すれば十分か？ アプリが小規模なうちは、JSON ロケールファイルを自分で管理できます。目安は、文字列が数百件、対象言語が 1〜2 言語、文言がめったに変わらない状態です。作業量は「キーの数 × 言語の数」で増えていきます。たとえば、500 個のキーを 10 の対象言語で持つアプリでは、常に最新に保つべき翻訳エントリが 5,000 件になり、50 言語なら 25,000 件にもなります。 翻訳元の文言を変更するたびに、同じ作業をすべての言語ファイルで繰り返すことになります。新しい文字列を追加するには、ソースファイルにキーを追加し、さらにすべてのロケールファイルに翻訳を追加しなければなりません。文字列を変更すると、誰かが翻訳し直すまでその翻訳は古いままになります。コンポーネントを削除した場合も、誰かが取り除くまでそのキーはすべてのファイルに残り続けます。 i18nライブラリがこうした作業を肩代わりしてくれるわけではありません。i18next、react-intl、next-intl などのライブラリは、ファイルの内容をそのままレンダリングするだけで、翻訳を書き込んだり更新したりはしません。そのため、`en.json` に追加したキーを `ja.json` に追加し忘れると、日本語ユーザーにはその文字列が未翻訳のまま表示されます。 ローカライゼーションソフトウェアにお金を払う価値があるのは、これらのファイルの保守にかかるエンジニアや翻訳者の工数がソフトウェアの費用を上回る場合や、翻訳待ちでリリースが遅れる場合です。General Translation では、文言は [``](/docs/react/reference/components/t) で囲んだままコンポーネント内に記述するため、キーに名前を付ける必要がありません。さらに、[`npx gt translate`](/docs/cli/reference/commands/translate) がビルドのたびに各言語のファイルを書き出します。CLI は翻訳元が変更されたコンテンツだけを翻訳し、同じファイルの以前のバージョンに一致する翻訳があればそれを再利用できます。 General Translation のライブラリは無料で、MIT ライセンスで提供されています。翻訳を自分で用意する場合は、アカウントなしでも利用できます。[`npx gt generate`](/docs/cli/reference/commands/generate) を使うと、手作業で翻訳するためのテンプレートファイルがロケールごとに書き出されます。プラットフォーム経由での翻訳の生成は従量課金制で、シート単位の料金はかかりません。 ## 他のローカライゼーション製品の方が適しているのはどのような場合か？ General Translation が提供していない機能が必要な場合は、他の製品の方が適しています。以下の各機能については、それぞれの製品のドキュメントに記載されています。 * **XLIFF や Office ファイルで作業する翻訳会社。** [Phrase TMS](https://phrase.com/platform/tms/) は XLIFF 1.2／2.0 と Microsoft Office ファイルをサポートし、翻訳メモリ付きの CAT ツールを翻訳者に提供するほか、1 つのジョブに複数のベンダーを割り当てることもできます。General Translation は AI で翻訳を行うため、XLIFF や Office ファイルの読み書きには対応していません (Google Drive インテグレーションでは Google ドキュメント、スプレッドシート、スライドを翻訳できます) 。そのため、これらのファイルを前提とした翻訳会社のワークフローには TMS が適しています。 * **リリースなしでテキストを更新したいネイティブモバイルアプリ。** Lokalise の iOS、Android、Flutter 向け [OTA SDK](https://developers.lokalise.com/docs/ota-sdk) は、アプリの起動時に新しい翻訳をダウンロードするため、アプリストアで新バージョンを公開する必要がありません。一方、General Translation の CLI は [iOS](/docs/cli/reference/formats/xcstrings-files) および [Android](/docs/cli/reference/formats/android-strings-files) の文字列ファイルをビルド前に翻訳するため、新しい翻訳がネイティブアプリに反映されるのは次回のリリース時になります。 * **自社サーバーで運用するローカライゼーションプラットフォーム。** [Weblate](https://docs.weblate.org/en/latest/admin/install.html) は Docker、virtualenv、Kubernetes でインストールでき、[Tolgee](https://docs.tolgee.io/platform/self_hosting/getting_started) は Docker で動作します。General Translation のライブラリはオープンソースですが、翻訳プラットフォームとダッシュボードは General Translation がホストしています。 * **スニペットで翻訳する Web サイト。** [Transifex Live](https://help.transifex.com/en/articles/6244596-introduction-to-transifex-live) はサイトに追加した JavaScript スニペットで動作し、ファイルを介さずにページから直接コンテンツを翻訳用に保存します。ただし React や Vue のアプリについては、Transifex は代わりに Native SDK を推奨しています。General Translation が翻訳するのは、コード内でマークされたコンテンツ、`gt.config.json` に記載されたファイル、そして Sanity、Storyblok、Payload、Google Drive などの接続済みツール内のコンテンツです。 * **オープンソースプロジェクト向けの無料ライセンス。** [Crowdin](https://crowdin.com/product/for-open-source) は、承認済みのオープンソースライセンスを採用していること、プロジェクトに紐づく商用製品がないことなどの条件を満たすオープンソースプロジェクトであれば無料で利用できます。General Translation では、無料枠を超えるプラットフォーム利用は有料です。 こうした要件がない場合、翻訳管理システムを使うと、リリースのたびにエクスポートとインポートの手間が発生します。文字列をファイルに抽出して TMS と同期し、翻訳を待ってから結果をインポートしなければなりません。また、エクスポートされた文字列には、コード内でその文字列を取り巻くコンポーネント、変数、条件が含まれないため、翻訳者はその文脈がわからないまま作業することになります。 ## 開発者優先のローカライゼーションツールが適しているのはどのような場合か？ 開発者優先のローカライゼーションツールが適しているのは、プロダクトのテキストの大半がコード内 (たとえば React や Next.js のコンポーネント内) にあり、ほとんどのリリースで文言が変わる場合です。General Translation はまさにこうしたケースのために設計されています。文言はコンポーネント内に置いたまま、翻訳はビルド時またはプルリクエスト内で実行されます。コードを編集しないレビュアーはダッシュボードで翻訳を確認でき、各変更はそれを追加したリリースで全言語同時に提供されます。 General Translation は、すでに i18nライブラリを使用しているチームにも適しています。アプリで next-intl や react-i18next を使用している場合、`gt` CLI がそのライブラリを検出し、既存のメッセージファイルをそのライブラリの文字列構文のまま翻訳します。そのため、ライブラリを乗り換えることなく General Translation を導入できます。 ## ローカライゼーションソフトウェアの代わりに Google Translate や AI API を使えますか？ 単発のテキストであれば使えます。Google Translate のウェブサイトでは[ドキュメント全体を翻訳](https://support.google.com/translate/answer/2534559)できます。最大 10 MB の `.docx`、`.pdf`、`.pptx`、`.xlsx` ファイルをアップロードすると、翻訳結果をダウンロードできます。OpenAI API や Claude API が適しているのは、プロダクトですでに行っているモデル呼び出しの一工程として翻訳を組み込み、モデルの選択やプロンプトの作成を自分で行いたい場合です。たとえば、サポートチケットに顧客の言語で返信するようなケースが該当します。 本番環境のアプリでは、翻訳そのもの以外にも多くの要素が必要です。各文字列の文脈、リリースをまたいだ用語の統一、複数形とロケールに応じたフォーマット、レビュー、そしてアプリへの配信です。Google Translate は文字列を1つずつ個別に翻訳します。また AI API を使う場合は、すべての文字列について文脈を自分で組み立てなければなりません。 General Translation は、AI 翻訳を取り巻くこうした部分を引き受けます。各 [``](/docs/react/reference/components/t) ブロックをネストされた要素ごと1つの単位として翻訳し、コンテキストグループ内の用語集とカスタムプロンプトを適用します。さらに、ロケールごとに値を書式設定し、ビルドに組み込むか CDN 経由で翻訳を配信し、すべての翻訳をダッシュボードに表示してレビューできるようにします。 ## General Translation はコード内のコンテンツをどのように翻訳しますか？ General Translation の [``](/docs/react/reference/components/t) コンポーネントは JSX をラップし、ネストされた要素も含めてひとつの単位としてインプレースで翻訳します。そのため、キーを割り当てたり、言語ごとのファイルを手作業で作成したりする必要はありません。[`npx gt init`](/docs/cli/reference/commands/init) を実行すると、フレームワークが検出され `gt.config.json` が作成されます。あとはコンテンツをラップするだけです。 ```tsx title="app/page.tsx" import { T } from 'gt-next'; export default function Home() { return (

Welcome to my app

This content will be translated automatically.
); } ``` プレースホルダーや `aria-label` の値などのスタンドアロンの文字列には、[`useGT`](/docs/react/reference/hooks/use-gt) が返す関数を使用します。General Translation のライブラリは無料のオープンソースで、MIT ライセンスで提供されています。Next.js 向けの `gt-next`、React 向けの `gt-react`、Vue 向けの `gt-vue`、Node.js 向けの `gt-node` があります。 React アプリでは、General Translation の [``](/docs/react/reference/components/num)、[``](/docs/react/reference/components/currency)、[``](/docs/react/reference/components/datetime) コンポーネントが、ロケールに応じて値を書式設定します。[``](/docs/react/reference/components/plural) は言語ごとに適切な複数形を選択します。複数形の種類は、英語では 2 つ、アラビア語では 6 つ、日本語では 1 つです。 ## General Translation は各翻訳にどのように文脈を与えるのか？ モデルが文字列を正しく翻訳するには、その文字列がプロダクト内で何を意味するのかを把握している必要があります。General Translation は、プロジェクトに割り当てた[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を、そのプロジェクト内のすべての新しい翻訳に適用します。コンテキストグループには、一貫した扱いが必要な用語 (翻訳せずに残す製品名など) を定める用語集と、対象読者、文体の丁寧さ、スタイルを指定するカスタムプロンプトが含まれます。1 つのグループをアプリ、ウェブサイト、ドキュメントに共通して割り当てることもできます。 特定の文字列だけが曖昧な場合は、General Translation の [``](/docs/react/reference/components/t) に `context` プロパティを渡します。たとえば、「cells」がスプレッドシートのセルを指すのか携帯電話を指すのかを明示できます。`gt.config.json` で `includeSourceCodeContext` 解析フラグを有効にすると、前後のソースコード行が各翻訳の文脈として追加されます。 ## General Translation の翻訳はどこから読み込まれますか？ 本番環境では、General Translation はユーザーがアプリを読み込む前のビルド時に [``](/docs/react/reference/components/t) のコンテンツを翻訳し、翻訳が存在しない場合は原文にフォールバックします。`gt-next` と `gt-react` が翻訳をどこから読み込むかは、設定によって決まります。 `gt.config.json` でローカルの `output` パスを指定し、[`loadTranslations`](/docs/react/reference/functions/load-translations) 関数を用意した場合、翻訳は[バンドルに含まれる](/docs/react/guides/storing-translations)ため、更新するには再デプロイが必要です。`projectId` を指定し、[`loadTranslations`](/docs/react/reference/functions/load-translations) 関数を用意しない場合は、実行時に General Translation の CDN から翻訳が読み込まれます。その際は、あらかじめプロジェクト設定で CDN を有効にし、[`npx gt translate --publish`](/docs/cli/reference/commands/translate) で翻訳を公開しておく必要があります。 ## コードの変更に合わせて翻訳を最新の状態に保つには？ CI でビルドコマンドの前に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行すれば、本番環境のビルドには常に最新の翻訳が含まれます。General Translation の CLI は、翻訳元が変更されたコンテンツのみを翻訳します。 コードの変更も自動化するには、General Translation の AI エージェントである [Locadex](/docs/platform/locadex/quickstart) に GitHub を接続します。Locadex の各自動化は、「いつ実行するか」「何を変更するか」「変更をどのように GitHub に反映するか」の 3 点で設定します。各設定のデフォルト値は[自動化の設定](/docs/platform/locadex/guides/configuring-automations)を参照してください。 * **いつ実行するか。** **Run when** では、自動化を開始するタイミングを、プルリクエストが変更されたとき、**Target branch** にコミットがプッシュされたとき、または誰かが **Run now** をクリックしたときのみ、から選択します。プルリクエストに `/locadex` とコメントすると、その時点のリビジョンに対する実行をリクエストできます。また、**Active** をオフにすると自動トリガーが一時停止します。 * **何を変更するか。** 変更の種類はテンプレートで決まります。**Generate code** はインターフェースのテキストを [``](/docs/react/reference/components/t) などの i18n 呼び出しでラップし、**Generate translations and push** は新規または更新されたソースコンテンツを各対象言語に翻訳し、**Keep locales in sync** は言語の追加や削除に合わせてプロジェクトファイルを更新します。**Target directory** ではモノレポ内の特定のアプリを自動化の対象に指定でき、**Changed files only** は **Generate code** の関連性チェックを変更された行に限定し、**Preserve local edits** は Locadex が以前に生成したファイルへの手動編集を保持します。さらに、前処理・後処理コマンドを使えば、各実行の前後に独自のインストール、ビルド、lint、チェックなどの手順を実行できます。 * **変更をどのように GitHub に反映するか。** Locadex は **Created branch prefix** を付けた名前のブランチにコミットし、ターゲットブランチに対してプルリクエストを作成します。プルリクエストによって実行がトリガーされた場合、Locadex は自身のプルリクエストへのリンクを元のプルリクエストにコメントし、同じソースブランチに対する以降の自動実行ではそのプルリクエストを更新します。プルリクエストのタイトル、説明、コミットメッセージを設定できるほか、**Auto-merge** をオンにすると、チェックに合格した Locadex のプルリクエストを自動でマージできます。 Locadex は、Next.js、Vite・Gatsby・React Router などのツールで構築された React アプリ、およびドキュメントフレームワークの Mintlify、Fern、Docusaurus に対応しています。利用には Starter プランまたはエンタープライズプランが必要です。 ## AI翻訳はどのようにレビューするのか？ AI翻訳の品質は大きく向上しましたが、本番環境で運用するアプリでは、その言語を理解できる人によるチェックが今も欠かせません。General Translationのダッシュボードで **プロジェクト > 翻訳** を開き、並べて比較したいロケールを選択して、セルをクリックすると編集できます。ダウンロードした翻訳ファイルを手動で編集した場合は、[`npx gt save-local`](/docs/cli/reference/commands/save-local) を実行すると、編集内容がプラットフォームに反映されます。 General Translationでチームメンバーを招待するには、Starterプランまたはエンタープライズプランが必要です。Starterプランはユーザー数無制限で、シート単位の料金もかからないため、翻訳者、プロダクトマネージャー、現地のレビュアーなど、関係者全員にアクセス権を付与できます。 ## General Translation の料金はいくらですか？ General Translation は使用量に応じた課金制で、ユーザー数に応じた料金はかかりません。Starter プランはプラットフォーム料金が $0 で、ユーザー数・プロジェクト数・言語数は無制限です。翻訳エディター、GitHub連携、Locadex も含まれており、営業担当との打ち合わせなしですぐに始められます。エンタープライズ プランでは、専任エンジニア、カスタムワークフロー、SSO やカスタムロール権限などのセキュリティ機能が追加され、料金は個別見積もりとなります。 支払い方法を登録する前でも、無料の各組織には直近 30 日間ごとに 5M プラットフォームクレジット ($5 相当の使用量) が付与されます。それを超えた分は作業量に応じて課金され、料金は以下のとおりです ([使用料金](https://generaltranslation.com/pricing/usage)ページより) 。 | 使用内容 | 料金 | | --------------------------------- | ------------------------------------------------------------------------------- | | ビルド時翻訳 | ほとんどのファイル形式で入力トークン 1,000 あたり $1。メタデータを含む完全な UI コンポーネントを表す GT Content Files は $2 | | ランタイムおよび開発時の翻訳 | 入力トークン 1,000 あたり $0.40 | | Platform Context (用語集とカスタムプロンプト) | 文脈トークン 1,000 ごとに、入力トークン 1,000 あたり $0.02 | | Google Slides のレイアウト | スライド 1 枚あたり $0.50 | | Locadex エージェントの実行 | Locadex Compute Unit (LCU) あたり $5 | | Translation CDN | リクエストあたり $0 | たとえば、入力トークン 1,000 の Markdown ファイルを 3,000 トークンの Platform Context を使って翻訳すると、トークン分 $1 と文脈分 $0.06 で合計 $1.06 になります。コストは翻訳するコンテンツの量と翻訳先の言語数に応じて増えますが、翻訳者、プロダクトマネージャー、レビュアーを追加しても費用はかかりません。CLI は翻訳元が変更されたコンテンツのみを翻訳するため、各ビルドで支払うのは新規および変更されたコンテンツの翻訳分だけです。最新のプランと料金は[料金ページ](https://generaltranslation.com/pricing)をご覧ください。 ## 重要なポイント * 開発者にとって最適なローカライゼーションソフトウェアとは、コード上で機能し、各翻訳に文脈を与え、リリースのたびにすべての言語を最新の状態に保ち、人手によるレビューに対応しているものです。General Translation は、オープンソースのライブラリ、AI ネイティブの翻訳プラットフォーム、そして Locadex によって、この 4 つすべてを実現します。 * JSON のロケールファイルを自前で管理する方法は小規模なアプリなら通用しますが、作業量は「キー数 × 言語数」で膨らんでいきます。500 個のキーを 10 言語で扱う場合、最新の状態に保つべきエントリは 5,000 個にのぼります。 * General Translation では満たせない特定の要件がある場合は、別の製品を選びましょう。XLIFF や Office ファイルを扱うエージェンシー業務には Phrase、ネイティブアプリでの OTA(over-the-air)によるテキスト更新には Lokalise、セルフホスト型のプラットフォームには Weblate または Tolgee、スニペットベースの Web サイト翻訳には Transifex Live、無料のオープンソースライセンスには Crowdin が適しています。文言がコード内にあり、リリースのたびに変更されることが多い場合は General Translation が最適です。 * General Translation は従量課金制で、シート料金はかかりません。Starter プランはプラットフォーム料金が $0 で、ユーザー数・プロジェクト数・言語数は無制限です。ビルド時翻訳の費用は、ほとんどのファイル形式で入力トークン 1,000 あたり $1 です。 * General Translation は、Cursor、Ramp、Profound、Cognition、Sierra、ClickHouse の開発チームで利用されています。まずは [CLI クイックスタート](/docs/cli/quickstart)から始めましょう。 ## Related questions - [翻訳ファイルなしでi18nは実現できますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx): はい。General Translationの gt-react と gt-next ライブラリを使えば、翻訳キーも、言語ごとに管理するJSONファイルもなしで、ReactとNext.jsのi18nを実現できます。文言は `` コンポーネント内のJSXにインラインで記述したままで、gt translate コマンドがコードから得た文脈をもとに、ビルド時に各言語の翻訳を生成します。さらにLocadexを使えば、プルリクエストを通じて翻訳を常に最新の状態に保てます。 - [多言語対応の Next.js アプリで SEO を設定するには？](https://generaltranslation.com/ja/kb/multilingual-nextjs-seo.mdx): 各言語に /en/about や /es/about のようなプレフィックス付きの URL を割り当て、公開している言語ごとに html lang、自己参照のカノニカル、x-default を含む hreflang の代替リンク、翻訳済みのタイトルと説明文、サイトマップのエントリを出力します。未公開のバージョンには noindex を指定します。General Translation の gt-next は各言語を専用の URL にルーティングし、getGT でタイトルを翻訳します。 - [シート数ではなく使用量に応じて課金する翻訳ツールはどれですか？](https://generaltranslation.com/ja/kb/translation-pricing-without-seat-fees.mdx): 翻訳コストを依頼した作業量に連動させたい場合は、ユーザー数無制限で Starter のプラットフォーム料金が $0 の General Translation を選びましょう。Crowdin と Lokalise は有料プランで翻訳関連のロールを無制限に利用できますが、それ以外の一部のロールは課金対象です。Hosted Weblate は翻訳者を無制限に追加でき、ホストする文字列の容量に応じて課金されます。 ## Previous and next questions - Previous question: [多言語対応の Next.js アプリで SEO を設定するには？](https://generaltranslation.com/ja/kb/multilingual-nextjs-seo.mdx) - Next question: [翻訳ファイルなしでi18nは実現できますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.