The Mozilla
Organization
At A Glance
Feedback
Get Involved
Newsgroups
License Terms
Newsbot
Developer Docs
Roadmap
Projects
Ports
Module Owners
Hacking
Get the Source
Build It
Testing
Download
Bugzilla
Bug Writing
Tools
View Source
Tree Status
New Checkins
Submit A Bug
FAQ
Search
International M12 Status Page


by Katsuhiko Momoi
Last Update: 12/25/99

This page tracks the progress of M12 International features.  By the time M12 is completed, this page should have all the completed M12 features and testing hints. If you are interested in what has been completed in the prior Milestone, visit the M11 international status and testing hints page.
 

M12 International features that have been completed:

General:

I18n Engineering and Milestone Tasks document is available here.
I18n Beta 1 Feature Plan is available here.
I18n Beta 1 Mail/News Functional specifications are available here.
Localizing Mozilla document.
Bitstream Cyberbit Unicode font for Windows  (version 2.0) is available here. Read READMEFirst file for details before downloading the fonts.
Report international bugs: Use Bugzilla.
Questions and comments:
    Note: The name of the executable is mozilla. (At one point during the development, it was apprunner.exe.)
 

Preferences/Installer:

  • The Mac installer for the M12 binary seems to be very slow taking an extremely long time to finish.
  • There is very little need to directly edit Preferences file, prefs.js.  Both profile migration and new profile creation are very easy to accomplish with the improved Profile Manager. Users who have had trouble setting up Mail server(s) before should try Edit | Account Setup menu available in the Messenger window.
  • Mozilla can migrate Communicator 4.x profiles you have on your system. Choose an existing one made by 4.x from the list and a new one will be created for Mozilla.
    • The window for profile migration will appear the first time you start M12 build after the installation.
    • If it does not, you can start with the profile manager: mozilla -installer (Unix & Win).  Mac users can start with the Mozilla Profile Manager file.
  • If you have used an earlier version of Mozilla, we recommend that you delete the file called mozregistry.dat (Win)/Mozilla registry (Mac)/registry (Unix) before you run M12 Mozilla. (Don't delete Netscape Registry file for Mac, which is for Communicator 4.x.). We recommend this procedure because during an earlier Milestone, i.e. M10, there has been a change in the way registry works and the old registry prior to M9 will not work well with builds later than M9. Read the section in the Release Notes called Files Used or Created to find out where you can find these files.
  • When you start M12 after having deleted mozregistry.dat or registry, you will be asked to create a new profile. If you name an existing profile, that profile will be used. Otherwise "Default" profile called "mozProfile" will be created. If this latter happens, you can replace the prefs.js file in the Default folder with the one from an existing profile directory. (Note that the default profile name changed from prefs50.js (of M8 and earlier) to prefs.js starting with M9.)
  • Note on non-ASCII path names: For both Profile manager and Mail/News Account setup manager, it would be best to avoid choosing folder or path names which contain non-ASCII characters at this point. Internationalization of these is not complete yet. (Mail/News Account names in non-ASCII display OK, however.)
  • Also read the Installation instructions for your platform carefully in this Release Notes.
Browser:
  • Performance: There have been more improvements made since M11 in stability and features that matter to international users. There are, however, still some crashing bugs left. They tend to be caused by encountering unsupported feature.. And in that sense, there is good stability in the program if you can avoid these types of crashes. Generally speaking, however, we believe M12 is quite usable for international users.
  • Sidebar: You should be able to display non-ASCII names here, e.g. Related sites. (Note: You may run into a  crashing problem if you use Search dialog and then try to close/open the Sidebar.)
  • Bookmarks: Bookmarks titles support non-ASCII characters. Note: IE favorites are not imported correctly yet and will nod display non-ASCII characters well.
  • Font Preferences: Backend work for font preferences has been completed for M12. The UI for font preferences are not done yet but font names and sizes can be manipulated by editing prefs.js file for Windows only.  Here are some highlights of new font preferences:
    • The font preferences can now be set for 5 generic font families: serif, sans-serif, monospace, cursive and fantasy
      • Mozilla does not map non-generic font family names such as "Times", "Courier", and "Arial" to corresponding CJK fonts. Web page designers should use generic font names if this is the desired result.
    • The font preferences are in principle set for language/script groups (except for Unicode) rather than for charsets as was done in Communicator 4.x.
    • These preferences will be consulted to select fonts to use in case the page you are visiting does not have fonts specified.
    • Non-ASCII font names are also supported on Windows at this time. We don't have UI for this yet but you can play with non-ASCII font names and font sizes by editing prefs.js. Be careful, however, because prefs.js must be in UTF-8 if it contains any non-ASCII characters. UTF-8 editor is hard to find. Japanese font names are known to work on Japanese Windows95/98/NT4. Help us by trying out the Korean and Chinese font names under the respective language Windows. Below is an illustration on how you might edit prefs.js for font preferences on Japanese Windows:
      • Find your current  prefs.js file, and make a backup copy, then rename the original prefs.js to something like jpprefs.txt.
      • Using a text editor like NotePad, edit jpprefs.txt with the following templates for font names and sizes:
        • user_pref("font.name.serif.ja", "Font_name_in_JPN");    -- You can set fonts for each of the 5 font types mentioned below.
        • user_pref("font.size.serif.ja", 12);
          • Possible font types: serif, sans-serif, monospace, cursive and fantasy.
          • Possible language groups are: ja, zh-TW, ko, zh-CN, x-western, x-central-euro, x-cyrillic, el, tr, x-unicode, zh-TW
        • When inserting font names in Japanese, pay special attention to how the font names are spelled -- is the alphabet part using full-width Roman? Is the space half-width or full-width? You can see how the font names are written by looking in the Control Panel's Font utility program.
      • Now that you have edited jpprefs.txt using Japanese font names, you should convert the encoding to UTF-8 using the following command line utility shipped with Mozilla (Win and Unix only) in the same directory as the mozilla executable. See below on details of how to use the conversion utility.
        • nsconv -f Shift_JIS -t UTF-8  jpprefs.txt prefs.js
          • Note: nsconv does not replace an existing file of the same name -- that's why you should rename the original prefs.js to something else first.
        • Now Mozilla can read the Japanese font names you specified and reflect your choice.
      • Any additional Japanese editing should be done on jpprefs.txt only. Then the conversion utility should be used to get the UTF-8 version of it -- unless you have an editor which can handle UTF-8 data directly. Note: On Windows 2000 (currently Beta), editing utilities should be able to save data into UTF-8. If you know of other such editors, please write to me and tell me about it.
      • None of these hand-editing would be needed when the font UI is done, which should be coming soon.
  • Big 5 fonts on Unix: It is now possible to use Big5 fonts with the suffix big5.et-0.
  • Big 5 fonts and Japanese Kana display on Unix: When you have Big5 fonts like Taipei on your Unix system, due to a Big converter table error, it leads to non-display of Japanese Kana characters. If you have this problem, you can get the Japanese display back when you remove the Big5 fonts. See Bug 21209 for details. This problem was fixed in M13.
  • Form: Form submission of non-ASCII data is working generally. Multipart file upload is not implemented for M12. This will be fixed in M13.
    • If a web page form uses JavaScript and escape() function on form input data, at M12 JS returns unicode data instead of the charset which matches the web page. This will lead to incorrect data submission and failure of search. Cf. Bug 22594.
    • There is a bug which shows only dots or blank for non-ASCII data input when the Back button is pressed on the page which resulted by submitting form data. Cf. Bug 22580.
  • GFX widget/Ender is ON by default. This means that all input areas in M12 support non-ASCII character input including input using CJK IMEs. Editor bugs reported for M10 have been mostly fixed in M11. Thus users should have usable Editor on all platforms.  Read the Editor section below for more information.
  • M12 converter(s): There are no new converters in M12.  See here for a list of all the converters at M12.
    • Unix charset testing:  As mentioned in the M7 Release Notes, the display for the supported charsets except Armenian, Thai, and Vietnamese should be working now.  We would like users to continue to look at various Unix charsets and file a bug if a problem is found. The list of the supported charsets at M12 can be found below. Please download the Unix binary and check out our support for these character sets. (Note: You need appropriate fonts to display these languages -- pcf.gz format on Linux. Visit this site for ISO and Cyrillic BDF fonts, and this site for multi-byte language fonts. If you want to get the entire international font set, try one directory above for this file, intlfonts-1.2.tar.gz . For converting from BDF to PCF format fonts, use bdftopcf utility. Once installed you need to update the fontsdir, i.e. mkfontdir, and then rehash the font path, i.e. xset +fp `pwd` .)
  • View | Character Set menu:
    • Note: The current Character Set menus (including the name of the menu itself) are temporary and will be replaced soon by an entirely new single menu. The new menu specs for the Browser have been published here. The name "Character Set" will also be replaced by "Character Coding".
    • You will notice that there are 7 Character Set Menus in the Browser window, and 6 in Composer/Editor and Messenger.
    • The first 6 "static" menus with sub-titles such as "ISO" constitute a workaround for long, non-customizable and non-scrollable menu.
    • The 7th Character Set menu -- found only in the Browser window -- is the dynamic menu which is under development but will eventually replace the workaround menu. This is the same menu as the first 6 put together. It does not scroll under Linux and Windows and so you cannot probably see the whole list except on Mac, but the dynamic menu is created via a script. This is first of the series of steps we will be taking to make the Character Set menu completely dynamic and eventually accommodate new Character sets via a plug-in directory. The dynamic Character set menu will use the Extensibility Model as discussed in this document.
    • Both types of  menus should work in M12 and one of them is actually redundant. This is harmless, however. Character set menus in other components are still static at this point and you will not see the dynamic menu.
    • View | Character Set menu Display problem workaround: The workaround mentioned in M10 and earlier Release Notes has been incorporated into M11 and later and thus is no longer necessary.
  • View | Character Set menu usage:
    • You can switch to different Character set upon encountering a page which does not have a  meta charset tag and which is not displaying correctly. If you happen to have a charset detector ON and if the display is failing, you need to first turn OFF the detector setting, and then try the Character Set menu. Otherwise, the charset detector's choice will always predominate over the manual menu selection. You will not see a checkmark next to the menu item yet, however.
  • Charset detection modules in the Browser Menu.
    • The charset detection modules for Chinese, Japanese, Korean, East Asian (CJK), Chinese (Simplified & Traditional Chinese), Ukrainian, and Russian are in a menu below the Character Set menu.
      • Russian & Ukrainian: At present, there are 2 serious bugs for Ukrainian and Russian modules from working properly. One of them prevents any character input by Editor once either of  these auto-detect modules is turned on. We recommend against this using these 2 modules until these bugs are fixed. --> Bugs 17094 & 17103 -- both fixed in M13.  )
    • You can select 1 charset detection module at a time. Once selected, the auto detection for the charsets of  language(s) you selected will be ON until you turn it OFF.
    • The charset detector will be engaged even when you have selected a Character Set explicitly via the Character Set menu. If you need to override the effect of the charset detector in effect, choose OFF, and then select a new Character Set from the Character Set menu. Please use the charset detector feature for a variety of web pages in the languages of your choice and let us know how we are doing. File a bug at Bugzilla or send your comments to netscape.public.mozilla.i18n or  netscape.public.mozilla.qa.i18n.
    • Until M10, these charset detectors could be used only by prefs.js settings. This is no longer necessary since the charset detector menu fulfills exactly the same function.  The menu now controls what gets inserted into chardet_name of:
      user_pref("intl.charset.detector", "chardet_name");
       
      If the charset detector is OFF, then chardet_name value will be empty. As reported before, unit testing also can be done via a utility called "Detectch.exe" found in the same directory as the "mozilla.exe" file. If you are interested in modifying the prefs.js for charset detector modules or use the command line utility, read the usage instruction here.
       
  • HTTP charset: Mozilla supports server-generated HTTP charset correctly. (The order of priority is: HTTP charset > Document Meta Charset > Browser Menu choice.)
  • View | Page Source: works only partially for different charsets.
    • It works OK:
      • if the page has a correct server-generated HTTP charset or document-based Meta charset associated with it
    • In other cases, there are failures of correct display. They fall under 2 types of cases:
      • The page has been correctly loaded with the use of a charset detector --> the source view will load but may not correctly display characters.
      • When none of the conditions above holds and the user has loaded the page correctly with the manual change of the Character Set menu --> the source view will load but may not correctly display characters.
  • CJK line breaking: Mozilla's line breaking implements specifications found in JIS X 4501 with some additional modifications. Read this news article posted to the newsgroup netscape.public.mozilla.i18n by Frank Tang for details.
  • CJK basic printing: should be working on M12 on Windows and Mac. Not verified to be working on Linux -- probably not.
  • EUC-TW bug (Unix): M12 still a bug which produces wrong display for EUC-TW (Traditional Chinese) pages under Unix only. This problem has been fixed in M13.
  • Mac: Baltic display:
    • ISO-8859-13: You may experience a problem in Baltic ISO-8859-13 display in that some of the uppercase characters may be missing the diacritical marks above them showing only the base characters.  See Bug 9165.
      • One Workaround:
        • 1) Install a Central European script bundle (CE) from this Apple file. (You need DiskCopy utility to mount this image). After you mount this disk image, rather than using the Installer, open the System file directory by double-clicking on it. In it, you will find among others, CE (script), Slovak (keyboard layout), and slovensk (keyboard layout). Drag these files to your current System Folder. Mac OS will then place them in the right places.
        • 2) Next, get the fonts for Central European from this Apple file. Once you mount this image file with DiskCopy, you will find a number of CE fonts. Drag and drop them onto your System Folder. Mac OS will then place them in an appropriate folder.
        • 3) After steps 1 and 2 are completed, re-start your Mac. You should now see ISO-8859-13 (also ISO-8859-4) characters correctly.
    • Central European ISO-8859-2 display: There seems to be a Mac bug -- some 8-bit range characters display as "?" even though a correct font exists on the system. See Bug 18095.
  • Mac: In earlier milestones, Mac Japanese display had mixed fonts from other Asian language fonts. Font display for CJK should now be consistent using a single font family for native characters.
  • Java: Java Plug-ins work OK on Windows.
    • To get Java working on Mozilla, you need to take some extra steps as described below.
      • First get the International version of  JRE 1.2.2 or later from Javasoft. We recommend using JRE1.3 (Beta at this point) for improved Java support. (JRE package are not  included in Mozilla distribution.) JRE packages are distributed for JDK releases and Beta version downloading requires registration first. Install the package on your Windows. We find that JRE 1.3 Beta can run more applets than JRE 1.2.2 plugin files and are therefore recommended. Plugin files are also much smaller in size in the latter version.
        • Note to CJK Windows 95/8 users: If you want to use Java on these Asian Windows 95/98, you must get the international version of JRE which has i18n.jar file needed for conversion from native charsets to Unicode -- otherwise, Mozilla will crash when trying to start. NT4 users will have no crash of this type. If you are CJK Win95/98 users and are not using the international version of JRE and are experiencing startup crashes, then remove the 3 .dll files from the plugins directory and live without Java until an international version of JRE is installed. See discussion in Bug 21305 for details.
      • Create a directory named plugins in the same directory where the mozilla.exe resides.
      • Copy 3 files, npjava11.dll, npjava12.dll, and npjava13.dll, from the JRE's bin directory into the plugins directory you created in step 2.
      • Check the Java Plug-in Control Panel from Windows Start | Program menu. The following settings (no others) must be checked.
        • Basic: Java Plugin, Java Console (optional), Cache Jar in memory
        • Detailed/Advanced: Use Java Plugin as default, Just in time Compiler is on
        • Proxy: use the browser setting
        • Certificates: (none)
    • Due to a few bugs, some applets simply will not run. Some string display applets do run and so far we have found none can actually display non-ASCII strings. If you have specific applets which deal with string display, write your finding to netscape.public.mozilla.qa.i18n.
Editor: For IME specifications, see this document by Tague Griffith. (Current eidtor i18n engineers are Frank Tang & Erik van der Poel.)
  • General: There have been a number of  fixes in M12 to make editing easier for the user. The user will find editing tasks generally much improved in M12.
  • Filing Editor bugs. If you are filing editing related bugs, please CC the following people depending on the category of bugs you are reporting:
    • For all the Window keyboard input/ IME related bugs, add
      • buster@netscape.com,ftang@netscape.com,beppe@netscape.com, to the CC list
    • For all the Mac keyboard input/ IME related bugs, add
      • brade@netscape.com,ftang@netscape.com,beppe@netscape.com, to the CC list
    • For all the Linux keyboard input/ IME related bugs, add
      • akkana@netscape.com,erik@netscpe.com,ftang@netscape.com,beppe@netscape.com, to the CC list
    • For all the cross-platform keyboard input/ IME related bugs, add
      • buster@netscape.com,brade@netscape.com,akkana@netscape.com,ftang@netscape.com,beppe@netscape.com, to the CC list
  • Copy/paste now I18n-friendly: Basic intra-application copy/paste is now working in all areas of Mozilla for non-ASCII strings. You can copy from Browser or Messenger viewing window and paste into all Edit fields within the application. This should work for all languages we cover at present. Please check this out in M12 and let us know if there is any problem. Note: The inter-application copy/paste is working partially in M12 -- a full fix is scheduled for M13.
    • You can copy/cut and paste within the same application
      • within the same same text area
      • from one text area to another text area (e.g. from HTML to Plain Text editor text area)
      • from one text field to another text area under HTML Mail Composer (e.g. from Mail compose subject header to body text area)
    • Known bugs: Copy/cut and paste for non-ASCII string is not working in the following inter-application cases. These cases are being worked on and we should get this resolved in M13. See 8427 for details. The following paints a general idea of where copy/paste may not be working currently. Note that in some text areas these functions may be working at M12 anyway.
      • From Mozilla to another application -- if the other application does not support Unicode clipboard in the target Edit field. (Note: It does not help the matter if the platform does not support Unicode clipboard, e.g. Win95/98.)
      • From another application to Mozilla -- if the platform does not support Unicode clipboard. This should work on WinNT4/2000 but probably will run into a problem Win95/98 in some cases.
  • CJK IMEs: Most  major bugs in basic operations of CJK IMEs have been fixed but there are a number of smaller bugs. They should be suitable for fairly heavy use now.
  • Basic IME support on Unix: We test Japanese input under Red Hat 6.0 + kinput2 + wnn4. We need your help on testing other Unix platforms and other language IMEs!
  • Help test (Japanese) IME on Unix!: We need the following kinds of testing for Japanese IME  and others on Unix. Please send your comments to netscape.public.mozilla.i18n or file a bug using Bugzilla Bug Management System for Mozilla.
    • Testing on other platforms -- our reference platform was Red Hat 6.0.
    • Testing other XIM-based Japanese IMEs (both public domain and commercial ones such as Wnn6+xwnmo) to see how we are doing. We used kinput2 + wnn4 as our testing environment. We need input from people using other IMEs and servers. Write to us also if you can confirm other IMEs are working. If there are special conditions to be followed, include that information also.
  • Chinese and Korean IMEs on Unix: We would also like to hear from users of IMEs for Chinese and Korean IMEs. Write to: netscape.public.mozilla.i18n about your findings.
      • So far we have received reports that XCIN for Traditional Chinese works with Mozilla. For XCIN, see this English page for more info.
      • Also internally we could get one Korean IME to work. For Korean XIME general info, visit this English page by Jungshik Shin. For hanIM specific info, visit this Korean page.
  • CJK IME bugs:
    • On all platforms:
      • We don't see any crashing bugs at M12.
    • On Unix: Unix IME is fairly good shape though bugs remain but it is quite usable in M12. You need to be aware of  the following bugs, however.
      • The over-the-spot position of the input area: At M11, the input baseline was not well-aligned vertically when you first start inputting character. You could not see the characters well until the first input has been committed. This problem was fixed in M12.
      • With kinput2, there was a bug for M11 in which the input module window often covers the input line. This bug was fixed in M12 except for the New Mail Composer window's body text window. This latter bug was fixed in M13. Cf. Bug 22326. You can move the window if this bothers you.
  • Form Password field input bug:
    • Due to a bug, the form password input is not concealed completely when you engage CJK IMEs -- you can bring up the conversion candidate window and see what characters you are typing. To avoid this bug, turn off the IME and then input a password. Only this mode will work OK for the password field. The Half-width Alphanumeric mode (e.g. Japanese IME) normally works like the direct input mode but for this bug, it is not effective and reveals the input when the candidate window is brought up. Only ASCII input mode should be available in this field. See Bug 16940 for details.
  • Other bugs:
    • M12 has an annoying bug in Editor and Mail Composer where if you use ALT + NUM Pad to input Latin 1 accented characters, the input character gets placed one position to the left of the current cursor position. There is also similar bugs reported for reply/quoted msg in Mail Composer. See Bugs 22206 & 22205.
  • Notable bug fixes:
    • CJK IME force commit function has been enabled in some areas. For example, choosing a style menu item or inserting the cursor into other parts of the edit field will force commit.
    • Win95/98 Dead Keys on certain keyboards (e.g. US-International) is finally functional.
    • AltGr combination should now work for international keyboards. There is one glitch remaining -- i.e. a menu will open if the key you happening to be using with AltGr key is also a menu shortcut key.
    • XIME status window position now gets refreshed as new input is being made.
  • Saving with Editor Character Set menu: On a new document, change the encoding to the one you would like to save the document in and then use the File | Save as  menu to save the edited document in that character set. Bugs or comments to: Bugzilla or netscape.public.mozilla.qa.i18n. Here are some known bugs.
    • Now the document will be saved in a charset you specify via the Character Set menu. (Note: This behavior will change when the International Editor UI specs are implemented.)
    • Currently this menu does not reload a document. It can only be used to save a document into a different charset at the save time. This menu will be re-worked extensively later.
  • Summary of what has been enabled up to M 12:
    • CJK IMEs on Windows, Mac and Unix.
    • CJK force commit is functional in some areas -- there are some more tasks to be done.
    • Keyboard support for many one-byte languages on Windows: Please file a bug if you find a problem in your language or keyboard.
    • Keyboard support for many one-byte languages on Mac: Roman Australian,  Brazilian, British, Canadian-CSA, Canadian-ISO, Canadian-French, Dutch, dv-Dvorak, dq-Dvorak-Qwerty, Finnish, Flemish, French, French-numerical, German, Italian, Norwegian, Spanish, Spanish-ISO, Swedish, Swiss French, Swiss German, Cyrillic Bulgarian, Cyrillic-Qwerty, Russian, Ukrainian.
Localizability:
  • General: One of the key features of Mozilla is that it is relatively easy to localize menus and dialogs UI into any language. See the framework section below for a brief discussion of guidelines. Commercial browsers don't often get localized into languages with smaller number of speakers. If you want to see a fast, next generation browser in your own language, Mozilla offers a great chance to make it a reality.
  • Voluntary localization projects: Currently 12 voluntary language projects are going and more are likely to join. If you're interested in localizing Mozilla into your favorite language, this page explains it all. Current projects are: Bosnia, Brazilian, Catalan, Czech, Danish, German, Greek, Hawaiian, Norwegian, Japanese, Polish, and Thai. Some of them already have published M12 kits. Check out the Mozilla L10n How-to Page.
  • Localization framework:
    • We have published a guideline for localization. Anyone interested in localizing Mozilla into a native language should read this document carefully.
    • Here are some basic ideas to keep in mind when localizing Mozilla. For more details, read this document.
      • Do not localize .xul files directly. All localizations must take place in corresponding  .dtd files or property files.
      • Most localizable strings have now been extracted from .xul into .dtd (or property files) files. The .dtd files are found under  ../chrome/component_name/locale/en-US directory. They match the names of the corresponding .xul files which are placed under:../chrome/component_name/content/default directory.  (Note: Some samples of property files, which can also be localized, are found under ../res directory but there are currently only a few examples of this type of files.)
      • Translaters need not worry about this, but if you create a .xul file then you need to extract localizable string into a corresponding .dtd file. (If you're creating Mozilla UI via a script rather than by a static .xul file, then you need to extract them into a property file.) To extract .XUL entities into DTD files for localization, read this document.
      • XUL/XML/RDF files assume the default charset to be in UTF-8. If you change UI strings to your favorite language, they should show OK as long as the localized files use UTF-8 charset. (You can change menus to Japanese, for example, in ..chrome/navigator/locale/en-US/navigator.dtd file using the method suggested above and then convert the DTD file to UTF-8.) The menu items generally cannot be in languages your system does not support, e.g.  no Japanese menu for US Windows is possible at the moment.
      • All non-ASCII .dtd and .property files must be in UTF-8 encoding, which is Mozilla's default encoding for resource files. You do not need to explicitly mark the resource files with this encoding, Mozilla will assume that they are in UTF-8 if there are no charset tags.
      • In summary:
        • Make backup copies of all .dtd files you will be localizing
        • Rename your .dtd files to something which have a language identifying prefix, e.g. jpnavigator.dtd for navigator.dtd.
        • Edit these language specific .dtd files with an editor which can handle your language.
        • Once translation is done, use an UTF-8 conversion utility to turn jpnavigator.dtd into UTF-8 encoded navigator.dtd.  If you have an UTF-8 capable editor -- as you might on Windows 2000 --, you can edit these files directly and save them into UTF-8 encoding. See below for how to use Mozilla's character encoding converter, nsconv.
      • UTF-8 conversion utility:
        • Use convenient converter utilities such as "uniconv" (for Windows and Unix) or "native2ascii" utility included in the latest JDK.
        • Mozilla's nsconv conversion utility has been enhanced by "jonas.utterstrom@vittran.norrnod.se"-- it now supports charset aliases: The original nsconv is by the courtesy of Frank Tang. nsconv is installed in the same directory as your mozilla executable. You can use any encoding names recognizable by Mozilla and their aliases checked into the source in using this utility. Here's the basic command line for using this utility:
          • Usage schema --any one of the following:
            • nsconv -f source_charsetname -t target_charsetname source_filename new_filename
            • nsconv -f source_charsetname -t target_charsetname source_filename > new_filename
            • nsconv -f source_charsetname -t target_charsetname < source_filename > new_filename
          • You can use the charset names you see within the parentheses of  the Character Set menu for source_charsetname and target_charsetname, e.g. iso-8859-1, Shift_JIS, Big5, EUC-KR, etc.
          • The utility does not seem to replace an existing file with the new output file. If you have an existing file with the same name as the intended output, first delete the existing file. Or else output into a new file with a different name.
  • DTD/XML encoding definition supported -- thus  you can use charsets other than UTF-8 as the resource file charset, but using charset other than UTF-8 is not recommended for Mozilla localization. We assume UTF-8 as default. Cf. Bug 4431.


Mail/News (Testing done on Windows and Linux only):

  • Performance: Mail is now very much usable. It is not yet scalable to heavy use for those handling several hundred messages per day or those who have over a few thousand IMAP messages in an account. But for moderate users of mail, Mozilla is very very close to a usable mail client for daily use. M12 would be a very good chance to get your Mozilla experience going and participate in making it better for the upcoming 1st Beta. In addition to performance improvement with server interactions, improvements in preference settings with Mail Account Setup have been great in M12.
  • Preferences file: prefs.js (Note: Up to M8, the Preferences file was named prefs50.js. This file name is prefs.js instead for all later Milestones.)
    • General info for M12:
      • Once you create a profile via the Profile Manager, the rest is very easy to set up with the use of  Edit | Account Setup ... menu in the Messenger window. Read this section also for general preferences issues in addition to looking at Mail specific preferences.
  • Mail Account Setup manager: If you want to learn more about how to setup various mail and news servers, and multiple mail mail accounts, read this document. The future Mail Account Setup specs also have been published here.
    • UI drawing bug: Not all the UI elements may be drawn correctly and some buttons may look grayed out. If you have this problem, click on one or more server names on the left panel. This will complete the drawing of all the buttons.
    • SMTP sever setting:
      • If you have not done so already, after you start up Messenger, choose Edit | Account Setup ... and set the outgoing (SMTP) server and user name. This needs to be done only once but without setting, you will not be able to send out mail.
    • Password: Starting with M9, Mozilla ignores the password provided in the prefs.js file.
      • When accessing a mail server for downloading messages, you will be asked to provide a password via a dialog. If you want Mozilla to remember your password, use Edit | Account Setup ... menu and select "server" under each one of your accounts. Then check "Save password: box. You can also insert the following line into the prefs.js file:
        user_pref("mail.server.server1.remember_password", true);

        where "1" in "server1" should be changed to match your server number.

    • IMAP server setting:
      • Use Edit | Account Setup ... menu to set up a variety of IMAP server related options.
    • NNTP (News) server setting:
      • Use Edit | Account Setup ... menu and add an News server. Then when it is added, use File | Subscribe ... menu to add newsgroup you want to read. Currently there is no way to list all the newsgroups on a server. Just add newsgroups you want manually via the Subscribe... menu.
      • Reading in different languages is now working if the charset parameter is specified in news article headers. You can also use auto-detection modules enabled though the Browser menu to detect and display articles without a charset parameter. At this point, news reading in Chinese will be generally difficult since many Chinese newsgroups contain messages without any charset parameter.
    • POP Mail settings:
      • Use Edit | Account Setup ... menu and set up several different options using the server setting under each account.
      • You can set it up to keep the messages on the POP server after you have downloaded them, too.
    • HTML vs Plain Text Mail option:
      • You can set up HTML or Plain Text send option for each server in your account. In case a server is not selected in the Messenger's left pane, the setting for the very first server on the Account Manager list will be used as the default. In future, the default Mail Send option should become possible through an UI element.
    • Account Names in non-ASCII characters: For the names you want to give to each of the Mail or News account, you can now use your own language.
    • Directory Path names in non-ASCII characters?: You can customize where you store your mail msgs and summary files. At this point, non-ASCII names must be avoided in path names.
  • Downloading POP msgs & IMAP headers :
    • The performance in these areas has further improved since M11.
    • Note: some POP servers don' t handle multiple, simultaneous accesses to the same account well. In such cases, keep only one connection alive to use it trouble-free.
  • Displaying Mail links with Browser: Choose Browser's Debug | URI Dispatching | Enable Dispatching. When you do this, URL links in mail messages will not be shown in the Messenger window but by the Browser window. In the near future, this will be the default behavior and links will not be shown inline.
  • How various mail-related international functions are working at M12:
    • Address Book: now supports Non-ASCII (including CJK) input, editing and display. The following features are working.
      • Non-ASCII Input into card fields
      • List View pane -- proper international sorting
      • Each card view pane -- displays non-ASCII strings
      • Can re-edit existing cards with non-ASCII entries.
      • New message button -- quotes non-ASCII names correctly
      • Composer Address Picker -- now select non-ASCII names correctly.
      • Address auto-completion is working partially. If an Address Book entry contains non-ASCII characters, they are now displayed correctly. However, matching try with non-ASCII characters don't work with M11.
      • Importing 4.5 or later AB entries: Address book entries import from Communicator 4.5 or later is now possible. Just export your Address Book entries using Communicator 4.5 or later. This will create a file with .ldif extension. Import this file using File | Import  menu from the Address Book. (Note: This will not work with .ldif files created by Communicator 4.0x versions.)
      • New Msg button on Address Book entries: works and will import any language name into the "To: " header for new mail correctly.
      • Address Picker on Mail Composer window: works for all languages we support and displays all non-ASCII names correctly.
      • Bugs:
        • M12 has a bug which prevents new Address Book folder creation.
        • On Unix, sorting in Address Book is not working well.
    • Multi-lingual mail viewing: This is working on all platforms.
      • Multilingual viewing is working on IMAP, POP3 and NNTP servers as long as the messages contain properly MIME-encoded headers and body with correct charset parameters.
      • View | Character Set menu is currently not working to override wrong MIME charset label, or view msgs which have no MIME charset (except for Latin 1) specified.
      • If you have a multilingual font or several fonts which together cover the Unicode ranges (e.g. Chinese, Japanese, Korean fonts + Pan-European fonts), we use them in displaying mail messages and headers for all the languages we support. We pay attention to the charset parameter in the Content-Type header and switch to an appropriate font. The Character Set menu is not needed to switch to different language views unless the message you're viewing is incorrectly labeled. If you would like a basic mono-weight multi-lingual font, you can get Bitstream Cyberbit font 2.0 here. Mail font settings are also affected by prefs.js setting as described above in the Browser section..
      • Earlier there were a few bugs which prevented Mozilla from displaying Thai (Windows-874 or TIS-620) mail messages. They have been fixed and now you can view mail messages sent in these encodings.
      • Viewing News: is working. Multilingual news articles viewing works if they have correct MIME charsets indicated in the articles. Be warned, however, that newsgroups postings are not always MIME-compliant and this could defeat our charset honoring mechanism.
    • Viewing non-ASCII attachments: generally working but there are some bugs.
      • Attachments should be viewable if they are of the same charset as the main body of the mail or if it has explicit charset parameter in the attachment headers.  If an attachment lacks charset parameter info and if its charset does not match that of the main body, that attachment cannot be viewed currently even when the Character menu is changed to match the charset of the attachment. A charset detector as discussed above can work on attachments without explicit charset information -- if it is turned on via the Browser menu.
      • Multiple attachments in different languages: can now be viewed without changing the charset menu if each attachment's header contains a correct charset parameter. If you send a message from Mozilla with multiple attachments and if each attachment has a meta charset tag, Mozilla will create a content-type charset parameter for each attachment from the meta-tag information.
      • Latin 1 attachment to ASCII msg: If an attachment contains raw 8-bit Latin 1 characters and is attached to a mail body with ASCII tag, Mozilla does not display these attachments correctly. We fixed this problem in M13 by assuming ISO-8859-1 instead of ASCII as the message charset. See Bugs 20997 & 22209 for details.
      • Japanese attachments and auto-detection:
        • The auto-detection module set for the Browser via its Auto-Detect  menu will also detect the charset of mail attachments. See above on how to set an charset detection module.
        • Currently there is a bug which corrupts Japanese EUC-JP attachment display. To work around this problem, we have put in a mail specific charset detector which only works in Messenger under Windows only. (Note: Eventually this detector will be removed when the EUC bug is fixed.) When this is set, this detector rather than the Browser detector will be used in Messenger.  This detector will be ON even when the Browser detector is OFF. For those wishing to view Japanese EUC files attached to mail messages, we recommend that this workaround be put in place. There is no UI for this but this is how you can use it:
          • In the pres.js file, insert the following line:
            • user_pref("mail.charset.detector", "jaclassic");   <-- this is basically a detector module used for Communicator 4.x.
      • Printing: Basic printing is enabled. Currently it is rather primitive. Headers don't seem to be printed -- only body text.
    • View | Character Set menu and thread pane reloading:
      • The menu change causes the thread pane to reload properly. This makes it possible to display non-MIME-encoded headers which don't match the current Character Set menu setting.  Headers, body, and attachments without MIME charset information may not be displayed properly, however, even if the Character Set menu is changed.
    • IMAP Latin 1 folder name: displays OK. Multi-byte folder names (e.g. CJK) don't display well yet.
    • International Sorting for Thread pane headers:  now works well in the Subject headers on all platforms with some problems still left on certain locales. CJK characters are not displayed correctly in the Sender field and therefore cannot be tested. Sorting should be done according to the sort default for the language of your operating system. Date/Time sorting is also working as it should.
      • Linux sorting:
        • There seems to be a problem with Latin 1 sort -- this is under investigation.
        • Also sorting is working for some Japanese locale names but not others. It might have to do with locale name aliasing. This problem is under investigation.
    • International Date/Time format:  now works for NT4, Win9x, and Mac for all locales. The format will be used according to your OS's date/time format setting.
  • Sending Latin 1 & Japanese attachments/pages:
    • File | Send Page is now working in M11 in addition to attaching a local file to a message.
    • Note that Mozilla will append a charset parameter to the attachment headers if the page contains a meta charset tag.
  • Send-related bugs at M12: Most of the send-related bugs in M11 have been fixed. We still have some new bugs in M12, however.
    • If you reply/quote, under Plain Text send option, a message which has an attachment bearing a meta-charset document tag, Mozilla may crash. See Bug 22655.
    • If you reply/quote a page containing an attachment with frames, it may lead to a crash. See 18312.
    • Using HTML entities under an encoding which does not contain the characters represented by them, e.g. Latin 1 accented characters under Japanese encoding, leads to a crash. Bug 22315.
    • Forward/inline of certain plain text mail msgs lead to loss of linebreaks in the quoted text. See Bug 21869.
    • When replying under HTML send-option to a message which includes an HTML attachment, an error occurs and the mail cannot be sent. See Bug 21682.
  • Sending messages in other languages: View | Character Set menu for New Mail Compose window is working for sending mail for many additional languages. Switch to the charset you want to compose a message in and then compose the message.  You will not see a checkmark next to the menu item yet, however. Let us know how we are in sending messages in other languages. Send your report to: netscape.public.mozilla.qa.i18n.
  • Composing Latin 1 mail messages:
    • In sending 8-bit range characters with HTML mail under Latin encodings, starting with M11, we will generally use 8-bit characters rather than HTML entities. However, certain special characters not in the chosen encoding will be turned into CERs (so-called HTML entities) or NCRs (numeric character references).
    • In sending 8-bit range characters with Plain Text mail, we will generally use 8-bit characters rather than QP-encoded characters. Those characters not in the chosen encoding, e.g. the EURO under ISO-8859-1 is currently turned into a "?" symbol. We are considering more user-friendly spec for this currently.
  • General Fallback strategy for sending characters not found in the chosen encoding:
    • CERs or NCRs will be used in HTML mail.
    • "?" will substitute for non-existing characters under Plain Text send option. In future, we may offer an option to send in UTF-8 or some other encoding which support the characters in question.
  • Domain Name completion: is now working. An user ID only input will be automatically completed with the default domain when the Enter key is pressed.
  • Message Send Status summary for Latin 1 and Japanese: No indicates that the functionality is not working well.

    •  
    Message send feature
    Latin 1 (ISO-8859-1)
    Japanese (iso-2022-jp)
    Header (subject, address)
    Yes
    Yes
    Body - HTML
    Yes (8-bit characters are sent as is w/o entities except when the chosen charset does not contain the character)
    Yes
    Body - plain
    Yes (8-bit characters are sent as is w/o QP. When the chosen charset does not contain the character, "?" is used in its place currently.)
    Yes
    Reply/forward header
    Yes
    Yes
    Reply/forward body html 
    		 Yes -- POP mail, IMAP, NEWS (but some bugs) Yes -- POP mail, IMAP, NEWS (but some bugs)
    Reply/forward body plain
    		 Yes - IMAP, POP, News.  (but some bugs) Yes - IMAP, POP, News (but some bugs)
    Send/View Attachment(s)
    		 Yes (Send - local file and web page) Yes (Send - local file and web page.)
    Copy/paste into headers and body
    		 Yes (accented characters copy OK) Yes  (from headers to body in HTML composer only) No (from body to headers)
Notes on Composing Latin 1 and Japanese Mail messages:
    • Composing Latin 1 Mail:
      • Copying/pasting accented characters into the headers and  body works from anywhere within the application where copy is enabled, e.g. Messenger Mail window, Browser window. You can also copy Latin 1 data from Communicator 4.x into Mozilla.
      • Keyboard input into headers (e.g. subject) also works for accented characters. Using the English keyboard for Latin 1 high-bit input, ALTGr + 0+Number Keypad method works, e.g. Right ALT key + 0232.
      • Make sure to switch the View | Character Set  to your chosen Character set name before you send out a message.
      • Basic MIME compliance is there: Header Q encoding, and Body QP encoding for accented characters.
    • Composing Japanese mail:
      • Basic Japanese input works for body.  Japanese input/copying into the headers and body also work from within Mozilla. You can also copy JPN data from Communicator 4.x into Mozilla.
      • Mail goes out in ISO-2022-JP.  Header is B-encoded. (The Kanji-in escape sequence is that of JISX0208-1990/83. )
      • Make sure to switch the View | Character Set  to Japanese (ISO-2022-JP) before you send out a message.
    • Sending other charset mail -- is enabled. Please try out these new charsets! For example, Central European, Cyrillic, Greek, UTF-8, Thai, etc.
      • Though the mail text body can sense what keyboard you have selected and will switch font accordingly, there may be mapping bugs with some international keyboards.  If you find a bug with your charset/language, please file it here.
Mail/News (for Mac)
  • We don't currently test Mac for international features. Though we cannot vouch for accuracy, many of our Windows/Linux features should be working on Mac also.
List of Charset Converters available at M12:

Single-byte:

  • Western (ISO-8859-1, Windows-1252, MacRoman), Central European  (ISO-8859-2, Windows-1250, MacCE), South European/Esperanto/Maltese (ISO-8859-3), Baltic/North European (ISO-8859-4, Windows-1257), Baltic/North European (ISO-8859-13), Cyrillic (ISO-8859-5, Windows-1251, KOI8-R,  ISO-IR-111 aka ECMA-Cyrillic, MacCyrillic, CP-866), Arabic (ISO-8859-6, Windows-1256) - (not in spec, might be removed from commercial build later) , Greek (ISO-8859-7, Windows-1253, MacGreek), Hebrew (ISO-8859-8 aka Windows-1255) - (not in spec, might be removed from commercial build later), Turkish (ISO-8859-9 aka Latin5, Windows-1254, MacTurkish), Nordic/North European (ISO-8859-10 aka Latin6), Celtic (ISO-8859-14), Western (ISO-8859-15), Armenian (ARMISCII-8), Thai (TIS-620 aka Windows-874), Ukrainian (KOI8-U, MacUkrainian), Vietnamese (VISCII, Windows-1258, VIET-VPS, VIET-TCVN5712), other Mac encodings (MacCroatian, MacIcelandic, MacRomanian).
Multi-byte:
  • Japanese (Shift_JIS, EUC-JP), Traditional Chinese (Big5, EUC-TW), Simplified Chinese (GB2312), Unicode (UTF-8, UCS-2, UCS-4), Korean (EUC-KR), Western (T.61-8bit) - support this for LDAP v2 and X.500.
Stateful:
  • Japanese (ISO-2022-JP), Unicode (UTF-7, IMAP4-modified-UTF7- Needed for IMAP folder names)
Copyright © 1998-2000 The Mozilla Organization.
Last modified December 25, 1999.