mixed charsets in header creation (forward inline)

VERIFIED FIXED in M16

Status

defect
P3
normal
VERIFIED FIXED
20 years ago
11 years ago

People

(Reporter: nhottanscp, Assigned: nhottanscp)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

20 years ago
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*.
Assignee

Comment 1

20 years ago
qa contact to momoi.
QA Contact: lchiang → momoi
Assignee

Comment 2

20 years ago
Assignee

Comment 3

20 years ago
Putting beta2 since we need this for localized builds.
Keywords: beta2

Comment 4

20 years ago
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

20 years ago
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.
Assignee

Comment 6

20 years ago
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

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

- rhp
Assignee: rhp → nhotta
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M16

Updated

19 years ago
Keywords: nsbeta2
Assignee

Updated

19 years ago
Keywords: beta2

Comment 8

19 years ago
"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.

Updated

19 years ago
Depends on: 34083

Updated

19 years ago
No longer depends on: 34083

Updated

19 years ago
Blocks: 34083
Assignee

Comment 9

19 years ago
checked in yesterday
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

Comment 10

19 years ago
** 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.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.