私はあなたの製品がこれらの特定の国で使用されることを事前に知っていれば、人々はリソースバンドルのアプローチに行くべきです。しかし、私たちの製品が将来どのくらい多くの国で発売されるかを考えていない場合は、Googleが提供するような翻訳APIを用意してみませんか？新しい国で製品を立ち上げる予定の場合、リソースバンドルのアプローチでは、テキストファイルの各ラベルのエントリを作成する必要があります。しかし、この翻訳手法では、サーバーの起動時に翻訳apiを使用してファイルを作成して、ランタイム変換を保存することができます。私は今のところこれをやっているプロジェクトは見ていませんが。これについての考えは？リソースバンドルアプローチの代わりに変換APIを使用してみませんか？
主な理由の1つ自動翻訳を使用すると、アプリを「翻訳」したくない場合は、実際には「localize」にします。
あなたがただ翻訳したいと思っても、結果には文脈が必要な意味があります。そうでなければ、ユーザがあなたのシステムと思うような奇妙なテキストを持つメニュー/ UI要素になります彼らは翻訳されたバージョンを悪用したり、システム全体を悪化させたりすることをやめるでしょう。
Google Transliteration APIを使用しない理由の1つは、deprecatedです。新しいプロジェクトで廃止予定のAPIを使用しても、特に賢明な動きではありません。
翻訳APIは有用ではあるものの、リソースバンドルの「人間が生成した」コンテンツができるアプリケーションのコンテキストを提供することはできません。
申し訳ありませんがポイントを取得しないためのradimpe。 –
"Venetian Blind" - あなたの窓を覆うもの、または "ヴェネツィアの盲人"を指しますか？ – radimpe
+1また、非推奨になっていない場合でも、将来信頼性の問題や消滅する可能性のある外部サービスへの依存は、お客様の製品にとって危険です。 – mikera
それは有効な点です。しかし、GoogleのAPIは単なる例です。私の主なポイントは、javaが将来的に翻字APIを思い付くかどうかです。リソースバンドルでそれを好むべきかどうか？ –