<%= t(".unread", count: @count) %>
``` スペイン語を選択しても、このファイルが翻訳されるわけではありません。英語へのフォールバックが有効になっていれば、スペイン語の読者にも "Inbox" や "You have 3 unread messages." がそのまま表示されます。Rails でスペイン語の文言を表示するには、まずスペイン語のカタログを用意する必要があります。英語のメッセージを追加・編集するたびに、言語ごとに同じ作業が発生します。 [rails-i18n](https://github.com/svenfuchs/rails-i18n) gem は、ロケールごとの書式と複数形規則を提供します。[i18n-tasks](/kb/general-translation-vs-i18n-tasks) は、キーや複数形の抜け漏れをチェックします。そして General Translation は、これらのツールが使用する翻訳済みメッセージを提供します。 ## General TranslationでRailsのロケールファイルを翻訳する キーの参照にはRails I18nをそのまま使い、他のロケールファイルの作成はGeneral Translationに任せましょう。`gt` CLIはNode.js上で動作し、キーを保持したままYAMLを翻訳します。この英語からスペイン語への例では、外側の`en:`キーを除いた形でメッセージを`translations/en.yml`に記述します。 ```yaml title="translations/en.yml" inbox: show: title: "Inbox" unread: one: "You have %{count} unread message." other: "You have %{count} unread messages." ``` `gt.config.json` でこれらの作業用ファイルを参照するよう設定します。簡単なエクスポート処理で Rails のロケールキーを追加し、アプリが読み込むカタログを書き出します： ```json title="gt.config.json" { "defaultLocale": "en", "locales": [ "es" ], "files": { "yaml": { "include": [ "translations/[locale].yml" ] } } } ``` [翻訳の生成](/docs/cli/guides/generating-translations)の説明に従って、`GT_PROJECT_ID` と `GT_API_KEY` を設定します。このカタログの既存の翻訳がある場合は、`es:` ルートを除いた形で `translations/es.yml` に配置し、新しい翻訳を生成する前に [`npx gt upload`](/docs/cli/reference/commands/upload) を実行してください。 ```ruby title="script/export_rails_locales.rb" require "json" require "yaml" require "fileutils" config = JSON.parse(File.read("gt.config.json")) locales = ([config.fetch("defaultLocale")] + config.fetch("locales")).uniq catalogs = locales.to_h do |locale| messages = YAML.safe_load_file("translations/#{locale}.yml", aliases: true) raise "Expected a message map for #{locale}" unless messages.is_a?(Hash) [locale, { locale => messages }.to_yaml] end FileUtils.mkdir_p("config/locales") catalogs.each do |locale, catalog| File.write("config/locales/#{locale}.yml", catalog) end ``` ```bash npx gt translate && ruby script/export_rails_locales.rb ``` エクスポートを実行すると、このカタログの `config/locales/en.yml` と `config/locales/es.yml` が書き出されます。編集は引き続き `translations/` 内の作業ファイルで行ってください。アプリが読み込むのはエクスポートされたコピーです。次回の翻訳実行の前に、[`npx gt save-local`](/docs/cli/reference/commands/save-local) でローカル翻訳の編集内容を同期してください。 General Translation はプロジェクトの[用語集とカスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations)を適用して各ファイルを翻訳するため、製品名やフォーマルな口調がすべてのロケールファイルで統一されます。また、チームはダッシュボードで[翻訳をレビュー・編集](/docs/platform/dashboard/guides/reviewing-translations)できます。変更のないエントリには以前の翻訳が再利用されるため、マージのたびに CI で CLI を実行しても、翻訳されるのは変更された部分だけです。 リリース前に `i18n-tasks missing` と `i18n-tasks check-consistent-interpolations` を実行し、エクスポートされたカタログのキー、複数形、`%{count}` プレースホルダーを確認してください。 ## Rails I18n と General Translation の比較 | 機能 | Rails I18n | General Translation | | -------------------- | ----------------------------------------- | --------------------------------------------------------------------------------- | | 概要 | 翻訳の検索と書式設定を行う Ruby ライブラリ | CLI、JavaScript および Python 向けライブラリ、ダッシュボードを備えた翻訳プラットフォーム | | Rails アプリでの翻訳のレンダリング | 対応 (ビュー、コントローラー、メーラー) | 既存の Rails I18n の呼び出しで使うカタログを提供 | | 翻訳の作成 | 非対応 | 対応 ([`npx gt translate`](/docs/cli/reference/commands/translate) で YAML ファイルを生成) | | 複数形規則 | デフォルトは英語の規則。rails-i18n を導入すると CLDR の規則に対応 | 設定された翻訳元の形式を翻訳し、ランタイムで Rails が選択 | | ファイル間の一貫性 | 翻訳者次第 | 用語集とカスタムプロンプトをすべてのファイルに適用 | | レビュー | 既存のプルリクエストのフロー | ダッシュボードと既存のプルリクエストのフロー | | 費用 | 無料 (MIT) | [従量課金](https://generaltranslation.com/pricing) | 翻訳者やベンダーからすでにロケールファイルが納品されている場合や、対応言語が 1〜2 つで手作業で編集している場合は、Rails I18n 単体で十分です。英語のコンテンツが頻繁に変わり、翻訳の往復を待たずに、用語の一貫性を保ったまますべてのロケールファイルを CI で再生成したい場合は、General Translation を導入しましょう。 ## 重要なポイント * Rails I18n は `config/locales` にある翻訳をレンダリングし、日付や数値の書式設定を行います。rails-i18n は複数形規則とロケールデータを追加します。ただし、どちらも翻訳自体を作成するものではありません。 * General Translation は、用語集とカスタムプロンプトに基づいて YAML を翻訳し、英語の原文が変更されても翻訳を常に最新の状態に保ちます。 * 編集用のカタログは `translations/` で管理し、[`npx gt translate`](/docs/cli/reference/commands/translate) の実行後に Rails のロケールルートへエクスポートします。 ## Related questions - [General Translation と i18n-tasks：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-tasks.mdx): i18n-tasks は、Rails I18n の不足キーや未使用キーを検出し、ロケールファイルを整理し、Google Translate、DeepL、OpenAI、Yandex、watsonx を使って不足キーを補完できる Ruby gem です。General Translation は、用語集、カスタムプロンプト、ダッシュボードでのレビューを活用してロケールファイル全体を翻訳します。両者は役割が異なるため、多くのチームにとっては併用も有効です。 - [General Translation と Mobility：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-mobility.mdx): Mobility は翻訳済みのモデル属性をデータベースに保存します。General Translation は、用語集とカスタムプロンプトを活用し、API を通じてそれらの翻訳を生成します。両者を組み合わせれば、Rails モデルをそのまま維持しながら、商品リストや投稿などのデータベースコンテンツを翻訳できます。 - [General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。 - [TMS（Smartling、Lokalise、Phrase、Crowdin、Transifex）ではなく General Translation を使う理由](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): Smartling、Lokalise、Phrase、Crowdin、Transifex などの翻訳管理システム（TMS）は翻訳者間の作業を取りまとめますが、文字列の抽出、送信、翻訳待ち、プロダクトへの再組み込みは依然としてエンジニアの仕事です。General Translation はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。 - [開発者にとって最適なローカライゼーションソフトウェアとは？](https://generaltranslation.com/ja/kb/best-localization-software.mdx): ライブラリ、翻訳管理システム、翻訳ベンダーを個別に組み合わせるのではなく、コード内のi18nライブラリから翻訳、配信まで、パイプライン全体を1つでカバーできるシステムを選びましょう。 ## Previous and next questions - Previous question: [General Translation と Paraglide JS：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-paraglide.mdx) - Next question: [General Translation と Symfony Translation の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-symfony-translation.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.