問題タブ [pseudolocalization]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
windows - テストのためにWindowsで疑似ロケールを有効にする方法は?
Windows Vista では、次の 3 つの疑似ロケールの概念が導入されました。
アプリケーションが日付、時刻、数字、金額などの項目の書式設定に現在のロケールを使用していることを確認できるため、ベースロケールを有効にすると便利です。
たとえば、現在のロケールがBaseに設定されている場合、日付は次のようにフォーマットされます。
[Шěđлеśđαỳ !!!]、2006 年の [Μäŕς !!] の 8
Windowsのビルドは実際には pseudoで行われ、英語にローカライズされます。
グローバル市場向けの Windows 7 のエンジニアリング
疑似ローカリゼーション
一般的なグローバリゼーションのバグを防ぐために、疑似ローカライズされたビルドが作成されました。疑似ローカリゼーションは、ローカライズされた製品を人工言語で作成するプロセスです。その言語は、視覚的に英語の文字に似た異なる文字で各文字が書かれていることを除いて、英語と同じです。完全に機械で生成されることを除いて、ローカライズされたビルドを作成するのとまったく同じ方法で疑似ローカライズされたビルドを作成します。米国の単一言語のソフトウェア開発者でさえ、疑似ローカライズされたテキストを読むことができるため、開発サイクルの早い段階でグローバリゼーションの問題を発見する優れた方法であることが証明されています。Windows 7 ベータ版では、一部の UI 要素がまだ擬似的にローカライズされていたため、その意味についていくつかの興味深い理論が生まれました。このブログ投稿で謎が解けたことを願っています。:-)
疑似ローカライズされた Windows 7 のコントロール パネル ダイアログ
PRIMARYLANGID
これらのロケールの使用における別の値: アプリケーションが 16 ビットが次のもので構成されていると想定していないことをテストします。
- 8 ビットの第一言語 ID
- 8 ビットのサブ言語 ID
実際には PRIMARYLANGID は次のとおりです。
- 10 ビットの第一言語 ID
- 6 ビットのサブ言語 ID
またはグラフィカルに:
これら 3 つの疑似ロケールは、最終的に 8 番目のビットの終わりから離れます (Microsoft は、バグのあるアプリケーションを壊すためにうんざりしてきました)。
Windows で疑似ロケールを有効にするにはどうすればよいですか?
こちらもご覧ください
google-chrome - 疑似ローカリゼーション テストのためにカスタム Accept-Languages を Chrome に追加する方法は?
Web サイトの疑似ローカリゼーションをテストしています。
カスタム受け入れ言語を持つように Internet Explorer を構成できます。
- [ツール]、 [インターネット オプション] の順にクリックします。
- [全般] タブで、 [言語] をクリックします。
- [言語設定] ダイアログで [追加] をクリックします。
- ユーザー定義言語
qps-ploc
(つまり、疑似 (ベース) ロケール)を入力します。 - [ OK] をクリックします。
Internet Explorer が http 要求を発行すると、受け入れ言語は次のようになりますqpc-ploc
。
Chrome に対して同じ変更を行うにはどうすればよいですか? Firefoxに?
アップデート
また、Internet Explorerは Windows の設定を尊重することに注意してください。私の Windows は、疑似 (ベース) qps-ploc
ロケールを使用するように構成されています。デフォルトでは、Internet Explorer はこれを使用します。
Google Chromeは Windows の設定を無視し、代わりにリクエストen-US
とen
言語を決定します。
.net - .NET 日付から文字列への変換により、Vista 擬似カルチャで無効な文字列が返される
私のコンピューターは、 ではないen-US
カルチャで構成されています。
ネイティブの Win32GetDateFormat
関数を使用すると、正しくフォーマットされた日付が取得されます。
- 22//11//2011 4::42::53P̰̃M]
正解です; また、Windows がそれをレンダリングする方法でもあります。
タスクバー
地域と言語の設定
ウィンドウズ・エクスプローラ
見通し
現在のロケールを使用して.NETで日付を文字列に変換しようとすると、次のようになります。
私は間違った日付を取得します:
- 22////11////2011 4::::42::::53P̰̃M]
.NET のこのバグは、バグのある .NET コードを使用する Windows のどこでも明らかです。
Windows イベント ビューアー:
タスク スケジューラ:
SQL Server 管理スタジオ:
.NET にバグがないようにするにはどうすればよいですか?
現在のカルチャを使用して (正しく) 日付と時刻を文字列に変換するにはどうすればよいですか?
注: ユーザーは、 Windows を任意のロケール設定に設定できます。現在、私のプログラムは 有効な設定を適切に処理しません。ユーザーに「そんなことはしないでください」と言うのはかなり意地悪です。
同様の例が Delphi から来ています。Delphi では、日付区切り記号が複数の文字であってはならないことを前提としています。Windows が、日付区切り文字に複数の文字を使用するロケールで構成されている場合:
- sk-SK (スロバキア - スロバキア) :
.
日付は次のようにフォーマットする必要があります。
コード ライブラリは、1 文字を超える日付区切り記号を受け入れることができず、次のようにフォールバックします。
過去には、そのような極端なケースを気にしないようにと提案する人もいたかもしれません。そのような提案は私にとって重要ではありません。
タイトルを変更して私の質問の意味を変えようとする人との小競り合いは避けたいと思います。しかし問題は、アプリケーションのバグを見つけるために特別に設計された疑似ロケールに限定されません。
ボーナスおしゃべり
以下は、世界中の日付形式のユニークなリストです。
- 11.11.25
- 2011.11.25
- 2011/11/25
- 2011.11.25
- 2011.11.25.
- 2011/11/25
- 2011-11-25
- 2011年
- 11.11.25
- 2011.11.25
- 2011 年 11 月 25 日。
- 2011.11.25。
- 2011/11/25
- 2011年11月25日
- 2011/11/25
- 2554/11/25
- 25-11-11
- 2011 年 11 月 25 日
- 29/12/32
特に興味深いのは、グレゴリオ暦を使用しない最後の例です。
- アラビア語 (サウジアラビア)
ar-SA
: 29/12/32 02:03:07 ã - ディベヒ (モルディブ)
dv-MV
: 29/12/32 14:03:07 - Dari/Pashto (アフガニスタン)
prf-AF / ps-AF
: 29/12/32 2:03:07 غ.و
これらは、心配する必要のない特殊なケースですが。
2011 年 12 月 14 日更新:
バグの別のデモンストレーションは、Datetime.Parse
解析できないことDateTime.ToString
です:
は.Parse
例外をスローします。
更新 02//8、2012 09::56'12:
日付区切り文字の使用は、正しくないだけでなく、非推奨です。MSDN から:
LOCALE_SDATE
Windows Vista 以降:この定数は非推奨です。
LOCALE_SSHORTDATE
代わりに使用してください。カスタム ロケールには、1 つの統一された区切り文字がない場合があります。たとえば、「2006 年 12 月 31 日」などの形式が有効です。LOCALE_STIME
Windows Vista 以降:この定数は非推奨です。
LOCALE_STIMEFORMAT
代わりに使用してください。カスタム ロケールには、1 つの統一された区切り文字がない場合があります。たとえば、「03:56'23」などの形式が有効です。
resx - MSBuild AssignCulture タスクは、空のカルチャを疑似カルチャ (qps-ploc、qps-plocm) に割り当てます。
私のプロジェクトには、ローカライズされた RESX ファイルがいくつかあります。
最後の 1 つは、テスト目的で擬似的にローカライズされたテキスト リソースです。残りのローカリゼーションとしてサテライト アセンブリ (つまり、project/qps-ploc/project.resources.dll) にコンパイルしたいと思います。しかし、何らかの理由で AssignCulture タスクが空のカルチャをこのリソースに割り当てており、結果としてコンパイルされません。
MSBuild ログのスニペット:
ここ
で説明されているように、疑似ローカリゼーション カルチャがレジストリで有効になっており、new CultureInfo("qps-ploc")
正しい疑似カルチャが返されます。
これは AssignCulture の予想される動作ですか、それとも私が間違って使用しているだけですか?
visual-studio - Visual Studio で疑似言語 (qps-ploc) サテライト アセンブリをビルドする
実際の翻訳を取得する前に、ローカライズのバグをテストできるように、アプリのリソース ファイルの疑似ローカライズ バージョンを生成しました (たとえば、Order Summary and Payment
としてローカライズされます)。[[[[[Òŕd̂ër̊ S̀úm̂m̈år̀ý ân̈d̊ P̀áŷm̈e̊ǹt́]]]]]
qps-ploc リソース識別子を使用して、既存の疑似ロケール識別子と一致するように名前を付けました。たとえば、 の疑似ローカライズ版Details.resx
は という名前Details.qps-ploc.resx
です。
ただし、これらの resx ファイルをプロジェクトに追加すると、Visual Studio はそれらを無視します。「実際の」言語コード ( などDetails.fr-FR.resx
) を使用してそれらの名前を変更すると、Visual Studio はこの言語コードで名前が付けられたサブフォルダーを作成し、サテライト アセンブリをビルドします。
したがって、Visual Studio が qps-ploc を拒否するように見えます (ビルド警告さえもなしに)。何か不足していますか、またはこれらの qps-ploc リソースを Visual Studio プロジェクトの一部としてビルドする方法を提案できますか?
.net - すべてのリソース文字列を接頭辞で変更して、i18n または RTL の問題を簡単に見つける
ローカライズされていない文字列 (接頭辞が付いていない) の両方を見つけられるように、すべてのリソース文字列に「XXXSomeString」のような接頭辞を簡単に追加したい (つまり、すべての文字列に手動で触れる必要はありません)。 RTL 互換フォーム (プレフィックスは左側にあります)。
これを行うツールはありますか、またはすべての文字列値が返されるときにプレフィックスを追加するようにリソース コード ファイルを変更する方法はありますか? または、この問題に対するより良い解決策がある場合は、ぜひお聞かせください。
android - Android 4.3 の新しい疑似ローカリゼーション機能を使用するには?
Android 4.3 の新しい疑似ローカリゼーション (zz_ZZ ロケール) 機能に関するドキュメントが見つかりません。
どのように使用できますか?
ios - Xcode でのボタンのローカライズ
これはこれまでの私の最初の質問なので、理解していただければ幸いです。
アプリケーション全体をローカライズしています。疑似位置が適切に変換されるラベルに問題はありません。ただし、ボタンで同じことを達成しようとしても機能しません。
コードは
en.plistコンテンツの.stringファイルは次のようになります
疑似位置情報が機能しません。助けていただければ幸いです。シミュレーターは Clear を表示し続けます。
この件について質問があればお答えします!
私を食べないでください:P
internationalization - テスト用の自動 gettext 翻訳ジェネレーター (疑似ローカリゼーション)
現在、サイトを i18n 対応にする作業を行っています。ハードコーディングされた文字列を翻訳可能としてマークします。
サイトを閲覧して、どの文字列がマークされていて、どの文字列がまだマークされていないかをすばやく確認できる自動ツールがあるかどうか疑問に思っています。HTML 機能を使用して翻訳された文字列を強調表示しようとするdjango-i18n-helper のようなプロジェクトをいくつか見ましたが、これは JavaScript ではうまく機能しません。
だから私は、FДЦЖ CУЯILLIC、またはʇxǝʇ uʍop-ǝpısdn (またはそれらの線に沿った何か) がトリックを行うべきだと考えました。視覚的に区別しやすく、読みやすく、Unicode サポート以外のリッチ テキスト形式に依存しません。
.po
問題は、gettext / .pot
file(s) を食べてそのような翻訳を吐き出す、すぐに利用できるツールが見つからないことです。それでも、アイデアはかなり明白だと思うので、すでに何かがそこにあるに違いありません.
私の場合、Python/Django を使用していますが、この質問は gettext 互換ライブラリを使用するものすべてに当てはまると思います。ツールが注意すべき唯一のことは、翻訳文字列に HTML フラグメントが存在する可能性があるということです。