ご存知かもしれませんが、省略記号 (または 1 つのドット) で短縮されたテキストは、理解できない可能性があります。
どのようにcompr。ですか？
モバイルエリア（電話、タブレットなど）でこのスタッフの多くを目にするはずですが、そのような翻訳は醜く見えます. OK、画面解像度が低いと、実際には選択の余地がありません (自動スクロール テキストを作成できる場合を除きます)。しかし、Web インターフェイスの場合は、確かに選択肢があります。
通常、ポイント 3 と 4 に対応する 2 種類のソリューションがあります。個人的には、私は #4 に傾いています - ボタンを自動サイズ変更可能にします。もちろん、これはボタンのサイズに一貫性がありませんが、それについてできることはほとんどありません。
解決策 4 を使用できない場合 (つまり、UI デザイナーがこの手法に強く反対している場合)、解決策 3 を少し変更できます。基本的に、私が過去のプロジェクトで使用していたのは、固定サイズのボタンであり、既定のサイズはほとんどの言語 (もちろんポーランド語とロシア語を除く) に適合しましたが、幅の広いボタンを定義する CSS クラスもいくつかありました。「長すぎる」言語にローカライズするときは、できるだけ幅の広いボタン クラスを使用しました。それでもテキストが収まらない場合は、翻訳者に短くするように依頼しました (通常は、言い回しを変えて、最後の手段としてテキストを 1 つのドットで短くします)。
ただし、ローカリゼーション コストが増加することに注意してください。これが、この方法をお勧めしない理由です。
解決策 2 については、UI の見栄えが悪くなります。ブラウザがテキストをどのようにラップするかを制御することはできず、多くのテキストがボタンのクリッピング四角形の外側にはみ出す (オーバーラップする) ことになります。
解決策 1 については、省略記号を使用することは 2 つの理由からお勧めできません。1 つ目は、省略記号が多くの言語で有効ではないことです (これは特にアジア言語に関連しています)。2つ目は、あなたがそれを自動的にやりたいと思っていることを理解しています。この場合、文字列を測定することはできません - 実際の画面上のサイズで、代替フォントで書かれています. Web UI の場合、ユーザーが特定のフォントをインストールしているかどうかがわからないため、サイズを推測することになります (Dojo を使用すると、理論的にはクライアント側で測定できます)。もちろん、これはテキストの重複 (選択したフォントに対して動的な短縮を決定した場合) または完全に理解できないテキスト (たとえば 8 文字の後に短縮を決定した場合) になります。静的短縮を使用し始めたプロジェクトがありましたが、それは完全に混乱していました。次に動的に切り替えますが、それでも十分ではありません。「文字列を拡張する余地がない」という潜在的な UI デザイナーの議論に対抗するために、私はそれがあまりにも混み合っているためにインターフェイスを正しく設計していないことを意味すると
しか言えません。. これが、I18n が UI 設計のベスト プラクティスと密接に連携するポイントです。つまり、(UI 設計において) シンプルさを追求してください。その結果、使いやすく、アプリケーションのローカライズが容易になります。
