PO ファイルを翻訳者と交換し、i18next のネイティブ JSON 形式に変換したいと考えています。i18next-conv ユーティリティを使用すると、これは非常に簡単に思えます。
ただし、i18next は多かれ少なかれ特殊キーを想定しています。たとえば、ドットは i18next 名前空間に関して特別な意味を持ちます。対照的に、gettext PO ファイルは、メッセージ IDのソース文字列を (元の言語で) 運ぶことを目的としています。
メッセージ ID は任意であり、したがって i18next キーに直接マップできることはわかっていますが、ソース文字列を使用し、さまざまな理由で意図された PO ファイルを使用したいと考えています。
主な理由は、私たちが使用したいすべての翻訳ツール、そしておそらくすべての翻訳者がこれを期待しているためです。シンボリック キーを使用すると、翻訳が本当に面倒になります。いずれにせよ、これに関する議論から、これは主に意見の問題であることがわかりました。この制限をこの質問の要件として設定したいと思います。
- 技術的な観点から、ソース文字列を i18next キーとして使用するのは本当に悪い考えですか? それらから逃れるのはどれくらい難しいですか?ドットと名前空間以外に注意すべきことはありますか?
- シンボリック キーを使い続けたいと判断した場合、ソース文字列をメッセージ ID として使用して PO ファイルから i18next JSON 翻訳ファイルを生成できる i18next-conv の代替手段はありますか? シンボリック名と元の言語文字列の間で別のマッピングを維持する必要がある可能性が高いことを理解しており、そうする準備ができています。
さらに、一般的なワークフローについても疑問に思います。元の PO ファイルはどのように生成されますか? 翻訳ファイルはどのように維持されますか?
- i18next でソース文字列をキーとして使用する場合、コードベースから文字列を抽出するのに最適なツールは何ですか? xgettext は Javascript をサポートしていないようです。
- i18next でシンボリック キーを使用する場合、元の PO ファイルを生成するにはどうすればよいでしょうか? 手動で POT ファイルを作成することは良い習慣ですか?
- 繰り返しになりますが、シンボリック キーを使用する場合、元の言語文字列を更新するたびに翻訳を簡単に無効にするにはどうすればよいでしょうか? そのためのツールはありますか?
これらの質問が非常に基本的なものであることは理解していますが、i18next-gettext の統合に関する情報がほとんど見つからないことに少し驚きました。i18next-conv ツールが存在し、宣伝どおりに完全に機能しますが、実際に役立つのでしょうか? 人々は実際にそれを使用していますか?もしそうなら、私たちの質問は関連していますか?
最後に、システムの成熟度に対する私たちの期待は少し高すぎるのでしょうか?