問題タブ [jquery-globalize]

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 実装を使用する必要がありますか?

ありがとう

有効な ICU メッセージをフォーマットしようとした場合

「あなたのオープン チケット数は {n, number} です」

jquery/globalize は例外をスローします: fmt が定義されていません(…)

メッセージは globalize-compiler でエラーなしでコンパイルされますが、実行時に失敗します。

jquery/globalize 1.0.0 & 1.1.1 を使用する
と、次のような問題が発生します: github.com/jquery/globalize/issues/563

jquery/globalize ... globalize/message.js ソース ファイルを変更すると (customFormatters という単語を追加すると)、エラーが削除されます... しかし、サード パーティのソース ファイルを変更することは、プロジェクトでは受け入れられません。

以下の npm パッケージも、メッセージのフォーマットを期待どおりに処理します。 https://www.npmjs.com/package/format-message

(jquery/globalize の Rafael に PM を依頼しましたが、彼はここに質問を投稿するように要求しました)

質問：

1. 他の誰かがこれに遭遇しましたか?あなたの回避策は何ですか?

2. ベース番号/日付/単位/などのフォーマッタにjquery/globalizeを使用し、メッセージのフォーマットに「format-message」などの別のライブラリを使用している人はいますか?

3. これが使用されるプロジェクトは、nodejs およびブラウザー ベース (spa) です。Intl と polyfill に切り替えることは、有効な代替手段になります。(Safari のサポートが必要ですhttp://caniuse.com/#search=intl )

4. PR を介して「customFormatters」をソースに追加するパフォーマンス コストを評価するテストはありますか。

9,999.99英語のローカル (en-CA) では Globalize が行われるのに9 999,99、フランス語のローカル (fr-CA) では行われないのはなぜですか。このシナリオでは、スペースが問題の原因ですか?

これは、numberParser メソッドを呼び出したときに発生します。入力すると NaN が返さ9 999,99れますが、フォーマッタがそれを返すため、それを受け入れる必要があります。

グローバル化フォーマット d について混乱しています。

の使用法は何ですかGlobalize.format(new Date(), 'd')。

月/日/年のラベル形式で現在の日付を返します。

Globalize.js は i18next.js よりも優れた機能を提供しますか? i18next.js を使用してきましたが、2 つのテクノロジの比較が見つかりません。どちらか一方に利点はありますか？それとも、これは jQuery の名前で販売されている別の jQuery プロジェクトですか?

この記事を使用して、.Net MVC プロジェクトのローカル番号を使用した Globalize エラーを使用して、Asp Mvc アプリケーションに Globalize の新しいバージョンをインストールしました。

だから _Layout.cshtml にこのコードを追加しました

しかし、サーバーにデプロイすると機能しません。

Ps: これを web.config に追加しました

助けてください。

jQuery Globalize 1.1.1 で負数の解析に問題があります。

したがって、Globalize は負の数を正の数に変換しているようです。次の CLDR データがロードされます。

• 補足/可能性のあるサブタグ
• 補足/時間データ
• 補足/週データ
• 補足/番号付けシステム
• メイン/SV/数字
• メイン/sv/timeZoneNames
• main/sv/ca-gregorian

Google検索でこれに関するものを見つけることができませんでした。何か不足していますか？

Web アプリケーションでjquery/globalizeを使用し、 JSON 形式のCLDR 29データを問題なく使用しています。つい最近、Unicode は CLDR 30 をリリースしました (そしてその直後に、いくつかの修正を加えたバージョン 30.0.1 がリリースされました)。

CLDR 30(.0.1) データにアップグレードすると、多くのカルチャで numbers.json の「currencySpacing」情報がなくなるため、クライアント側の通貨形式テストが失敗します。たとえば、カルチャが ar-AE であるとすると、Globalize ライブラリは次のパスで CLDR データを読み込もうとします...

/main/ar-AE/numbers/currencyFormats-numberSystem-arab/currencySpacing/beforeCurrency

...これは、この (および他の多くの) カルチャの最新の CLDR 30 numbers.json データには存在しません。

この問題の原因を突き止めるために、スタックを調べてみました。私たちはDTDから始めました。CLDR 30のDTD (CLDR 29 の DTD とともに) には次の行が含まれています...

...これは、 currencySpacing がオプションの要素であることを意味します。とはいえ、 CLDR 30 リリース ノートまたはデルタには、この情報が多数のカルチャで変更されたことを示唆するものは見つかりません。

XML データ (「グラウンド トゥルース」) では、currencySpacing要素が CLDR 29 と CLDR 30 の両方の main/root.xml でのみ使用されていることがわかります。つまり、XML でこの点に関して大きな変更はないようです。

これは、XML データから JSON データを生成するツールに問題があるのではないかと思われます。このツールはcldr-jsonプロジェクトldml2jsonによって呼び出され、使用されます。cldr-json プロジェクトのバグを除外するために、ツールを自分で構築し、JSON データを自分で生成しました。この生成されたデータには、numbers.json ファイルの「currencySpacing」情報もありませんでした。そのため、cldr-json プロジェクトの問題ではないようです。

正しく理解できれば、これは問題が次のいずれかにあることを意味します。

• ldml2json ツールにバグがある
• jquery/globalize は、この情報が常に存在すると仮定するのは正しくありません

後者が当てはまる場合、これは jquery/globalize のバグとして提起されるべきだと思います。前者を調査するには、おそらくソースからデバッグする必要があります。どちらかに時間を費やす前に、次の質問をしたいと思います:他の誰かがこの問題を見ていますか? また、既知の解決策はありますか? CLDR+JSON+Globalize スタックの経験が豊富で、私たちを助けてくれる人がいることを願っています!

私は非常に基本的なシナリオを持っています:

私のモデルでは：

(ここまで注釈なし)

私からしてみれば：

同じページの私の JavaScript コードでは:

ページのロード時にエラーが発生しないため、グローバライズの初期化が成功したと推測します

さて、問題は (nl-BE カルチャを使用する場合) です。

• クライアント側の検証では、1.23 と 1,23 の両方が受け入れられます。
• nl-BE カルチャに従って、1,23 のみを受け入れる必要があります。
• サーバー側の検証 (.NET) は期待どおりに機能し、1.23 を拒否します。

注釈を追加する必要がありますか? デフォルトでは、基本的な検証に注釈は必要ないと思います。

JQuery.Globalize検証に何か問題がありますか? (0.x バージョンの方がはるかに使いやすかったと言わざるを得ません。CLDR データを含むこの 1.x バージョンは、npm や bower を使用せずに nuget のみを使用する場合は非常に複雑です)

明確にするために、これらは私の期待ですが、期待しすぎているかもしれません

• ユーザーは異なるカルチャを切り替えることができます。これらの文化の中には、PI に 3.14 を期待するものもあれば、PI に 3.14 を期待するものもあります。
• 「。」が存在する文化では。クライアント側の検証で「3.14」のみを受け入れ、「3,14」が入力されたときにエラーを表示するようにします。
• 「,」が小数点記号であるカルチャでは、クライアント側の検証で「3,14」のみを受け入れ、「3.14」が入力されたときにエラーを表示するようにします。
• このようにして、クライアント側とサーバー側の検証が同期されます。
• どういうわけか、私は JQuery.Globalize が私のためにこれを行うことを期待していました。
• 現時点では、クライアント側の検証は両方を受け入れますが、サーバー側の検証は正しい方のみを受け入れます。

どうすればこれを解決できますか?

私のプロジェクトでは、Globalize 1.1.1を使用しています。

このパス「dates/calendars/gregorian/days」で平日のグローバル化が行われていますが、特定の日を取得する方法がわかりません。

「Tuesday」の Globalize を取得したいのと同様に、フィールドは「thu」と呼ばれます。

だから私の質問は、どうすればいいですか？

私が試した：

• Globalize.dateParser({ raw: "平日/ワイド" })( "木" )
• Globalize.formatUnit(1, "days", { form: "wide" })
• Globalize.formatMessage("/dates/calendars/gregorian/days/wide/thu")