Mozilla は、追加手順を踏むことなく多言語を表示できるように設計されています。システム上で必要なフォントが利用可能な状態にあれば、ユーザは面倒な設定や努力をすることなく、ブラウジングやメールの利用をできるはずです。
Mozilla は複数の言語パックで使うことができ、ユーザはメニューの言語や関連 URL を切り替えることができます。
別のリージョン (ローカライズされたコンテント) を選んでも、サイドバータブとブックマークは変わりません。これらは固有のプロファイルに依存します。(Bug 87939)
中国語、韓国語、日本語の Windows 9x/ME を使っていて、Mozilla の起動に失敗したりクラッシュする場合、後述の Java の項目 に該当するものがないか見てみてください。
Unicode ファイル名をサポートしているプラットフォームでは、その名前にシステムロケールから外れた文字を使ったファイルやフォルダをつくることが可能です。そうした名前を持つフォルダやファイルにかかわるブラウザ操作はうまくいかないかもしれません。たとえば、そういったフォルダへの保存やそういった文字をパスに含むファイルを開くことです。デフォルトのシステム言語でサポートされている文字だけを使っていれば この種の問題を避けて通れます。(詳細は Bug 58866、100243、100344、100364、100396、101573、128380、104305、162361 をご覧ください) UTF-8 ロケール下の Linux/Unix では、これらの問題はほとんどありません。
ウィンドウのタイトルバーに表示できる文字はプラットフォームに依存します。Unicode がネイティブでサポートされているプラットフォーム (Windows 2000/XP、UTF-8 ロケール付き Unix/Linux、Mac OS X) では、タイトルバーに使われる文字を含むフォントを設定してあれば、すべての Unicode 文字がタイトルバーに表示されます。その他のプラットフォーム (Windows 9x/ME、非 UTF-8 ロケール付き Unix/Linux) では、現在のロケールの範囲内の文字だけを表示できます。(Bug 9449。Linux で Unicode を認識する Windows Manager を選択し、フォントを適切に設定することでこの問題を回避する方法については Bug 150131 をご覧ください)
文脈上の数値変更のデフォルトが Mozilla 1.4 以降変更されました。アラビア語ドキュメントの 西洋数字 が、文脈に応じた方法で アラビア数字 に自動的に置換されなくなりました。西洋数字からアラビア数字への文脈的な置換を有効にするには、アドレスバーに about:config と入力して、設定アイテム bidi.numeral の値を 1 にしてください (Bug 181711)。または、文字コード UTF-8 が使えるテキストエディタで user.js ファイルを編集し、プロファイルディレクトリに置いてください。
デーバナーガリー文字、タミル語、タイ語、ハングル・ジャモ文字など 複雑な筆記体活字のレンダリング は、プラットフォーム・ツールキットに依存します。
フォントの選択は、ドキュメント内で指定された lang (HTML) や xml:lang (XML) の値に依存します。しかし、言語指定のない Unicode で、ドキュメントの言語を設定する方法はまだありません。これには [View] > [Set Language] オプションが必要です。(Bug 121193) この機能が実装されているとはいえ、HTML/XML ドキュメントの作者は、lang (HTML) や xml:lang (XML) でドキュメントやその一部の言語を明示することを強くお勧めします。
なお、HTTP ヘッダの Content-Language は無視されます。(Bug 122779)
正式に認められていない言語タグは x-western (Latin) と同じように解釈されます。このため、言語タグでページをレンダリングするためのフォントのコントロールは Mozilla では処理されず、western 用のフォントとして設定されるはずです。さらに、一部のプラットフォームでは、Unicode 用のフォント設定が無視され、現在のロケール用のフォント設定が言語タグのない Unicode のドキュメントに使われます。(Bug 91190、204586)
改行のアルゴリズムは UTR 14 (改行) ではなく JIS X 4051 を元にしています。これは、CJK とタイ語以外は言語に依存していません。(Bug 206152、203016、164759)
見分けのつかない文字は、システム上にそれらの文字のための明らかな象形文字フォントがあったとしても、見分けのつかない文字としてレンダリングされる必要があります。(Bug 205387)
Mozilla はダイナミックフォントをサポートしません。(注: Communicator 4.x ではサポートされていました)
ドキュメントの文字コード情報を提供していないページでは、全/汎用の自動判別は、文字コードを判別できないかもしれません。判別範囲をせばめた別の自動判別モジュールを選ぶと判別の正確性が高まります。たとえば 中国語、簡体字中国語、東アジアなどです。
Windows 2000 IME では、新しい日本語 IME 機能 (たとえば再変換) のほとんどはサポートされていますが、一部の機能は正常に動作しないかもしれません。(Bug 18680)
マルチバイトのフォルダ名をもつフォルダ配下のファイルを開く際、Composer ウィンドウのタイトルバーでは マルチバイトキャラクタのパスネームはエスケープされます。(Bug 136221)
メニューやツールバーのないウィンドウでは、文字コードを変える方法がありません。また、(フォーカスされた) フレームの文字コードを変える方法もありません。(Bug 63054、70830、98395、26353)
検索 Sidebar (デフォルトでは Google) は、現在のロケールに関わらず、すべての言語で正しく動作します。ただし、Internet Keyword サーバの問題により、アドレスバーからの非 ASCII 文字のキーワード検索はほとんどの言語で機能しません。(Bug 119825)
Linux のみ: CJK ページ編集時、ASCII キャラクタに対してボールド／イタリックのスタイルは効きません。これは いい ASCII フォントを持たない CJK ロケール上で 多分に起こります。たとえば あなたは オープンソースの CJK 言語サポートファイルを使っているかもしれません。コマーシャルな 特に最近の Linux ディストリビューションでは、サポートファイルはいくぶんベターな CJK フォントを持っていて こうした問題は起こりにくくなっています。(Bug 91145)
Red Hat Linux 8 では、デフォルトの Kinput2 XIM サーバで日本語の文字を入力できません。デフォルトの on-the-spot 入力形式を使うときにかなりの問題があります。これは Red Hat 8 の Windows Manager である Metacity のバグが原因であることが分かっています。Red Hat 9 は Metacity のより新しいバージョンを使っており、この問題は起こりません。解決策は、Metacity Windows Manager の最新版にアップグレードするか、over-the-spot 入力形式を使ってください。(詳しくは Bug 210134 をご覧ください)
Kinput2 で on-the-spot XIM 入力形式を使っている場合、ラテン語文字の後にシングルバイトの空白文字を入力したときに、クラッシュの問題に遭遇します。解決策は、(1) Kinput2 を有効にする前にシングルバイトの空白文字を入力する (2) シングルバイトの空白文字を入力する前に日本語の文字を入力する (3) XIM 入力形式を over-the-spot に設定する (詳しくは Bug 208095 をご覧ください)
Mozilla は、CJK XIM の 1 つが使われている場合、CJK UTF-8 ロケール下でクラッシュします。これは XFree86 4.2.0 以前のバグが原因です。解決策は、on-the-spot の代わりに over-the-spot 入力形式を利用することです。XFree86 4.2.0 以降にはこの問題はありません。(詳しくは Bug 128875 をご覧ください)
Mac OS: Internet Config に格納された ASCII でも Latin 1 でもない情報は、メールアカウント設定ダイアログの [Your name] のような自動挿入フィールドに正確に表示されません。このような場合は、自動挿入されたエントリーを自分で修正してください。(Bug 5721)
本文中のキーワードによるフィルタリングは実装されていません。
文字コードセットメニューは、MIME エンコードされていないヘッダのスレッドペイン表示を訂正することができません。(RFC 2047 をご覧ください) 表示されたメッセージに MIME 文字コードセット情報がない場合、スレッドペインの表示は [フォルダのプロパティ] ダイアログ ([編集] > [フォルダのプロパティ...] から設定します) で設定されたデフォルトのメッセージ表示文字コードセットにしたがいます。ユーザがこのオプションでメールを読むのに最もよく使う文字コードセットに正しく設定することでこの種の問題を回避することが出来ます。
メールに添付されたファイルの非 ASCII 文字を含む名前は、RFC 2231 に準拠した形でエンコードされません。(Bug 193439)
ページ上の画像ファイルがコンテキストメニューの [Send Image] を通じて送られた場合、非 Latin 1 文字のファイル名は正しくエンコードされません。(Bug 206252)
Windows: HP レーザージェットドライバ (日本語版) で、日本語版 Windows 98 から日本語の文字を印刷できない可能性があります。解決策: 日本語版 Windows 98 インストール CD に付属しているドライバをインストールしてください。または、印刷プロパティを開き、[詳細] タブ > [スプールの設定] > [プリンタに直接印刷データを送る] オプションを選択してください。(Bug 86989、130083)
Windows: 日本語版 Window ME では、HP レーザージェット 5Si/5Si MX PS 印刷ドライバを使って HP レーザージェット 5Si/5Si MX で印刷できない可能性があります。この場合、ドライバを HP レーザージェット 5Si/MX に変えてください。または、印刷プロパティを開き、[詳細] タブ > [スプールの設定] > [プリンタに直接印刷データを送る] オプションを選択してください。(Bug 86989、130083)
Linux/Unix: 直接的な PostScript と Xprint という 2 種類の異なる印刷モジュールがあります。
Windows 9x/ME 日本語版のユーザが OS に古い JDK や JRE を先にインストールして使っていると Mozilla の起動に問題が起こるケースが報告されています。Mozilla ユーザが Netscape の ftp サイトからダウンロードできる JRE 130_02 (以降) には JRE 1.3 オフィシャルリリース以降の修正が多数含まれています。日本語版、中国語版、韓国語版の Windows で JRE 1.3 の古いバージョンや US バージョンを使っている場合、こうした Mozilla が起動しない問題に遭遇するかもしれません。
この問題が Java のインストレーションによるものかどうかを見極めるためには、次の手順にしたがってください:
前述のような Java の問題がある もしくは Netscape の ftp サイトからダウンロードできる アップデートされた JRE 130_02 (以降) をインストールしたい場合は、次の手順にしたがってください (注: この種の問題は Windows NT4/2000 では報告されていませんがそうしたプラットフォーム上でもこの問題に遭遇したらやはりこの手順にしたがってください):
XFree86 が使われている Linux やその他のプラットフォームでは、XIM サーバがアクティブになっていると、Flash アニメーションを含む Web ページをレンダリングしているあいだに Mozilla がクラッシュします (Bug 211213)。このクラッシュは、最近修正された XFree86 のバグ が原因です。Mozilla 1.5 RC-1 リリースの時点で、XFree86.org はこのバグを修正した新しいバージョンをまだリリースしていませんが、まもなくリリースされると思われます。それまでの間、以下のような解決策を取ることが可能です: