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*.

qa contact to momoi.

Putting beta2 since we need this for localized builds.

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

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.

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).

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

"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.

checked in yesterday

** 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.