34666 - mixed charsets in header creation (forward inline)

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[nhottanscp]

In mimedrft.cpp, a function (mime_intl_insert_message_header_1) is appending 
string resources (in UTF-8) to a body (in mail charset).
This does not work once the strings are localized.
We need to convert body to unicode before appending localized strings.

I wrote a patch to convert body to UTF-8 (same charset as string resources). But 
this requires extra conversion between PRUnichar* to UTF-8.
Other possible solution is to separate header and body creation to reduce 
charset conversion for body. Or make functions to use PRUnichar* instead of 
char*.

Comment 1

[nhottanscp]

qa contact to momoi.

Comment 2

[nhottanscp]

Attachment: patch to convert body to UTF-8

Comment 3

[nhottanscp]

Putting beta2 since we need this for localized builds.

Comment 4

[rhp (gone)]

Naoki,
So do you want me to apply this patch? Is there any reason you don't want to 
take care of this yourself?

- rhp

Comment 5

[Katsuhiko Momoi]

Let me add for localization purposes that:

1. We should have this fixed for languages which want to
   locliaze these strings.
2. We need to make sure that localized strings will never
   go out to the net except as part of a mail body.
3. Localizers should have an option not to translate these
   MIME related strings.This is because some users may prfer not
   to translate them in case they want to send msgs to people
   who don't read their language.

Comment 6

[nhottanscp]

If performance is critical for this operation (forward inline) then my patch 
needs to be rewritten. If no need to rewrite the patch then I will take this 
bug. I believe conversion between UTF-8 and PRUnichar* is not slow (we sends 
UTF-8 to layout and it is converted to PRUnichar*) but the conversion needs to 
allocate more memory.
If the patch need rewrite then I need to do more extensive change in the code. 
If it's okay to do that change then I can take this bug (but I may need some 
help).

Comment 7

[rhp (gone)]

forwarding inline is not the most common operation in the world, so I would go 
with your fix for now.

- rhp

Comment 8

[Katsuhiko Momoi]

"Forward as inline" is a very common operation among Japanese
users. What users often do when they get "plain text" info from
someone, e.g. new product info, they then simply forward it
inline so that recipients can see where taht info originated
in plain text format quickly. We had a group of serious
intl bug in 4.x time frame fo forward inlien and most of them
came from Netsdcape Japan customers.

Comment 9

[nhottanscp]

checked in yesterday

Comment 10

[Katsuhiko Momoi]

** Checked with 5/30/2000 Win32 build **

A series of MIME headers now can be translated in
mime.properties file.
In PR1, we saw diamond shapes rather than real character
when these characters were 8-bit. In the build above,
I see correct Japanese characters.

Marking the fix verified.