Closed Bug 206550 Opened 21 years ago Closed 10 years ago

Revise Mozilla Intl Release Notes

Categories

(Documentation Graveyard :: Help Viewer, defect)

Product:
Documentation Graveyard
Component:
Help Viewer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: momoi, Assigned: momoi)

References

Details

(Keywords: intl, relnote)

Attachments

(3 files, 3 obsolete files)

Adjusted known-issues-int.html based on todays CVS with new printing sections
29.87 KB, text/html
Details
a little more changes
30.15 KB, text/html
Details
update for 1.5b/1.5
13.29 KB, patch
Details | Diff | Splinter Review 
This is a bug to keep track of items that need to be added or revised in
International Release Notes for Mozilla 1.4.

The initial list of items have been created by Jungshik. I added one
item to this list. This initial will be uploaded next for public view.
I will add some more later.
 
If you have other items, please suggest them here. One comment per one item,
please, so that we can easily track items to be included. 

It is important to remember that the descriptions will be edited down
to read like release notes. Thus what we have right now is a longer version
of the items to be included. This is necessary so that we can write accurate
notes even in shorter form.

Jungshik and I will be the final editors for this section.
Summary: Revise Mozilla Intl Release Notes for Mozilla 1.4 → Revise Mozilla Intl Release Notes for Mozilla 1.4
This is a longer version of the current additions/revisions. 
This will be edited down for the Official Release Notes. Also
some of the current items will be added back as well.
QA contact to jshin so that we can co-own this bug.
QA Contact: rudman → jshin
see bug 158894, bug 90384, bug 76433
http://bugzilla.mozilla.org/showdependencytree.cgi?id=54561
also try Bugzilla query for "relnote + intl" keywords
Keywords: relnote
Daniel,
We'll look at the bugs you mentioned and also the ones marked with "intl" and
"relnote" keyword. Most of the latter are kind of old. One other thing to
remmeber is that not every intl bug should be in the release notes. 
Only the most important ones should be -- otherwise the notes will become
useless. One other thing -- release notes is not where documentation
requests bugs should be handled. Some of the bugs you mentioned are 
of this category.

We would like the contribution in this bug to be specific -- not just 
the bug number list. Tell us what in a bug should be dealt with in
the next Intl Release Notes.
 
Kat,
Thank you for filing the bug. Here are some updates.

It's a moving target :-). 
 
>  [1] There's a problem with ZWJ/ZWNJ. (bug 192088 and bug 202352)
>  This also results in the misrendering for Arabic script.

  This problem was resoloved about 12hrs ago for Mozilla-Windows :-) Mozilla on
other platforms still have problems with ZWJ/ZWNJ. 

I forgot to list one of the most frequently duped bugs in I18N along with bug
9449. Everyone agrees that we need to offer a way to set 'Character Coding' for
frames and chromless windows (bug 26353, bug 63054, bug 70830 and bug 98395),
but we have yet to reach an agreement as to how to do that 'properly'.

> 2. Running Mozilla on  'Unicode platform' such as Win2k/XP, Linux/Unix
> with UTF-8 locale and MacOS X also helps you with file operations.
> That is, saving files with Chinese filename under French OS works well
> if the OS is Unicode-enabled. It doesn't work well under non-Unicode OS
> (e.g. Windows 9x/ME, Linux/Unix with non-UTF-8 locale.)

  I'm afraid I was too optimistic about this.  Under Linux UTF-8 locales, most
of file operations, if not all, work well as described. However, under
Windows(Win2k/XP), it appears to be a different story. What you have in 1.4b
release note appears to better reflect the reality:

> New: 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. 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. (Bugs 58866, 100243, 100344, 100364,
100396, 
> 101573, 128380, 104305)

 Bug 162036 may be added to the list above. Alternatively, it can be an item on
its own. 

 Besides, I found that saving to a file with Greek name doesn't work under
German locale (Win2k). Mozilla changes the Greek filename in a manner I can't
understand (MS IE preserves the Greek name). Needless to say, 'Greek' and
'German' are just examples and can be applied to any file name with characters
outside the repertoire of the current system locale (Win2k/XP). It seems like we
still make  'A' API (as opposed to 'W' API) calls in some places
(widget/windows?) where the difference between them is important. Most of
file-related bugs refer to 'double byte' character sets, but in Win2k/XP,
'single byte character set' (actually, the distinction is almost meaningless for
Win2k/XP) has more or less the same problem.
 
We should add a release note for the change in default behaviour with contextual
shaping for numeric glyphs in Arabic (bug 181711)
OS: Windows XP → All
Hardware: PC → All
Keywords: intl
Attached file a new draft in html (obsolete) — 
I merged attachment 123864 [details] with the current i18n release notes. New/revised
items are set in blue in yellow background (I wouldn't say this is the best
color choice. This is just a temporary measure to distinguish the new/revised
from the existing ones.)
Attachment #123864 - Attachment is obsolete: true
> The Character Coding menu cannot correct the thread pane display of 
> non-MIME encoded headers. This is by design. 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 Edit | Folder Properties ...). Correctly setting 
> this option to the charset most often used in the user's mail viewing > helps
avoid display problems of this type.

IMHO, the MIME charset of the body (if present in Content-Type header) should
override the default display charset set of the folder when rendering raw-8bit
headers. I thought there was a bug for this, but couldn't find it. Naoki, do you
know which bug it was? 

Another bug I couldn't find that I'm pretty sure was filed a couple of years ago
is about using lang-dependent fonts in the mail index pane. At that time, it's
not possible to fix that because xml:lang was not honored by the font-selection
mechanism. However, now that it's honored, we can fix this. Naoki, do you
remember the bug?
Blocks: 207595
Kat, if you're too busy with other stuffs, can I take care of this? 1.4rc2 was
out , but the i18n rel. notes was not updated.
Jungshik, I was timing this for 1.4 final but if you want to put out 
what we have now for 1.4rc2, that is OK for now. I am going to finish the editing
in the next 2 days. Let's then finalize the notes for 1.4 final. I have a few
more items to add.
Added 2 Linux JA IME related bugs for notes. The note for Bug 219134 
is a must.
Blocks: 208095, 210134
Attached file final draft (obsolete) — 
Kat and I worked off-line and came up with this final draft. (I'm hoping to
land a couple of patches into 1.4branch before the release, but that may not
happen so that this draft mentions bugs related with them.)
Attachment #124524 - Attachment is obsolete: true
The printing comments for Linux are wrong.
1. There is no "default" on Linux, both Postscript/default and XPrint are
included by default unless someone puts --disable-xprint in his .mozconfig file.
2. The Postscript/default driver is broken and requires newest version of
Ghostscript to be functional.
David, can you suggest a full text of the revised note items that you
referred to above? 
Katsuhiko Momoi:
I could but I suggest to try the resident experts for the printing code first:
rods@netscape.com and roland.mainz@netscape.com
David Schweiger wrote:
> I could but I suggest to try the resident experts for the printing code first:
> rods@netscape.com

rods is gone since a while... ;-(((

> and roland.mainz@netscape.com
                   ^^^^^^^^^^^^

Nah... that can't be correct... =:-)
I don't even get money for hacking mozilla in my spare free time... ;-(
Comment on attachment 126743 [details]
final draft 

There are a few "bugs" in the text (for _example_ mozilla on Linux has two
print modules, not three - unless you mean the gfx/src/qprinter/ stuff which
was killed because gfx/src/qt/ was CVS removed... ;-( ) ...

... new text coming up in a few hours (after dinner... :) ...
> There is no "default" on Linux, both Postscript/default and XPrint are
> included by default unless someone puts --disable-xprint in his 
> .mozconfig file.

My use of the word 'default' might have been  misleading. It may have been a bit
too Linux-centric, as well. On most Linux distributions these days, end users
don't have to take any extra-step to use PS module. On the other hand, to use
Xprint, they have to install and configure Xprt server (although it's very
simple due to Roland's effort and kind explanation at xprint.mozdev.org) 

> The Postscript/default driver is broken and requires newest version of
> Ghostscript to be functional.

I don't agree with your (repeated?) assertion that PS module is broken.
ghostscript is so widely used these days (see http://www.linuxprinting.org
It's not just for Linux despite its name) that requiring a relatively new
version of  ghostscript cannot be a basis for your assertion. As I wrote
elsewhere, most end-users of free Linux don't have a PS printer at home (please,
don't assume that everybody uses Mozilla at school/work where PS printers are
easily available), which means their printer jobs have to go through ghostscript
(or other host-based - as opposed to printer-resident - PS interpreters) no
matter what. 


> mozilla on Linux has two print modules, not three

 Again, the 'module' was not the best word, but I was  writing not from
programmers' point of view (to whom there are only two) but from end users'
point of view (to whom there are three methods depending on how you count)  

In addition to www.linuxprinting.org, I should have mentioned http://www.cups.org 
Perhaps, both (or the latter) should be mentioned in the rel. notes.

> new text coming up in a few hours 

 Roland, Is it ready? I'm waiting for you to fix a few 'bugs' you wrote about.
BTW, I clarified it a bit more (about CTL and Printing) and put it up at 
http://i18nl10n.com/mozilla/i18nrelnotes.html  (the newest version will always
be there until I get the cvs write access to the document tree). 

I'll incorporate Roland's fixes and upload it here as well. 
Jungshik Shin wrote:
> > new text coming up in a few hours 
>
> Roland, Is it ready?

Unfortunately isn't not ready yet, sorry. I wasted my time with various
Mozilla+Xfree86 bugs, the 1.4 release builds for Solaris(SPARC+x86)+Linux/SPARC
and much more and now I am walking on my theeth. Next item on my ToDo list is
sleep and the 2nd thing when I am awake again is this bug - don't worry... :)

Ok, jungshik. I committed the final draft at:

http://i18nl10n.com/mozilla/i18nrelnotes.html

to: http://www.mozilla.org/releases/mozilla1.4/known-issues-int.html

It should show in an hour or so. The only thing I did is to eliminate the
comment and the base tag. Otherwise, it is identical to what you have
put up above. 

Jungshik, please confirm the content. I'm on IRC. So if I should have 
eliminated more materials from your file. Let me know. I guess I can
upload to mozilla.org. It took my changes.

Roland, please revise as needed but please post your revision idea here
first. Thanks!
Hi Kat,

Thanks for committing it. There's a problem though. I didn't know that
the banner, menus and doc. info are added automatically and added them
manually. Because they're added automatically, now there are two of them.
I put up a new version (the only difference is removal of the banner,
menu and the doc. info and there's no change in actual content) at

   http://i18nl10n.com/mozilla/i18n_toupload.html

Please, replace what's currently up with this one. Thanks again.


jungshik, looks like asa fixed the problem. I forgot that you're not supposed
to include any wrapper. We now have at least our final draft up. 
Changes:
- Changed s/three print modules/two print modules/ with two subsections for the
PostScript module (normal+freetype2 mode)
- Added lots of anchors, mainly that people can put _external_ links to the
(sub-)sections (please don't change them too often :)
- Added "requirements" for the print modules and their modes (to rid of the
xx@@@!!!-"blabla not working..."-rants)
- Rewrote the Xprint section that people have an actual clue about what the
module is actually good for
- Added some more infos about the PostScript module's normal mode (people
always forget "wprint"... ;-()
- Wording/reordering and the usual adjustments (I agree with smontagu, some
native english speaker should run over the whole release notes and check them
:)

The page has smontagu's blessing - question to katakai and jungshik: Is it OK
for you ?
Attachment #126743 - Attachment is obsolete: true
Roland, once you get an agreement from the people you are cnsulting,
please chech the latest version in. (See my comments first, however.)

> - Wording/reordering and the usual adjustments (I agree with smontagu, some
> native english speaker should run over the whole release notes and check them
> :)

I disagree with this statement. Simply being a native speaker does not
make you a good editor. You really must have editing skills in addition
and good editors don't grow on trees.

It is true that this document -- even the one you uploaded can 
benefit from much tighter editing. But given the time constraint,
I suggest that we improve on wording, syntax and stylistics later
as we find more time.

May I suggest that we re-word the following section slightly?

"Note that PostScript files generated by FreeType2 printing have to be filtered
through GhostScript even if you have a PS printer. If you use one of recent
Linux distributions, there's not much, if any, to do, but on other flavors of
Unix, you may find it useful to refer to http://www.cups.org and
http://www.linuxprinting.org.?"

to something like:

"Note that PostScript files generated by FreeType2 printing have to be filtered
through GhostScript even if you have a PS printer. If you use a recent Linux
distribution, there is not much additional - if any - that you need to do to
make it work. But on other flavors of Unix, you may need to perform additional
steps. (See http://www.cups.org and http://www.linuxprinting.org for useful info.)"
Attached file a little more changes — 
Thanks for the revision of 'Printing' section and other changes.
Listed below are some more 'little' changes I made on top of yours:

- I got rid of a couple of remaining inconsistencies (module vs method/mode) in
'Printing' section and took care of a couple of remaining 'typos' in other
sections.

- I also removed the reference to 'Opentype' fonts because gfx/xprint doesn't
do anything special with GSUB/GPOS tables present in opentype fonts for complex
scripts.  In theory, every "dumb" Truetype font is an Opentype font, but when
it's mentioned side by side with TrueType, most people would believe that
GSUB/GPOS tables are made use of to render complex scripts. Please, correct me
if either Xprint module or Xprinte server does use GSUB/GPOS. 

- I also did some html clean-ups to get it validated and added a few more
'title' attrib. and links. 

- 'intl_' prefix was removed in anchor names because it seems redundant now
that this document is separate from the main release notes. There shouldn't be
many documents that refer to them, should there?
Katsuhiko Momoi wrote:
> Roland, once you get an agreement from the people you are cnsulting,
> please chech the latest version in. (See my comments first, however.)
>
> > - Wording/reordering and the usual adjustments (I agree with smontagu, some
> > native english speaker should run over the whole release notes and check 
> > them
> > :)
>
> I disagree with this statement. Simply being a native speaker does not
> make you a good editor. You really must have editing skills in addition
> and good editors don't grow on trees.

Disclaimer, my statement above was not meant as an offense to anyone, I just
droped that as a note and future ToDo item :))))

> It is true that this document -- even the one you uploaded can 
> benefit from much tighter editing. But given the time constraint,
> I suggest that we improve on wording, syntax and stylistics later
> as we find more time.

Agreed. :)
Jungshik Shin wrote:
> Created an attachment (id=126980)
> a little more changes

The changes are OK, except one nit: The new document has UTF-8 encoding while
the old one had ISO8859-1 - can you attach a ISO8859-1 encoded version of the
file, please ?

> - I also removed the reference to 'Opentype' fonts because gfx/xprint doesn't
> do anything special with GSUB/GPOS tables present in opentype fonts for 
> complex scripts.  In theory, every "dumb" Truetype font is an Opentype font, 
> but when it's mentioned side by side with TrueType, most people would believe
> that GSUB/GPOS tables are made use of to render complex scripts. Please, 
> correct me if either Xprint module or Xprinte server does use GSUB/GPOS.

Currently Mozilla's Xprint module has no support for GSUB/GPOS; but the Xprint
server side will have it at the time the whole STSF support lands in the
xprint.mozdev.org CVS tree.
> can you attach a ISO8859-1 encoded version of the file, please ?

 I wouldn't :-)  It was intentionally tagged as in UTF-8  because it's I18N
notes (I think I need to do what I always 'preach', switch to UTF-8 asap).

Currently, there is NOT a single character outside the repertoire of US-ASCII so
that the whole document is in US-ASCII, ISO-8859-1, (and many other traditional
encodings compatible with US-ASCII) and UTF-8 at the same time. However, in the
future it might include some characters outside US-ASCII or ISO-8859-1 and using
UTF-8 is the best choice(needless to say, I can use NCRs in US-ASCII). If your
concern is that it takes the default Unix(Linux) binary too long (about a minute
or two on some system with a lot of fonts) simply because it's tagged as UTF-8,
I'd switch to US-ASCII (that is as neutral as UTF-8)  

> Currently Mozilla's Xprint module has no support for GSUB/GPOS

  It's the release notes and we shouldn't say Mozilla supports what it doesn't
yet, should we?  

Jungshik Shin wrote:
> > can you attach a ISO8859-1 encoded version of the file, please ?
>
> I wouldn't :-)  It was intentionally tagged as in UTF-8  because it's I18N
> notes (I think I need to do what I always 'preach', switch to UTF-8 asap).

My concern is that all other documents are in ISO-8859-1 for now and we should
keep that unless we really make use of chars outside ISO-8859-1 (consistency).

> Currently, there is NOT a single character outside the repertoire of US-ASCII 
> so that the whole document is in US-ASCII, ISO-8859-1, (and many other 
> traditional encodings compatible with US-ASCII) and UTF-8 at the same time. 
> However, in the future it might include some characters outside US-ASCII or 
> ISO-8859-1 and using UTF-8 is the best choice(needless to say, I can use NCRs
> in US-ASCII). If your
> concern is that it takes the default Unix(Linux) binary too long (about a 
> minute or two on some system with a lot of fonts) simply because it's tagged 
> as UTF-8, I'd switch to US-ASCII (that is as neutral as UTF-8) 

I still can't understand what's the problem with ISO8859-1... it is as "neutral"
as "US-ASCII"... :)

> > Currently Mozilla's Xprint module has no support for GSUB/GPOS
>
> It's the release notes and we shouldn't say Mozilla supports what it doesn't
> yet, should we?

Mhhh, no... :) I just copied the text from the older release notes and didn't
thought about the different between TrueType and OpenType.
> My concern is that all other documents are in ISO-8859-1 for now and we should
> keep that unless we really make use of chars outside ISO-8859-1 (consistency).

 I'd say it should be the other way around(that is, all the other documents
should not use ISO-8859-1) for the reason I'm giving below. Needless to say, I'd
not insist that all of them should be modified overnight, but int'l release
notes should be a good start. 

> I still can't understand what's the problem with ISO8859-1... it is as "neutral"
> as "US-ASCII"... :)

  There's a big difference between them. US-ASCII is the common denominator of
virtually all encodings used on the web while ISO-8859-1 is not. ISO-8859-1 is
certainly Western-Euro-centric. On the other hand, US-ASCII is the foundation
for national versions of ISO-646.  I'm aware that ISO-8859-1 is the charset the
web started with, but that doesn't make it as neutral as US-ASCII. (namewise, 
it's the other way around.. I'm tempted to use '646' in place of US-ASCII...)
For the log:
I have checked-in the current version that we have something online for now
(I've used ISO8859-15 like used in all the other release notes docs, see my
question below about the US_ASCII charset code):
% cvs commit -m 'New international release notes for Mozilla1.4 final per bug
206550 (http://bugzilla.mozilla.org/show_bug.cgi?id=206550 - "Revise Mozilla
Intl Release Notes for Mozilla 1.4")'
Checking in known-issues-int.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4/known-issues-int.html,v  <-- 
known-issues-int.html
new revision: 1.5; previous revision: 1.4
done

Jungshik Shin:
Dumb question: Do you know the correct HTML charset for US-ASCII (various pages
seem to use stuff like "us-ascii", "usascii", "ascii", "us_ascii", etc.) ?
Another ToDo item:
- We need a sepcial section for "euro" support or at least quote which parts of
mozilla support the euro symbol and which not.
Jungshik Shin wrote:
> > My concern is that all other documents are in ISO-8859-1 for now and we 
> > should
> > keep that unless we really make use of chars outside ISO-8859-1 
> > (consistency).
>
> I'd say it should be the other way around(that is, all the other documents
> should not use ISO-8859-1) for the reason I'm giving below. Needless to say, 
> I'd not insist that all of them should be modified overnight, but int'l 
> release notes should be a good start. 

;-/

Personally I would prefer if we could stay with the current de-facto default for
mozilla.org pages (ISO8859-1/ISO8859-15) unless the pages really contain many
chars outside that range.

> > I still can't understand what's the problem with ISO8859-1... it is as 
> > "neutral"
> > as "US-ASCII"... :)
>
> There's a big difference between them. US-ASCII is the common denominator of
> virtually all encodings

Mhhh, without searching deeply in my memory I could list at least 50 encodings
which do not match that criteria. Did you never make a survey or what ? :))

> used on the web while ISO-8859-1 is not. ISO-8859-1 is
> certainly Western-Euro-centric.

Yeah, and currently it is much more Euro-centric since we use ISO8859-15 for the
release notes (and not ISO8859-1 as I had in mind) ... =:-)
> Do you know the correct HTML charset for US-ASCII?

  It's  MIME charset. Anyway, it's Us-AsCii, US-ASCII, us-ascii, us-ASciI
(case-insensitive).


 >  Mhhh, without searching deeply in my memory I could list at least 50 encodings
> which do not match that criteria. Did you never make a survey or what ? :))

  It's easy. Just go to the IANA charset registry and go through the list of
charsets registered. I didn't modify 'all encodings' with 'used on the web' and
'virtually' without a reason. A better alternative would be to  go through the
list in charsetaliases.properties (intl/uconv/src) file and tell me which of
them is not ASCII compatible (those marked as 'notforbrower' in
charsetdata.properties don't count). How about the number of charsets compatible
with either ISO-8859-1 or ISO-8859-15.

For sure, I can easily come up with over 50. For that matter, most national
variants of ISO 646 are different from US-ASCII at one or more code points. For
instance, ISO-646:JP (JIS X 201) has 'YEN' sign at 0x5c instead of reverse
solidus. (Danish nat'l variant of ISO 646 has a few code points replaced
according to Stroustrup). How many of them are actually used on the web _by
themselves_?

> currently it is much more Euro-centric since we use ISO8859-15

  This is bad for a web browser which has to be one of the most int'lized
programs and is even worse for the int'l release notes. 


> Personally I would prefer if we could stay with the current de-facto default for
> mozilla.org pages (ISO8859-1/ISO8859-15) unless the pages really contain many
> chars outside that range.

Current Mozilla.org pages do not specify any charset and that has been 
the long standing policy (perhaps due to some reload bug we used to 
have the in the browser.)
The release notes pages except the intl section don't seem to be
using any charset declaration, either. 

If we are going to specify the charset at all, let's use UTF-8.
ISO-8859-x charsets cannot accommodate the range of characters we
may need to be using in the notes in the not so long distant future.

> Another ToDo item:
> - We need a sepcial section for "euro" support or at least quote which parts of
> mozilla support the euro symbol and which not.

We probably should have a short paragraph if we have bugs in the Euro
support but not sure about a special section. Not a problem as far as I can
see on Win or Mac OS X. On Linux, we may have font support issues left.


If I can add my two small-denomination coins here, I don't think consistency is
a consideration. All HTML documents are consistently in the ISO-10646 character
set by definition, and I don't see any necessity to aim for consistency of
source encoding.

If we are concerned about UTF-8 documents being rendered in a different font and
giving an inconsistent _look_ to the documentation, we can add a "lang" attribute.
I can't agree with Simon more. That's exactly what I think. As for 'lang', my
drafts have the 'global' lang declared (<html lang="en"> or <body lang="en">)
[1], but it seems like somehow it's dropped/lost when it's automatically wrapped
with the header and the footer (for mozilla.org) by 'the document processing
system'(?) of mozilla.org. Either we have to 'fix' it to keep the lang tag in
html/body intact or have to work around it. Perhaps we can work around it by
sth. like the following:

<html>
<head>......</head>
<body>
<div lang=..>
.... acutal contents....
</div>
</body>
</html> 

[1] I did that partly because I wrote in the int'l release notes that it's
always a good idea to specify 'lang' in html/xml with 'lang'/'xml:lang'. 

When releasing 1.4 i18n rel. notes, I just mentioned that there are issues 
with  the cursor (caret) movement and text selection for complex text scripts 
without listing bugs. Here are the list: 
 
bug 79286, bug 115171, bug 85420, bug 100173, bug 122552, bug 157534, bug 
203406, bug 65896 
 
After reading the 1.4 release notes I think having a general printing section
would be better than hiding the details under "International Release" ...

momoi:
What do you think ? Should I create a general "Printing" section ? That would
offload all the printing bloat in the intl release notes to it's own, seperate
page...
Roland, there is already a printing section under General:

http://www.mozilla.org/releases/mozilla1.4/known-issues.html#printing

Are you proposing to add items under this section? Or do you want to take
items out of there and combine with the ones in the intl section into
a new section?

It is true that much of the PostScript items can belong to a genreal section.
But these are also items that non-English users are typically concerned
about and often they read the international section first.  

How about a compromise? Leave the items in the intl section but add
1-line item in the general section, e.g. There is additional info on 
PostScript printing in the international section ...
Depends on: bidi_relnotes
This is diff against the current 1.5b intl. rel. notes, which will be the basis
for 1.5 intl. rel. notes. I removed a couple of resolved problems, fixed a
couple of typos and added a few bug references. If there's no objection, I'll
commit it by Thursday. BTW, if there's any new item to add, let me know.
Would the notes in bug 154625 be added to these notes?
Could you tell me which ones you'd like to add among the listed in bug 154625?
Are all of them current?
Summary: Revise Mozilla Intl Release Notes for Mozilla 1.4 → Revise Mozilla Intl Release Notes
1.7 release notes should mention the change in the behaviour of "+" "-" and "/"
in combination with right-to-left text and numbers, following Unicode 4.0.1 (bug
73251 comment 46 and following)
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: