# General Translation Knowledge Base: Lokalise から General Translation へ移行するには？ URL: https://generaltranslation.com/ja/kb/migrate-from-lokalise.mdx Docs index: https://generaltranslation.com/llms.txt Description: リソースファイル、i18nライブラリ、レビュー済みの翻訳はそのまま使えます。空の翻訳を除外して Lokalise からエクスポートし、Lokalise の GitHub 同期を無効にしたうえで、最初の npx gt translate を実行する前に npx gt upload でファイルをインポートします。以降は General Translation がビルド時に新規・変更された文字列を翻訳します。用語集は コンテキストグループ に、キーの説明はキーごとの文脈として引き継がれます。 Category: ワークフローツール Last updated: 2026-11-12 Authors: Kevin Wu Published: 2026-11-12 Lokalise は文字列をプロジェクト内のキーとして保存し、エクスポート時にプラットフォームごとのリソースファイルを生成して、リポジトリと同期します。General Translation に移行しても、アプリが現在読み込んでいるリソースファイルはそのまま使えます。`gt` CLI が既存の翻訳ごとファイルをインポートし、以降はビルドや CI で新規・変更された文字列を翻訳します。i18nライブラリやキーを変更する必要はありません。文言をインラインに移すかどうかは任意で、別途行う作業です ([react-i18next からの移行](/kb/migrate-from-react-i18next)または [next-intl からの移行](/kb/migrate-from-next-intl)を参照) 。用語集は コンテキストグループ となり、アプリやドキュメント、その他のプロジェクトで共有できます。 ## Lokalise から何が引き継がれるか | Lokalise | General Translation | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | プラットフォームごとにファイルとしてエクスポートされたキー | 同じファイルを `gt.config.json` の `files` に記載 | | 翻訳 | [`npx gt upload`](/docs/cli/reference/commands/upload) でインポートし、翻訳元が変更されるまで保持 | | 用語集 | CSV からインポートした[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)の用語集 | | Pro AI 向けのスタイルガイド | 全体またはロケールごとの[カスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations) | | キーの説明と文字数制限 | iOS および Android ファイル内のコメント (General Translation が文脈として読み取ります) 、または JSON・YAML の場合は[キーごとのメタデータ](/docs/cli/reference/keyed-metadata)ファイル | | 翻訳メモリ | アップロードした翻訳。変更のない文字列は既存の翻訳がそのまま使われ、新規または変更された文字列のみが翻訳されます。TMX ファイルはインポートされません | | GitHub App、自動プル、GitHub Actions | CI での [`npx gt translate`](/docs/cli/reference/commands/translate)、または [Locadex](/docs/platform/locadex/quickstart) のプルリクエスト | | レビュータスク | [ダッシュボード](/docs/platform/dashboard/guides/reviewing-translations)での編集 (エンタープライズプランでは承認も可能) | | iOS、Android、Flutter 向けの OTA SDK | 翻訳はリソースファイルに含まれ、アプリのリリースごとに配信 | CLI は JSON、YAML、`.pot` と `.po`、iOS の `.strings`、`.stringsdict`、`.xcstrings`、Android の `strings.xml`、`.resx`、HTML、Markdown と MDX などを読み取れます ([対応フォーマット](/docs/cli/reference/config#files)を参照) 。XLIFF、ARB、Java の `.properties`、CSV や XLSX 形式のエクスポートは読み取れないため、ダウンロード時は対応フォーマットを選択してください。 ## ステップ 1: 言語ごとに 1 つのファイルをエクスポートする Lokalise は元のファイルを保持せず、エクスポートのたびにキーからファイルを生成します。Lokalise によって同期されたファイルがすでにリポジトリにある場合は、出力が一致するよう同じ設定でエクスポートし、インポート前にリポジトリとの差分を確認してください。 [`lokalise2` CLI](https://github.com/lokalise/lokalise-cli-2-go/blob/master/docs/lokalise2_file_download.md) を使う場合、Web アプリの JSON エクスポートは次のようになります。 ```bash lokalise2 --token "$LOKALISE_TOKEN" --project-id "$LOKALISE_PROJECT_ID" file download \ --format json \ --original-filenames=false \ --bundle-structure "locales/%LANG_ISO%/common.json" \ --unzip-to . \ --export-empty-as skip \ --filter-data nonhidden \ --async ``` 問題なくインポートするには、次の4つの設定が重要です。 * **`--export-empty-as skip`。** デフォルトでは、Lokalise は未翻訳のキーを空文字列としてエクスポートします。また `base` を指定すると、未翻訳のキーは原文で埋められます。どちらの場合も、そのまま翻訳としてインポートされてしまいます。`skip` を指定すれば、これらのキーは除外されます。 * **複数形とプレースホルダーの形式。** 使用しているライブラリが読み込む形式に合わせてください。i18next の `_one` や `_other` キーには `--plural-format i18next_v4` を、next-intl には `--plural-format icu --placeholder-format icu` を指定します (詳しくは Lokalise の [plural and placeholder formats](https://developers.lokalise.com/reference/api-plurals-and-placeholders) を参照してください) 。 * **プラットフォーム。** 各キーは1つ以上のプラットフォームに属しており、エクスポートには指定した形式に対応するプラットフォームのキーしか含まれません。プラットフォームごとにエクスポートを実行してください。iOS には `--format strings` と `stringsdict` を、Android には `--format xml` を使用します。 * **`--async`。** Lokalise の同期ダウンロードは、キーと言語の組み合わせが 10,000 未満のプロジェクトにしか対応していません。それ以上の規模のプロジェクトでは非同期ダウンロードを使用する必要があります。 CLI を使わない場合は、プロジェクトの **Download** ページを開いて形式を選択し、**Empty translations** を skip に設定してから **Build and download** をクリックします。ダウンロードには、コントリビューターの **ファイルをダウンロード** 権限が必要です。 フォルダ名に含まれるロケールコードも確認してください。Lokalise は `en_GB` のような独自の言語コードを使用しており、CLI はこれを `locales` リストと完全一致で照合します。コードを上書きするには、**Download** ページでコードをクリックするか、`--language-mapping` を使用します。あるいは、エクスポートされたとおりのコードを `gt.config.json` に記載してください。 ## ステップ 2: Lokalise の同期を停止する General Translation がファイルを書き込む前に、リポジトリへ翻訳を書き込む経路をすべて無効にしてください。 * GitHub リポジトリの設定から、Lokalise の自動プル用 Webhook を削除します。 * ダウンロード時の GitHub トリガーの使用をやめます (このトリガーは新しいブランチからプルリクエストを作成します) 。 * Lokalise の push / pull 用 GitHub Actions を使用しているワークフローを削除するか、無効にします。 GitLab、Bitbucket、Azure DevOps 用のアプリでも手順は同じです。2 つのツールが同じファイルに書き込むと、最後に書き込んだ方の内容で上書きされます。 ## ステップ 3：CLI でファイルを参照する `gt` CLI をインストールし、エクスポートしたファイルの情報を `gt.config.json` に記述します。 ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "fr", "pt-BR"], "files": { "json": { "include": ["locales/[locale]/*.json"] } } } ``` CLI は、`package.json` に `i18next` または `next-intl` が含まれている場合、JSON 内の i18next および next-intl のメッセージ構文を解釈し、それ以外の JSON の値はプレーンな文字列として扱います ([JSON ファイル](/docs/cli/reference/formats/json-files)を参照) 。 [`npx gt login`](/docs/cli/reference/commands/login) でサインインして `GT_PROJECT_ID` を設定するか、設定ファイルで `projectId` を指定してください。CI 環境では、**ファイル > 書き込み**、**翻訳キュー > 有効**、**文脈 > 書き込み** の権限を持つプロジェクトの APIキーを `GT_API_KEY` に設定してください。 ## ステップ 4: 用語集とキーの文脈を移行する Lokalise の [用語集](https://docs.lokalise.com/en/articles/1400629-glossary) ページで **More > Download CSV** を選択し、すべての用語を翻訳とあわせてエクスポートします。このファイルはセミコロン区切りで、`de_DE` のように言語ごとに列が分かれています。`term` 列はそのまま残し、`description` を `definition` に、各言語列を `translation_de` のような `translation_` の形式にリネームします。その他の列は削除し、カンマ区切りで保存してください。General Translation のインポーターはこのレイアウトをそのまま読み込めます。それ以外のレイアウトは AI が解釈します。ダッシュボードで [コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations) を作成し、**Import** をクリックしてファイルを選択します。最初の翻訳を実行する前にそのグループをプロジェクトに割り当てておけば、新しい翻訳に最初から自社の用語が反映されます。 キーの説明は、その文字列が何を意味するかを翻訳者に伝えるものです。iOS の `.strings` や Android の `strings.xml` のエクスポートには、デフォルトで説明がコメントとして含まれており、General Translation はそのコメントを文脈として送信します。JSON の場合は、各キーの説明と文字数制限を `lokalise2 key list` で取得するか、ソース言語の [`json_structured`](https://docs.lokalise.com/en/articles/3229161-structured-json) エクスポートを `gt.config.json` で指定したフォルダの外に保存して取得します。取得した内容は、ソースファイルと同じ場所に置いた [キーごとのメタデータ](/docs/cli/reference/keyed-metadata) ファイルに書き込みます: ```json title="locales/en/common.metadata.json" { "checkout": { "save": { "context": "Button that saves the shipping address", "maxChars": 12 } } } ``` Pro AI のスタイルガイドは、[カスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations)として作成し直してください。ご利用のプランに翻訳メモリ管理が含まれている場合は、チームの管理者が **Team settings > Translation memory** の **Download as TMX file** からアーカイブを保存できます。 ## ステップ 5: 翻訳の前にアップロードする まず [`npx gt upload`](/docs/cli/reference/commands/upload) を実行します。このコマンドは、各ソースファイルと、それに対応する各ロケールの翻訳済みファイルを送信し、それらの翻訳を完了済みとして保存します。 ```bash npx gt upload npx gt translate ``` その後、[`npx gt translate`](/docs/cli/reference/commands/translate) は新しいロケールや未翻訳のファイルなど、不足している部分だけを翻訳し、結果を同じパスに書き込みます。[`npx gt upload`](/docs/cli/reference/commands/upload) より先に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行すると、新たに生成された翻訳でエクスポート済みのファイルが上書きされてしまいます。Lokalise で未翻訳だったキーは、そのソースファイルが次に変更された時点で General Translation が翻訳します。それより早くリリースしたい場合は、エクスポートする前に Lokalise で翻訳を済ませておいてください。 ## ステップ 6: 新しいテキストを自動で翻訳する 今後は、[ビルドまたは CI](/kb/translations-in-ci) で [`npx gt translate`](/docs/cli/reference/commands/translate) を実行するか、[Locadex](/docs/platform/locadex/quickstart) に翻訳を含むプルリクエストを作成させましょう。`gt-lock.json` もコミットしてください。このファイルには CLI が書き込み済みの翻訳が記録されるため、同じ翻訳を再度ダウンロードせずに済みます。チームがリポジトリ内の翻訳済みファイルを直接編集する場合は、次回の翻訳の前に [`npx gt save-local`](/docs/cli/reference/commands/save-local) を実行してください。これにより、編集内容が上書きされずに保持されます。 ## Lokaliseを使い続けるべきなのはどのような場合ですか？ ネイティブモバイルアプリでOTA (over-the-air) による文字列更新が欠かせない場合、デザイナーがFigmaプラグインやスクリーンショットをもとに作業している場合、同じツール内でプロの翻訳を発注している場合、またはパイプラインでXLIFFやARBファイルをやり取りしている場合は、Lokaliseを使い続けることをおすすめします。 ([General Translation と Lokalise の比較](/kb/general-translation-vs-lokalise)を参照してください。) ## よくある質問 ### レビュー済みの翻訳は失われますか？ いいえ。エクスポート時に空の翻訳をスキップし、[`npx gt translate`](/docs/cli/reference/commands/translate) の前に [`npx gt upload`](/docs/cli/reference/commands/upload) を実行すれば、失われることはありません。アップロードした翻訳は、原文が変更されない限りそのまま保持されます。また、どの翻訳も[ダッシュボード](/docs/platform/dashboard/guides/reviewing-translations)からチームで修正できます。 ### スクリーンショットはどうなりますか？ スクリーンショットは Lokalise に残ったままになります。スクリーンショットで翻訳者に伝えていた情報を引き継ぐには、各文字列が表示される場所をキーごとの文脈に記述してください (ステップ 4) 。 ## 重要なポイント * `--export-empty-as skip` を指定して言語・プラットフォームごとに1ファイルずつエクスポートし、アプリが現在読み込んでいる複数形の形式に揃えます。 * General Translation が同じファイルに書き込む前に、Lokalise の Webhook、トリガー、Actions を削除しておきます。 * 翻訳を始める前に、用語集をコンテキストグループにインポートし、キーの説明をキーごとの文脈として移行します。 * 最初に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行する前に [`npx gt upload`](/docs/cli/reference/commands/upload) を実行し、以降はビルド時または Locadex で新しいテキストを翻訳します。 ## Related questions - [Lokalise の代替ツール：General Translation と Lokalise の比較](https://generaltranslation.com/ja/kb/general-translation-vs-lokalise.mdx): General Translation は、JSX 内に読みやすいコピーをそのまま記述し、翻訳を開発プロセスに組み込みたいチームにとって、Lokalise の有力な代替手段です。Lokalise は、共有キー、デザインツールとの連携、モバイル向けの OTA（Over-the-Air）配信を軸に設計されています。General Translation は、アプリ内でマークされたコンテンツから翻訳を生成し、ダッシュボード または GitHub のプルリクエスト上でのレビューに対応しています。 - [CrowdinからGeneral Translationに移行するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/migrate-from-crowdin.mdx): リソースファイル、i18nライブラリ、レビュー済みの翻訳はそのまま引き継げます。「Skip untranslated strings」を有効にして翻訳をダウンロードし、CrowdinのGitインテグレーションによる翻訳のプッシュを止めたうえで、最初に npx gt translate を実行する前に npx gt upload でファイルをインポートします。以降はGeneral Translationがビルド時に新規・変更された文字列を翻訳し、その際にはコンテキストグループの用語集が適用されます。 - [PhraseからGeneral Translationに移行するには？](https://generaltranslation.com/ja/kb/migrate-from-phrase.mdx): ロケールファイル、i18nライブラリ、検証済みの翻訳はそのまま引き継げます。未翻訳のキーやフォールバックを含めずにPhrase Stringsからプルし、Repo Syncを無効化したうえで、最初のnpx gt translateを実行する前にnpx gt uploadでファイルをインポートします。以降はGeneral Translationがビルド時に新規・変更された文字列を翻訳します。用語ベースはコンテキストグループとして、キーの説明はキーごとの文脈として活用されます。 - [デプロイのたびに翻訳を最新の状態に保つにはどうすればよいですか？](https://generaltranslation.com/ja/kb/translations-in-ci.mdx): 本番環境のビルド前に、翻訳をパイプラインのステップとして毎回実行します。こうすることで、新しいテキストは追加されたデプロイと同時に翻訳済みの状態でリリースされます。General Translation の gt CLI では、CI シークレットとして保存したプロジェクトの APIキーとプロジェクトIDを使い、npx gt translate でこれを実現します。 - [翻訳メモリとは？AI時代にもまだ必要なのか](https://generaltranslation.com/ja/kb/what-is-translation-memory.mdx): 翻訳メモリ（TM）は、過去の翻訳元と訳文のセグメントのペアを蓄積したデータベースで、翻訳ツールはこれを検索して完全一致、文脈一致、ファジーマッチを見つけます。AIを使う場合でも、承認済みの訳語を再利用し、過去の翻訳を文脈として参照できるようにしておくことは重要です。General Translation は、ファイルの以前のバージョンからマッチする翻訳を再利用し、チームによる編集も保持するため、TM を別途管理する必要はありません。 ## Previous and next questions - Previous question: [CrowdinからGeneral Translationに移行するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/migrate-from-crowdin.mdx) - Next question: [PhraseからGeneral Translationに移行するには？](https://generaltranslation.com/ja/kb/migrate-from-phrase.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.