You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
Mozilla has been designed to display many different languages without extra steps. The user should be able to browse and use e-mail without complicated setups or efforts when necessary fonts are available on the system.
Mozilla can be used with more than one language packs, which lets the user change the menu language and relevant URLs.
Contents of Sidebar tab and Bookmark will not change when you choose another region -- they are bound to a specific profile by design. (Bug 87939)
If you are using Chinese, Korean or Japanese language Windows 9x/ME and launching fails or crashes, read the Java section below for possible causes.
On platforms which support file names in Unicode, it is possible to create files and folders bearing names in scripts which fall outside of the system locale. Other browser operations which involve such folder or file names may not succeed, e.g. saving into such a folder, or opening a file whose path contains such characters. Using only characters supported by the default system language avoids this type of problems. (For details, see Bugs 58866, 100243, 100344, 100364, 100396, 101573, 128380, 104305) On Linux/Unix under UTF-8 locales, most of these problems don't exist.
What can be displayed in the window title bar is platform-dependent. On platforms where Unicode is natively supported (Windows 2000/XP, Unix/Linux with UTF-8 locales, and Mac OS X), any Unicode character can be displayed in the title bar as long as you configure a font that contain characters used for the title bar. On other platforms (Windows 9x/ME, Unix/Linux with non-UTF-8 locales and Mac OS classic), characters within the repertoire of the current locale can be displayed. (Bug 9449. See Bug 150131 on how to avoid by this problem by choosing Unicode-aware Windows Manager and setting fonts appropriately.)
The default for contextual numeric alteration has changed with Mozilla 1.4 Western digits in Arabic documents are no longer automatically replaced with Arabic digits in a context-sensitive manner. To activate the contextual replacement of Western digits with Arabic ones, type about:config in the location bar and set the value of the preference item bidi.numeral to 1 (Bug 181711). Alternatively, you can edit user.js by locating the file in the profile directory and using a text editor that can handle UTF-8 encoding.
The font selection is dependent on the value of
xml:lang (XML) specified in the document. However, there isn't
yet a way to set the language of documents in Unicode without the
option is necessary for them.
Even if this feature is implemented, it's strongly recommended that
authors of HTML and XML documents explicitly specify the language of a
document or a part thereof with
lang (HTML) and
Content-Language in the http header is not
honored, either. (Bug
Unrecognized language tags are considered synonymous as x-western (Latin). As a consequence, to control the fonts to render those pages with a language tag not handled by Mozilla, one has to configure fonts for Western. In addition, on some platforms, the font preference setting for Unicode is ignored and the font preference setting for the current locale is used for documents in Unicode without the language tag. (Bugs 91190, 204586, 206123)
Invisible characters need to be rendered invisible even if there are fonts with visible glyphs for them on the system (Bug 205387)
Mozilla does not support Dynamic Fonts. (Note: It was supported in Communicator 4.x.)
Auto-detect All/Universal may not be able to detect encodings in some cases on pages which don't supply document encoding information. You may instead try other auto-detection modules with a smaller scope for detection, e.g. Simplified Chinese, in such a case.
With the Windows 2000, IME, most of the new Japanese IME features (e.g. reconversion) are supported but some features may not work correctly. (Bug 18680)
When opening a file under a folder with multi-byte folder name, the path name in multi-byte characters is escaped in the title bar of Composer window. (Bug 136221)
The search sidebar (with Google as the default) works well for any language regardless of the current locale. However, due to a Keyword server problem, looking up non-ASCII keywords in the location bar does not work for most languages. (Bug 119825)
Non-ASCII filenames in download managers are rendered as garbage and cannot be selected for removal, lanuch and other operations. (Bug 208903) This was fixed in trunk builds (for 1.5 development).
When a web page is saved with "Web page, complete" as file saving type, inline images with non-ASCII names are not included. Due to the same cause, it is not possible to open an inline image with a non-ASCII name with 205682)context menu, 'file not found error' occurs. (Bug
Stand-alone image and media documents (e.g. PDF or Flash animation) with non-ASCII names can be saved correctly with the original names when opened in the current window. The window title bar is updated accordingly. (Bug 198598) However, this doesn't work yet if they're opened in a new tab or a new window. (Bug 199237)
In Composer, saving in Korean (ISO-2022-KR) and visual Hebrew (ISO-8859-8) doesn't work because there are no encoders for them. This is by design since they are no longer used for creating documents or messages. However, these menu items should be hidden from dialog window. (Bugs 132070, 133615, 152151)
Linux only: Bold and Italics styles may not work on ASCII characters when editing a CJK page. This is most likely to happen on CJK locales without good ASCII fonts. For example, you may be using open-source CJK locale support files. On commercial Linux distribution, particularly recent ones, the support files contain better CJK fonts and this problem is less likely to occur. (Bug 91145)
On RedHat Linux 8, users may not be able to input Japanese characters with the default Kinput2 XIM server without considerable difficulty when using the default "on-the-spot" input style. This is known to be due to a bug in RedHat 8 Windows Manager, Metacity. RedHat 9 uses a later version of Metacity and does not have this problem. A workaround is either to upgrade to a newer version of Metacity Windows Manager or to use the "over-the-spot" input style. (See Bug 210134 for details.)
The user may experience a crash problem when inputting a single byte-space character afer another Latin character when using the "on-the-spot" XIM input style with Kinput2. A workaround is 1) to input a single-byte space before activating Kinput2 2) to input Japanese characters prior to entering a single-byte space character, or 3) set the XIM input style preference to "over-the-spot". (See Bug 208095 for details.)
Mozilla crashes under CJK UTF-8 locales when one of CJK XIMs is used due to a bug in XFree86 prior to 4.2.0. A workaround is to use over-the-spot input style instead of on-the-spot. XFree86 4.2.0 or later doesn't have this problem. (See Bug 128875 for details.)
Mac OS: Non-ASCII non-Latin 1 info stored in Internet Config will not show correctly in auto-fill fields such as "Your name" field in the Mail account setup dialog. If this happens, you can manually correct auto-filled entries. (Bug 5721)
Filtering by body key is not implemented.
The Character Coding menu cannot correct the thread pane display of non-MIME encoded headers. (See RFC 2047.) If the message displayed lacks MIME charset information, the thread pane display obeys the default message display charset set via the folder properties dialog (set via the menu ). Correctly setting this option to the charset most often used in the user's mail viewing helps avoid display problems of this type.
When an image file on a page is sent via contextual 206252)menu, non-Latin 1 filenames are incorrectedly encoded. (Bug
Windows: You may be unable to print out Japanese characters from Win98-J with HP Laser Jet driver (Japanese version). Workaround: Install the driver that comes with the Japanese Windows 98 installation CD. Or go into printer properties, choose details tab, choose spool settings, choose "print directly to printer option". (Bugs 86989, 130083)
Windows: If you have WinME-Ja, you may not be able to print to a HP LaserJet 5Si/5Si MX using the HP LaserJet 5Si/5Si MX PS printer driver In this case, you should change the driver to HP LaserJet 5Si/MX. Or go into printer properties, choose details tab, choose spool settings, choose "print directly to printer option". (Bugs 86989, 130083)
Some cases have been reported in which Windows 9x/ME Japanese users have a problem starting Mozilla when there is a prior installation of older JDK or JRE under the operating system in use. The JRE 130_02 (or later) that Mozilla users can download from a Netscape ftp site contains many fixes since the official release of JRE 1.3. If you are using an older version of JRE 1.3 or the US version of JRE 1.3 under Japanese/Chinese/Korean Windows, you may experience this non-start problem.
To determine if the non-starting problem is due to Java installation, follow these steps:
If you have the Java problem as described above or want to install updated JRE 130_02 (or later) that you can download from a Netscape ftp site, follow these steps (Note: This type of problem has not been reported for Windows NT4/2000, but if you experience this problem on the latter two platforms, follow these steps for those platforms also):