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, 162361) 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 and Unix/Linux with non-UTF-8 locales), only 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 on Linux.)
The default for contextual numeric alteration has changed since 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.
Rendering of complex scripts such as Devanagari, Tamil, Thai, and Hangul Jamos is platform/toolkit dependent.
The font selection is dependent on the value of lang (HTML)
or xml:lang (XML) specified in the document. However, there isn't
yet a way to set the language of documents in Unicode without the
language specified.
option is necessary for them.
(Bug
121193)
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
xml:lang (XML).
Content-Language in the http header is not
honored, either. (Bug
122779)
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)
Line breaking algorithm is not based on UTR 14 (Line breaking) but based on JIS X 4051. It's not language-dependent except for CJK and Thai. (Bugs 206152, 203016, 164759)
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)
In the window without menu and toolbar, there's no way to change character coding. Neither is there a way to change the character coding of a (focused) frame. (Bugs 63054, 70830, 98395, 26353)
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)
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.
Non-ASCII names of files attached to mail messages are not encoded in compliance to RFC 2231 (Bug 193439).
When an image file on a page is sent via contextual menu, non-Latin 1 filenames are incorrectedly encoded. (Bug 206252)
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)
Linux/Unix: There are two different printing methods, direct PostScript and Xprint:
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):
On Linux and other platforms where XFree86 is used, Mozilla crashes while rendering a web page with flash animations if XIM server is active (Bug 211213). The crash is due to a bug in XFree86 that was fixed recently. As of Mozilla 1.5b release, XFree86.org had not yet released a new version with this bug fixed, but it is expected to shortly. In the meantime, you may take a couple of workarounds :
env LC_ALL=C mozilla enables you to avoid the crash
env XMODIFIERS= mozilla