サードパーティのサービスを使用したRailsの国際化の管理
私のお気に入りのRailsコンポーネントの1つは、I18nクラスと辞書ファイル（en.yml、ru.ymlなど）を使用して国際化とローカリゼーションを整理することです。 しかし、「真空の球状のプロジェクト」ではなく、開発者のグループとリポジトリ内のブランチの束を持つ実際のアプリケーションを使用すると、ロケールファイルで何らかの形で発生するさまざまなブランチ/バージョンを組み合わせるときに競合を解決するために頭が膨れることがあります。 になる方法 ここで私たちは思い出し、さまざまなサードパーティのサービスに宝石が付属しています。
99翻訳
私が最初に会った国際化管理サービスは99Translationsでした 。これは特別なロケールファイル「master.yml」をサーバーにアップロードする機能を提供し（ファイルにはキーのみが含まれる必要があります）、そこで解析され、インストールされた他のロケールにキーを追加しました。 さらに、翻訳が必要な新しいキーに関する情報がダッシュボードに表示されました。 辞書に完全に（または部分的に）記入した後、それらをサーバーから取り出してリポジトリに簡単にコミットできます。
なぜ過去形で話しているのですか？ このサービスは2012年3月31日に忘却に陥り、実際のプロジェクトで使用するのは不適切だからです。 ここでは、例としてのみ提供します。
長所：
-プログラムの観点からの使用の単純さと明確さ、それ以上。
-1つのキーのファイルキーパー：master.ymlに追加した場合、競合なし、すべてのロケールのアプリケーションページでの国際化の存在に対する強い自信（読み取り、 'translation missing'メッセージなし）。
短所：
-複数のロケールのウェブインターフェースから同時に翻訳を入力することはできません
-ただし、Webインターフェースが過負荷になっています（不要なタブがたくさんあるため、少し冗長に思えました）。
Localeapp
LocaleAppは、その「鮮度」（まだベータ版）とRails指向ですぐに私の注目を集めました。 ダッシュボードを見て少し時間を費やしたところ、インターフェイスが直感的であり、一度に複数のロケールを入力できるため、翻訳者/クライアントの生活がはるかに楽になることがわかりました（その結果、開発者の健康と気分が向上します）。
さらに興味深いのは、アプリケーションが開発モードで起動されると、サービスによって提供されるgemが自動的にサーバーからロケールを要求し（要求ごとにこれを行うため、アプリケーションがある程度遅くなります）、レンダリングプロセス中に欠落しているキーを追跡します それらが見つかった場合、彼はそれらが辞書に追加されていることを確認します。 便利ですね。 ダッシュボードに行くと、各ロケールがどれだけいっぱいになっていて、何を追加する必要があるかがわかります。
長所：
-複数のロケールを同時に満たす機能。
-リクエストごとに最新の国際化を自動的にダウンロードします。
-ローカライズファイルに不明なキーを自動的に追加します。
-見栄えの良いインターフェース。
-優れたスタートアップ：Webインターフェースを介してプロジェクトに新しいロケールを追加すると、すべての標準キー（月、日、日付と時刻の形式など）が既に翻訳されています。
-無料プレイベータ版：必要かどうかを試して理解する機会があります。
短所：
-バックグラウンドプロセスは開発者を困らせ、アプリケーションの速度を低下させます（しかし、幸いなことに、それらは簡単に無効にされます-gemのドキュメントを参照してください）。
-時々、翻訳の欠落の要求がscope：I18n.t（ 'key' ,: scope =>：some_scope）で正しく機能せず、間違った名前空間に自動的に追加されます（ 'key'はグローバルキーとして追加されます）。 さて、ベータ版はベータ版です。 これが修正されることを願っています。
-サーバーに任意の辞書ファイルをアップロードできるという事実により、長く削除されたキーは時々「復活」し始めます。 したがって、Webインターフェースを介してこれを行うことをお勧めします。
PSこのようなサービスの主なプラスは、すべてのブランチとすべての開発者が同じロケールファイルを持ち、ブランチ/バージョンを結合するときに、1つまたは別の言語への翻訳の機能ではなく、プログラムコードの比較に集中できることです（ただし、これは一部の人に見えるかもしれません）マイナス）。 また重要
翻訳者をリポジトリやソースから遠ざけるという事実ですが、それらは順番にロケールの支配者です。
更新：略語を削除しました。