5

Django の i18n 機能 (ugettext など) を内部的に使用して一部の出力に翻訳を提供する Django ベースの API レイヤーがあります。この API は、jQuery の Globalize と CLDN/メッセージ ファイルなどを介した独自のメッセージング機能を利用する単一ページの Javascript アプリケーションにフィードします。

現時点では、UI 用に独自に生成した言語ファイルを、Globalize のメッセージ モジュール用の JSON ファイルの形式で作成しています。
理想的には、翻訳可能なすべてのテキストを 1 つの場所から動かしたいと考えています。私は Django を翻訳可能な言語の信頼できる唯一の情報源として使用したいと考えていました (翻訳を容易にする方法として Rosetta を使用できるため)。ただし、この 2 つをどのように連携させるかはそれほど簡単ではありません。他の開発者との将来の混乱を防ぐために、既に存在する可能性のある独自の規則を発明することは避けようとしています。

まず、一部のテキスト ブロックは数単語よりも大きいです。Djangoのugettextを使用して、翻訳または表示するテキストを引数として提供することが期待されています.キーだけを提供し、翻訳が存在することを要求するのは良い慣習ですか?

第二に、この種のユースケースに対して確立された規則はありますか?
このシナリオで規範が理にかなっている場合、車輪を再発明したり、規範から逸脱したりしたくありません。

3 つ目は、どちらかを選択する必要があるかどうかです。または、翻訳を Django/API ワールド内に置き、UI から要求されたときに Globalize/messages 形式に出力できますか? または、Django が提供する Javascript の gettext 実装を使用する必要がありますか?

ありがとう

4

1 に答える 1

2

Django の JS 国際化は非常に強力で、すべての優れたプラクティスが付属しています。あなたは言った、車輪を再発明しない方が良い.

私の意見では、あなたの同僚が Django の使用に慣れている場合、彼らはこの移行を歓迎するでしょう。

私は専門家ではありませんが、Django の i18n はブロックごとに複数の単語を管理でき、段落を提供できます。.poファイルは次のようになります。

msgid ""                                                                                                                                                                  
"Lorem ipsum dolor sit amet, consectetur adipiscing elit."
" Duis ut lacus nec lacus rhoncus luctus."
" Donec luctus fringilla massa, eu accumsan odio vestibulum fermentum."
" Fusce arcu urna, tincidunt id turpis sed, rutrum lobortis sem." 
msgstr ""
"Translation goes here, and it can be on multiple lines"
于 2016-05-06T21:06:14.600 に答える