1

Pyramid は翻訳に gettext *.po ファイルを使用します。これは、アプリケーションを国際化するための非常に優れた安定した方法です。1 つの欠点は、アプリ自体から変更できないことです。通常のユーザーが自分で翻訳を変更できるようにする方法が必要です。Djangoはファイルを直接変更することを許可し、変更後にアプリ全体を再起動します。変更は頻繁に行われるため、私にはその自由がありません。

このタスクに役立つパッケージが見つからなかったため、Localizerをオーバーライドすることにしました。私のアイデアは、 ZopeプロジェクトがLocalizerで登録済みドメインを検索し、見つからない場合はデフォルトの翻訳戦略に戻るように、翻訳ドメインを使用することに基づいています。

問題は、ローカライザー自体にカスタム翻訳ソリューションを配置する良い方法が見つからなかったことです。私が考えることができるのは、get_localizerメソッドを再実装し、 Localizer全体を書き直すことだけです。ただし、マッピングの補間や翻訳文字列に関連するその他の微調整など、ここにコピーペーストする必要があるものがいくつかあります。

4

1 に答える 1

0

そこにどれだけのものが入っているかわかりませんが、私は少し前に同じようなことをしました..もう一度やらなければなりません. 実装は非常に簡単です...

すべての呼び出しが _() または同様のものを介して処理されることが確実な場合。独自の機能を提供できます。それはそれのように見えます。

def _(val):
    val = db.translations.find({key: id, locale: request.locale_name})
    if val:
        return val['value']
    else:
        return real_gettext(val)

これは非常に簡単です...次に、データベースをファイルにダンプするものが必要です...

しかし、ローカライザーをオーバーライドする方が理にかなっていると思います..私はずっと前にそれを行いましたが、関数をオーバーライドすることは、コードを検索するよりも簡単でした.

Localiser のプラス面は、どこでも機能することです。モンキーパッチはかっこいいけど醜い。もう一度やり直す必要がある場合は、最初にデータベースからロードしてから独自の値を表示する独自のローカライザーを提供します。データベースの背後にある理由は、誰かがサーバーを閉じてファイルが変更されていない場合、結果が表示されないためです。

DB が必要以上に多い場合は、Localize で十分であり、更新のたびにファイルを更新できます。サーバーが再起動されると、新しいファイルがロードされます...最初にカタログをコンパイルする必要があります。

于 2012-04-21T22:01:16.953 に答える