タグ付けされた質問 「internationalization」

近い将来、すべてのコンテンツの国際的なローカライズを必要とする.NET MVCアプリケーション用のUIを開発しています。私は一般的に.NETに非常に精通していますが、国際的なアクセシビリティにそのような重要な焦点を当てる必要のあるプロジェクトは一度もありませんでした。 投影は最初は英語で行われています。将来ローカライズを実装しやすくするために、この時点でどのような対策を講じる必要がありますか？

121 .net  localization  internationalization  multilingual 

フロントエンドアプリケーションで番号をローカライズする際に注意する必要があるのはどの警告ですか？ 例：ブラジルポルトガル語（pt-BR）では、ドットで千を分割し、コンマで小数を分割します。米国英語（en-US）ではそれは逆です。pt-BRでは、en-USと同様に、桁で区切られた桁が表示されます。しかし、今日、インド英語（en-IN）について読んで、この宝石に出会いました。 インドの番号付けシステムは、数字のグループ化に適しています。言葉で書かれたとき、または話されたとき、100,000 / 100 000未満の数字は、標準英語と同じように表現されます。100,000 / 100,000以上の数字は、インドのナンバリングシステムのサブセットで表されます。 https://en.wikipedia.org/wiki/Indian_English#Numbering_system つまり： 1000000 units in pt-BR are formatted 1.000.000 1000000 units in en-US are formatted 1,000,000 1000000 units in en-IN are formatted 10,00,000 コンマとドット、およびその他の特定の区切り記号に加えて、マスキングも有効な懸念事項のようです。 フロントエンドアプリケーションで番号をローカライズする際に注意すべき他の注意事項はありますか？特に非ラテン文字セットに数字を表示している場合はどうなりますか？

38 internationalization  localization  culture  information-presentation 

このページを読んだばかりですhttp://weblogs.asp.net/scottgu/archive/2010/06/10/jquery-globalization-plugin-from-microsoft.aspx 彼らがしたことの1つは、アラビア語の日付をアラビア語のカレンダーに変換することでした。そうするのは良い考えかどうか疑問に思っています。（ユーザーがアラビア語であっても）ユーザーにとって実際に迷惑/混乱するでしょうか。 また、2番目の質問は、ドイツ語などの一部の文化では33,899.99を33.899,99に変更する必要があるのか​​ということです。ライブラリがすでにそれを行っているので、そうすることは害になりませんが、これは実際にユーザーにもっと混乱を引き起こさないでしょう（たとえ彼がドイツ人であっても）。 私はこれらの人々がどのような文化から来たにせよ、33,899.99の数字を与えたとしても、あなたが間違ったことをする方法はないでしょうか？（私のウェブサイト/アプリケーションがあなたがあなたの人生でこれまでに使った最初のウェブサイト/アプリケーションでない限り、おそらくそれは可能ですが、確率はそれだけです） 私は、誰もがそれが何を意味するのかを見て、知っているフォーマットとして「ユニバーサル」を意味しました。白黒などで書かれた標準である必要はありません。誰もがそれを読んで、テキストが何を表しているのか混乱せずにすぐに知ることができる限り、それは普遍的です。確かに、1.234,00は間違いなく普遍的ではありません。私は、あなたが一生ずっと、コンピューターを使っていて、この数字形式にまったく出会ったことがない人を見つけることができると確信しています。ほとんどのWebサイト/アプリは、ローカライズに対応するために変更なしで1,234.00を使用していたため、事実上の（すべての人がそれを見て理解できる普遍的な形式）と考えています。 日付に関しては、01/02/03を書くと、誰がそれを知るか（一義的で、すぐに、あいまいさなしに）日付が何であるかはわかりません。しかし、2003年1月2日、2003年2月1日、2001年2月3日など、私たちがそれらを書いたとしても、だれもが間違っていることはないでしょうか？ この質問はローカライズを対象としていますが、「誰もが英語を読めるとは限りません！」それは国際化の問題だからです（このトピックを超えています）。ローカリゼーションに関する議論に固執しましょう。

30 time  internationalization  localization  date-format 

そのため、カナダ、米国、インド、英国などのユーザーを含むグローバルユーザーに使用されるWebページを設計しています。この電話番号フィールドに検証を適用する必要がありますが、これを実行する最善の方法はわかりません。 私が考えることができるいくつかの有効な形式は次のとおりです。 1800123456（インド） 米国の電話番号での「-」の使用 ユーザーに入力を許可する必要がある特殊文字（たとえば、- / ()）について少し混乱しています。過去に他の人はこれをどのように解決しましたか？

20 javascript  validation  internationalization 

一般に、多くのプラットフォームでは、文字列リソースを.resxまたは.xmlファイルに書き込み、プラットフォームに依存するアプローチを使用してそれらを取得しています。 つまり、iOSでは、を介してNSBundle.MainBundle、Context.ResourcesAndroidで使用して取得しています。 このアプローチの利点は何ですか？また、コードで直接アクセスできない理由は次のとおりです： クロスプラットフォームプロジェクトでは、どのプラットフォームでも統合せずに直接アクセスできます。 構築中、リソースが適切に構築されたかどうかについての懸念はありません。 コーダーは、多言語処理などの機能を使用できます 要するに、文字列リソースがそのように構成されている理由は何ですか？ [編集] 私のファイルが他のプロジェクト間で共有される「コア」プロジェクトの一部であるとしましょう。（PCL、クロスプラットフォームプロジェクトのファイル構造について考えてください。） そして、私のファイルは.resx / .xmlファイルとまったく同じで、次のようになっていると仮定します（私はxmlのプロではありません、ごめんなさい！）：パラメーターParamètres したがって、これは基本的にカスタムxmlであり、適切な文字列を取得するためにキー/言語をポイントします。 ファイルは、アプリケーション内にアクセス可能なファイルを追加するのと同じようにアプリケーションの一部になり、PCLを使用してコーディングされた文字列リソースにアクセスするシステムになります。これにより、アプリケーションにオーバーヘッドが追加されますか？

18 cross-platform  resources  internationalization 

多くの小さなパッケージで構成される大規模なアプリケーションを開発しています。各パッケージには、ローカライズ用の独自のリソースファイルセットがあります。 ローカライズ文字列を整理して命名するための最良のアプローチは何ですか？ これまでの私の考えは次のとおりです。 重複の処理 同じテキスト（たとえば、「Zip code」）が特定のパッケージ内で複数回出現する場合があります。プログラミング本能（DRY）は、すべてのオカレンスで共有される単一の文字列リソースを作成するように指示します。 繰り返しになりますが、翻訳者は場所によっては長い翻訳（ "Postleitzahl"）を選択し、スペースの少ない場所では短い翻訳（ "PLZ"）を選択することもできます。または、一部のオカレンス（「Zip code：」）にコロンを追加し、他のオカレンスには追加しないこともできます。または、場所によっては異なる大文字（「郵便番号」）が必要になる場合があります。これらの引数はすべて、内容が同一であっても、使用ごとに1つのリソースを作成することを指します。 ネーミング 重複を排除することを目的とする場合、contentでリソースに名前を付けることは理にかなっています。おそらくプレフィックスを介した使用の種類を示唆しています。我々が持っているかもしれだからlabelOK= 「OK」を、messageFileTooLarge= 「ファイルは、最大ファイルサイズを超えています。」、およびlabelZipCode= "Zip code"。 コンテンツによる命名には、フォーマット引数を自然に処理できるという利点があります。リソースはmessageFileHas_0_MBWhileMaximumIs_1_MB明らかに、実際のファイルサイズと最大ファイルサイズの2つのフォーマット引数を取ります。 ただし、重複を許可する場合、コンテンツだけで名前を付けることは意味がありません。一意のリソース名を取得するには、リソース名に使用場所を何らかの形で含める必要があります。識別子は少し長くなる傾向がありますが、グラフィカルコントロールでは機能します：fileSelectionConfirmationButtonText= "OK"、customerDetailsTableColumnZipCode= "Zip Code"。ただし、非ビジュアルコードファイルの場合は難しくなります。最終的に表示される場所がわからない場合、文字列の特定の使用法にどのように名前を付けますか？コードファイルと関数名で？私にはかなり不器用で脆いようです。 全体として、重複を許可しようとしていますが、これをサポートする一貫した命名スキームを見つけるのに苦労しています。 編集：この質問には2つの側面があります。リソースを整理する方法（DRYと複製）、および名前の付け方です。これまでのところ、答えは最初の側面に集中しています。命名規則に関するフィードバックをお願いします！

14 naming  resources  internationalization  localization 

私は、組み込みコンピュータシステムを製造する製品に統合し始めた会社で働いています。当社には非常に幅広い製品があり、それらは世界中に配布されています。さらに、システムにフラッシュされたファームウェアに応じて複数の目的に使用できる統合ボードをいくつか設計しました。このように、さまざまな製品のコンピューターハードウェアを再設計する必要はありません。特定の製品のニーズに合わせてファームウェアレイヤーを書き直すだけです。 これらのハードウェアの制限のため、ハードウェアの変更は議会の行為を取りますが、新しいソフトウェアの作成ははるかに簡単です。 当社の製品の1つには、以前に実装する必要がなかった新しい要件があります。これは、ユーザー入力テキストの必要性です。 現在、国際的なテキストをリソースに保存することができ、必要なフォント文字のみがビットマップ画像にコンパイルされています。これは、言語セット全体のごく一部しか使用していないため、中国語や日本語などの表意文字の言語を最小限のスペースに保存できることを意味します。 この新製品ではユーザーがテキストを入力する必要があるため、広範な文字セットを実装する必要があります。主にPC開発者として、私はASCII、Unicode、UTF-8などにかなり精通していますが、ボード上にFRAMが限られているため、これらの言語の完全な文字セットを実装することはできません。フォントデータを保存します。 私の経営陣は、表意文字の多い言語に使用できる最小限の文字セットがあることを望んでいます。日本語の発音記号（ひらがな？）があると思います。中国語、韓国語、ベトナム語などの言語にも同様の発音記号がありますか？その質問に対する答えは「絶対に、いいえ」であると確信していますが、質問する価値のある質問です。 経営陣は、一般的に使用されているすべての主要言語をカバーする約8,000文字の限られた文字セットのみを使用できるという「ソフト」要件を設定しています。これが不可能な場合は、限られたハードウェアリソースに基づいてニーズを満たすために、何らかの形の代替方法を探す必要があります。 この問題は以前に解決されていなければならないと確信しています。広範なフォントおよび文字エンコードシステムを必要とする一方で、このような制約内で作業した経験はありますか？もしそうなら、あなたはどんな知恵のナゲットを提供できますか？

14 c  hardware  embedded-systems  internationalization 

ソフトウェアプロジェクトまたはWebサイトで作業する場合、ローカライズを念頭に置いて開発しますか？ これにより、例えば エラーメッセージを含むすべての文字列を外部化します。 テキストを含む画像を使用していません。 テキスト拡張を念頭に置いてUIを設計します。 擬似翻訳を使用して、プロセスの早い段階でUIをテストします。 等 あなたが取り組んでいるプロジェクトでは、これらは「いい」カテゴリにあり、ローカリゼーションチームに残りのことを心配させますか、または開発プロセスにローカライズの準備が組み込まれていますか？開発者が一般的にローカライズをどのように見ているかを聞きたいです。

13 internationalization 

私はMVCパターンを学ぶ方法として始まった私の個人的なフレームワークを構築していて、今ではほとんどのフレームワークよりも好きなものに進んでいます（これはおそらく私が好きなものを追加して、私がしないものを変更したためです）好きではありませんが、それにもかかわらず）良いか悪いかにかかわらず、私はいくつかのプロジェクトでそれを使用しています。 私が現在抱えている問題は、i18n機能にアクセスするための適切な方法を思い付かないことです（これは実際にはi18nではなく、単なる翻訳であり、完全なi18nサポートは含まれていません）。 それが機能する方法は、構成ファイルを言語ファイルとして使用することです。Configフレームワークでは構成ファイルが動的にロードされるため、クラスを使用してそれらをロードするのが非常に便利だと考えたため、必要でない限りここで一目で把握できます。 class Config { private static $settings = array(); private function __construct() { } public static function load($file) { $path = PROJECT_PATH . '/config/' . $file . '.php'; if (is_file($path)) { $settings = require($path); } else { throw new Exception('Configuration file [' . $file . '] doesn\'t exist', …

10 php  mvc  internationalization  localization 

多言語のPHP Webアプリケーションを開発していて、gettextで翻訳する必要がある長い（-っぽい）テキストがあります。これらは、電子メールテンプレート（通常は短いですが、それでも数行）とビューテンプレートの一部（テキストのより長い説明ブロック）です。これらのテキストには、いくつかの単純なHTMLが含まれます（強調のための太字/斜体など、おそらくここまたはそこへのリンク）。テンプレートは、出力がキャプチャされるPHPスクリプトです。 問題は、gettextが長いテキストを処理するのに非常に扱いにくいように見えることです。長いテキストは通常​​、短いテキストよりも時間の経過により多くの変化があります— msgidを変更して、すべての翻訳で更新することを確認できます（多くの作業が必要で、msgidが長い場合はエラーが発生しやすくなります）。 msgidは変更されず、翻訳のみが変更されます（テンプレートに古いテキストが紛らわしくなります）。また、私はgettext文字列にHTMLを含めることに対するアドバイスを見てきましたが、これを回避すると、単一の自然なテキストが多数のチャンクに分割され、翻訳と再構築の悪夢がさらに大きくなるでしょう。 gettext文字列を個別のmsgidに不要に分割する。 私が目にするもう1つのアプローチは、これらの長いテキストではgettextを完全に無視し、それらのブロックを各ロケールの外部サブテンプレートに分離し、現在のロケールのブロックを含めることです。欠点は、gettext .poファイルと完全に異なる場所にある個別のテンプレートとの間の変換作業を分離していることです。 このアプリケーションは将来的に他のアプリケーションの出発点として使用されるので、長期的には最善のアプローチを考え出そうとしています。このようなシナリオでのベストプラクティスについていくつかアドバイスが必要です。同様のケースをどのように実装しましたか？何がうまくいき、何が悪い考えになったのですか？

9 php  templates  internationalization  gettext 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 APIを米国のスペルまたは英国のスペルで作成する必要がありますか？または、両方を1つにマッピングし、内部で私が好きな人を使用して両方が機能するようにする必要がありますか？現在、ほとんどのAPIは米国のスペルになっています。それの解決策は何ですか？ 編集：これを標準化する方法はありますか？両方サポートできますか？

9 naming  internationalization 

あなたの母国語がヘブライ語であり、ヘブライ語をソースコードに入れることができるPython 3のようなプログラミング言語で作業しているとします。よかったね！あなたは持っていdictます： d = {'a': 1} そして、あなたはそれをaヘブライ語で置き換えたいです。したがって、その単一の文字を置き換えます。 d = {'א': 1} ええとああ。他の変更を行わずに1つの文字を置き換えるだけで、表示がおかしくなりました。ヘブライ語からまでのすべて1が逆向きであり、これが何を意味するかは言うまでもなく、これが有効な構文（それがそうである）であることは極めて明白ではありません。 ヘブライ語は本質的に右から左であり、目に見えない制御文字がなくても、ヘブライ語のテキストは右から左に表示されます。これは、ヘブライ語の近くにある特定の「通常の」文字、および他のいくつかのスクリプトの文字にも適用されます。詳細は複雑です。 これにどう対処しますか？制御文字をソースコードに貼り付けて、コードを壊さずに表示を修正することはできません。16進数のエスケープですべてを書き込むと、ある種の読みづらさは別の種類と交換されます。Basic Latinブロックの文字を使用してすべてに名前を付け、ローカリゼーションファイルにすべてのヘブライ語の文字列を貼り付けることを辞任したとしても、右から左へのテキストと左から右への混合を避けるのは困難です。 ヘブライ語を含むJSONまたはCSVは文字化けします。文字列を押し込んだローカリゼーションファイルが人間が読めると想定されていたとしても、おそらくそうではありません。職業はなんですか？

9 internationalization  unicode 

gettextまたは同様のフレームワークを使用する場合、UIのラベルを生成するために翻訳文字列に':'（など"Label:"）を含める':'か、UIコード自体に追加する必要がありますか？

9 internationalization 

ログを国際化するための有効なユースケースは何ですか？特に、Webアプリケーションにとって意味のある用途はありますか。 私はからWebアプリケーションが使用するロギングAPIの変換に取り組んでいるlog4jのをslf4j、インターフェイスが上抽象的に使用されていることに気づいたlog4jの実装をサポートする国際化。また、との両方が国際化log4jをslf4jサポートしていることにも気付きました。 現在、国際化は、エンドユーザーがログを表示できるデスクトップアプリケーションをプログラミングするときに役立ちますが、このロギングファサードは、一般的に英語を使用する必要がある開発者が、いくつかのWebアプリケーションのサーバー側でのみ使用します。 。

8 design  web-applications  logging  internationalization  use-case 

海外のユーザーにデータベースを使用してもらいますが、米国以外でメールシステムがどのように動作するのかわかりません。 「都市」、「州」、「国」、そして「郵便番号」の概念は、階層が2レベルしかない場合でも階層をキャプチャするのに十分ですか（都市/国）。

8 database  internationalization