Closed
Bug 139615
Opened 22 years ago
Closed 17 years ago
Return receipt is not displayed correctly on a localized build
Categories
(MailNews Core :: Internationalization, defect)
MailNews Core
Internationalization
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 335534
People
(Reporter: ji, Assigned: Bienvenu)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: l12y, Whiteboard: [adt2])
Attachments
(5 files, 1 obsolete file)
5.23 KB,
text/plain
|
Details | |
174.17 KB,
image/jpeg
|
Details | |
11.73 KB,
patch
|
bugzilla
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
85.57 KB,
image/jpeg
|
Details | |
3.31 KB,
patch
|
Details | Diff | Splinter Review |
This is originally filed as netscape internal bug: http://bugscape.netscape.com/show_bug.cgi?id=14209 On a Ja build, the return receipt is displayed as dots. Steps to reproduce: 1. On a Japanese build, from mail account manager, configure your mail account to receive a return receipt after sending. 2. Send yourself a message. 3. Observe the Japanese return receipt after received
Nominating for nsbeta1, since it will affect all the localized build.
Comment 3•22 years ago
|
||
Several places need changes. * provide two sets of strings, English and localized strings * get "X-Accept-Language:" of the original message * map lang to charset (need new intl service) * get a charset of the original subject header if MIME encoded * if both charsets matches then use the localized string and MIME encode the header using the charset * also use the charset for Content-Type:, this is for the body In the current code, * folder charset is used - need to change to the mechanism mentioned above http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#956 * localized string for the subject from property is corrupted by the lossy conversion - need charset conversion and MIME encode http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#569 * localized string for the body from property is corrupted by the lossy conversin - need charset conversion http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#629
Status: NEW → ASSIGNED
Comment 5•22 years ago
|
||
Impact language users- European users and Asian users- 325.9M (51.8% ) of internet users are not using English will hit this issue. Severity- we will generate the garbage return receipt when the text are localized. It won't crash, won't hang Visibility- This is a feature mainly for enterprise only. Major feature in enterprise. User work around- None nsbeta1+ [adt2]
Comment 6•22 years ago
|
||
This needs more investigation. For now, I will put "do not translate" comment in the property file.
Comment 7•22 years ago
|
||
Comment 8•22 years ago
|
||
MDN spec - http://www.ietf.org/rfc/rfc2298.txt
Comment on attachment 80889 [details] [diff] [review] Adding a comment not to translate strings in the file. Please add "# LOCALIZATION NOTE:" at the beginning of the comment.
Attachment #80889 -
Flags: review+
Comment 10•22 years ago
|
||
I filed bug 140080 for the localization comment change.
Comment 11•22 years ago
|
||
http://www.ietf.org/rfc/rfc2298.txt 3. Format of a Message Disposition Notification That is talking about the part which we do not localize. --------------mdn050903030708040903080406 Content-Type: message/disposition-notification; name="MDNPart2.txt" Content-Disposition: inline Content-Transfer-Encoding: 7bit Reporting-UA: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020412 Netscape6/6.2.1+ Final-Recipient: rfc822; nhotta@netscape.com Original-Message-ID: <3CC5EACE.1090801@netscape.com> Disposition: manual-action/MDN-sent-manually; displayed For the part we localize and having the problem does not seem to be mentioned in the spec (except in section 9.1 which is an example but it uses English). The same is true for the subject header. So I assume that part is optional. The spec does not mention about checking sender's language or charset. I think because the part we localize is not part of the spec. --------------mdn050903030708040903080406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ....nhotta@netscape.com ................ ........................................................................................................
Assignee | ||
Comment 12•22 years ago
|
||
I thought the subject part was fixed.
Comment 13•22 years ago
|
||
The patch in bug 136805 fixes the problem for the original subject which is included as a part of the subject of the receipt. The localized string in the header is still corrupted by NS_LossyConvertUCS2toASCII() and not MIME encoded. Currently, we are investigating what charset to be used for the receipt subject or we might use English for subject and localized strings for the body.
Comment 14•22 years ago
|
||
ccing myself and Jeff.
Comment 15•22 years ago
|
||
The only thing you need to translates is the first part not the second part or the third. If you do translate the second part you are sort of violating the standard. The first part is human readable explantion of MDN. As for the second part it meant for machine readable/processable. You cannot translate those headers in the second part.
Comment 16•22 years ago
|
||
Thanks Jeff, we understand that the second and the third part should not be translated. We are investigating what to do for the first part (and the subject header).
Comment 17•22 years ago
|
||
Here is how it works on 4.x according to some people explained to me. * match sender's "X-Accept-Language:" against receiver's localized language One problem of this is that the original subject header is used for the return receipt. That may not be MIME encoded using the charset which is used for the localized subject string. For example, the original message subject is MIME encoded with ISO-8859-1 while the charset used for the localized subject (to prepend to the original subject) is ISO-2022-JP. What we have for that case is a subject which MIME encoded as two different charsets. Some mailers (include 4.x) has display problem with that kind of headers. To avoid that, we need to check the charset of the original subject in addition to the language matching. Alternative (and simpler) way is to always use English for the subject string (e.g. "Return Receipt (displayed)" and for the body add localized string before or after the English string. I think this is acceptable because there are chances that the returned receipts are sent in English anyway due to the lang/charset checking explained above. I would prefer a consitant return receipt subject than sometimes localized and sometimes English.
Comment 18•22 years ago
|
||
I tried OutlookExpress JA. When I sent Japanese message, it returned the receipt in Japanese (subject and body). When I sent Latin1 message, it returned the receipt in English (subject and body). I sent the original messages using the branch build my accept lang was 'en'. It looks like OE does not care about sender's accept language but checks for the charset of the message (subject or body or both). I cannot find MDN support for Eudora.
Comment 19•22 years ago
|
||
>I cannot find MDN support for Eudora.
Now I found it. Tried Eudora JA, both subject and body are English (not
localized) for the return receipt. The one I tried was a free version.
Updated•22 years ago
|
Attachment #80889 -
Attachment is obsolete: true
Comment 20•22 years ago
|
||
> It looks like OE does not care about sender's accept language but
> checks for the charset of the message (subject or body or both).
Need to check OE localized for European language.
Comment 21•22 years ago
|
||
Here is what the http://www.ietf.org/rfc/rfc1892.txt said about the first part: (1) [required] The first body part contains human readable message. The purpose of this message is to provide an easily-understood description of the condition(s) that caused the report to be generated, for a human reader who may not have an user agent capable of interpreting the second section of the Multipart/Report. The text in the first section may be in any MIME standards-track content-type, charset, or language. Where a description of the error is desired in several languages or several media, a Multipart/Alternative construct may be used. This body part may also be used to send detailed information that cannot be easily formatted into a Message/Report body part. So... we may want to use muiltipart to put the description of several langauge there. For example, the English localization may only put English in the first part. The Japanese localization may put both English and Japanese translation in the first part.
Comment 22•22 years ago
|
||
Multipart/Alternative, I think most mailers (including Mozilla) does use charset or language in the header to select what to display. We can append/prepend the localized string in the first part in addition to the English string.
Comment 23•22 years ago
|
||
> think most mailers (including Mozilla) does use charset
> or language in the header to select what to display
Correction, does NOT use charset or language ...
Comment 24•22 years ago
|
||
I did some testing using French OE 6. I got different type of receipts (French or English) depends on the subject charset of the original message. I got English receipt when the original subject charset was ISO-2022-JP or KOI8-R. I got French receipt when the original subject charset was ISO-8859-1 or UTF-8 or us-ascii (i.e. not MIME encoded).
Comment 25•22 years ago
|
||
Here is a proposal for enabling localized return receipt. * No localization for subject header: * checking sender's charset (OE's implementaion) is not enough to select appropriate language * using sender's language may not encode the original subject properly * checking both charset and language make it very complicated (both implementation and the usability) * 4.x does send header as English. * Body (in the first part) may contain localized string if available in addition to the English string: * English string is always included which can be shown without depending the user's environment (e.g. font). * Localized string can be seen if the user is capable display/read it, otherwise can be just ignored. Please write to this bug if you have comments to the proposal.
Comment 26•22 years ago
|
||
Changed to append localized strings to the first part. Changed to determine the transfer encoding based on the actual first part data. Changed m_charset to C string and get it from the default pref instead of a folder charset which can change.
Comment 27•22 years ago
|
||
Comment 28•22 years ago
|
||
Comment on attachment 82058 [details] [diff] [review] Changed to append localized strings to the first part. R=ducarroz. It's kind of wierd that the function named GetLocalizedFirstPart in fact return first and second part! maybe you should consider a better name.
Attachment #82058 -
Flags: review+
Comment 29•22 years ago
|
||
No, it returns the first part only. The first part is composed with two strings. "This is a Return Receipt for the mail that you sent to %S." and "Note: This Return Receipt only acknowledges that the message was displayed..." It corresponds with the original code. http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#452 447 nsresult nsMsgMdnGenerator::CreateFirstPart() 448 { 449 DEBUG_MDN("nsMsgMdnGenerator::CreateFirstPart"); 450 char *convbuf = nsnull, *tmpBuffer = nsnull; 451 char *parm = nsnull; 452 nsXPIDLString firstPart1; 453 nsXPIDLString firstPart2;
Assignee | ||
Comment 30•22 years ago
|
||
Comment on attachment 82058 [details] [diff] [review] Changed to append localized strings to the first part. sr=bienvenu, yes, the original code had those poorly named variables
Attachment #82058 -
Flags: superreview+
Comment 31•22 years ago
|
||
It's not clear to me what you're using as a trigger to send a localized message. It is the charset of the 1st MIME part or is it the accept-language? or both?
Comment 32•22 years ago
|
||
Please see comment #17 and the screen shot id=82059 > * Body (in the first part) may contain localized string if available in addition > to the English string: This is independent from language and charset. The localized string is always appended after the English string.
Comment 33•22 years ago
|
||
>Please see comment #17 and the screen shot id=82059 Correction, comment #25 instead.
Comment 34•22 years ago
|
||
Even if the message is not in the language that matches localization? So we will be sending out localized return receipts no matter what language sender prefers?
Comment 35•22 years ago
|
||
Please see comment #25 > * Body (in the first part) may contain localized string if available in addition > to the English string: > * English string is always included which can be shown without depending the > user's environment (e.g. font). > * Localized string can be seen if the user is capable display/read it, > otherwise can be just ignored. also comment #21 > So... we may want to use muiltipart to put the description of several langauge > there. For example, the English localization may only put English in the first > part. The Japanese localization may put both English and Japanese translation > in the first part. > and comment #17 > Alternative (and simpler) way is to always use English for the subject string > (e.g. "Return Receipt (displayed)" and for the body add localized string before > or after the English string. I think this is acceptable because there are >
Comment 36•22 years ago
|
||
Reading comment #35 leads me to believe that this patch will create the following MIME structure: =========================================== Content-Type: multipart/report; report-type=disposition-notification; boundary="------------mdn166A68D8DC731E946CCD4496" --------------mdn166A68D8DC731E946CCD4496 Content-Type: multipart/alternative; boundary="------------mdn0000000000000000000" --------------mdn0000000000000000000 Content-Type: text/plain; charset=usacii Content-Transfer-Encoding: 7bit This is a Return Receipt for the mail that you sent to ... --------------mdn0000000000000000000 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit ... (Japanese receipt message) ... =========================================== point 1: This structure is what seems to be implied by RFC 1892 and RFC 2046. When using multipart-alternative, you need to indicate the importance of each part so that the receiving agent knows which one to display. For example, currently Mozilla displays the last of the multipart alternative if you send html and plain text parts. Also if all the parts have equal meaning, then the Content-ID fields should have the same value. Question: Are we doing this in this patch? If you are following RFC 1892, then that should be the case. In other words, both languages should not be showing. Only one language. That shoudl be the meaning of multipart-alternative. point 2: I think it is awkward to send mixed language data to any mail msg requesting a return receipt. Most mailers do not send x-accept lang header. If we pay attention to accept-language, we can then send back localized MDN only to Mozilla-based mailers and the English one to all others which do not send accept-language header. This may be a desired result. We should not force the user's language on people who indicate no language preference or preference in languages other than user's preferred language. If you want to broaden this coverage, you can also send a localized message to those people who send a message in the language of user's localization. The comment in #35 implies that the patch is consistent with RFC 1892. In that case, only one of the 2 language messages should be showing. The attached image shows 2 languages. I don't believe this should be the case.
Comment 37•22 years ago
|
||
Yes, absolutely. We should implement multipart/alternative for the first part. This put us more standard compliant.
Comment 38•22 years ago
|
||
>Reading comment #35 leads me to believe that this patch >will create the following MIME structure: nhotta said this is not the case. His patch will only generate one part , it won't generate multipart alternative. >Question: Are we doing this in this patch? No. That is NOT the case. > If you are following RFC 1892, > then that should be the case. No. That is not what RFC1892 said. RFC 1892 only said there are a way to do that. It does not said people "should"/"have to"/"must" do that. It is clearly out of the scope of RFC1892. It only mention the possibility >Here is what the http://www.ietf.org/rfc/rfc1892.txt >... > Where a description of the > error is desired in several languages or several media, a > Multipart/Alternative construct may be used. It said "may be" used, not "must be" used. Nhotta had expressed his opinion why we should not do that. And It won't violate RFC1892 because it is not what rfc1892 defined, but it is only what rfc1892 mentioned. >The comment in #35 implies that the patch is consistent with RFC 1892. The patch IS consistent with RFC 1892. But RFC 1892 does not imply the mailer should use multipart/alternative. It only said it may use it. > I think it is awkward to send mixed language data to any mail > msg requesting a return receipt. They are not MIXED language data. They are multiple translation of the same information. IT is different from said information A in English and then said information B in Japanese. I think it is awkward to send only English langauge data between Japanese users to any mail msg requesting a return receipt. That mean no localization in this part. I think it is awkward to send only Japanese langauge data between Japanese and non-Japanese users to any mail msg requesting a return receipt What is the problem of sending BOTH English and localized translation in one part? What problem could it cause? If a japanese user send mail to japanese users and ask for receipt (regardless what mailer s/he is using), s/he will get both english/japanese back. and they will understand it. If an English user send mail to japanese users and ask for receipt (again, regardless what mailer s/he is using), s/he will get both english/japanese back. and they will understand it. Let's move on. We should not spend too much time on this issue.
Comment 39•22 years ago
|
||
The other problem with the statemetn in RFC is the following >Where a description of the error is desired in several languages >or several media, a Multipart/Alternative construct may be used. It is ok from MIME point of view to use multipart/alternative with several media, because we could label the media type with primiary type and sub type in Content-Type . It is ALSO ok from MIME point of view to use multipart/alternative with the same translation of message in different charset (say Japanese in both UTF-8 and ISO-2022-JP) because we can use the "charset" parameter in Conten-Type to label it. However, in order to label different languages data in multipart/alternative, we need to make sure most mailer implement the content-language in http://www.ietf.org/rfc/rfc1766.txt In particular, we need to make srue mozilla understand Content-Language and understand Content-Type: multipart/alternative; differences=content-language nhotta, please file a bug about RFC 1766 support. RFC 1766 is in the standard track so I think we should consider implement it. I propose we take naoki's current approach as short term solution for now. (Mean year 2002 Q2) and implement the multipart/alternative way after mozilla can handle RFC 1766 in general .
Comment 40•22 years ago
|
||
> I propose we take naoki's current approach as short term solution for now.
I would like us to review feedback comments on the behavior
proposd after this patch goes in. I have misgivings about sending
out 2 language MDN indiscriminately. I would also like to see how
mailers other than Outlook Express, NN4 and Mozilla deal with this.
Comment 41•22 years ago
|
||
> I have misgivings about sending
> out 2 language MDN indiscriminately. I would also like to see how
> mailers other than Outlook Express, NN4 and Mozilla deal with this.
Do you want me to check in or you want to do the investigation first?
When can you complete your investigation and provide the result?
If you do not like the current patch and want me to revert it later, I would
prefer waiting for the investigation result.
Comment 42•22 years ago
|
||
fang, nhotta, I am concerned about CJK builds sending out bilingual return msg to anyone requesting an MDN. If the sender/requester is a Mozilla/NS6 users, will he or she not get a dialog prompt to download fonts -- even though this sender simply sent a return receipt request? (Have we decided to disable font download dialog for mail?) Would it not be better and less likely to cause trouble to the requester if we tried the following instead? Send out a localized msg only in your non-US build only if: 1. The sender is indicating a prefence for that language as the first choice in the accept-language header for Mozilla/NS6. (No other mailers seem to send x-accpet-language header excpet perhaps NS Mail servers. So this solution is specific to Netscape/Mozilla.) or 2. The sender sent a msg which contains a (primary) MIME part with the charset matching that of receiver's localized language. So if a user sends an MDN requesting msg in Japanese, the receiver can return a Japanese return receipt if he/she is using a Japanese language build. 3. In all other cases, send out the default English return receipt. It is true that English is another localization but it is a fairly well accepted common language of the Internet and most users will not have a problem with it.
Comment 43•22 years ago
|
||
What about Latin 1/Latin 2/Cyrillic cases which represent many languages? How do we apply point 2 above? I am inclined to send back the default English one to such users. This means that these multi-language encoding users will get an MDN in their own language only if they send a specific language request via something like an accept-language. I think this is an OK result. The fact of the matter is that we don't have a standard in indicating preference of language in MDN request. Until such a standard is established, we can assume that ASCII only MDN in English would be the common format. Many mail severs send out only English error msgs. It will not be a surprise to any Internet mail users to get an English MDN from Mozilla/NS 6. If we have any problem with this state of affairs, then we should be proposing a standard to set a language preference in MDN requests.
Comment 44•22 years ago
|
||
> What about Latin 1/Latin 2/Cyrillic cases which represent > many languages? How do we apply point 2 above? I am inclined to > send back the default English one to such users. Please see my comment #24 of the French OE's behavior. OE sends French localized string even if the original message is not French (e.g. German, Spanish). I did some research for OE and Eudora (comment #18, comment #19, comment #24) before proposing comment #25. I did not propose to implement the OE's behavior because it does not work well for the cases like Latin1. With the current patch, it is up to each localization to decide localize the string or not. If the strings are not localized then only English would be sent (4.x, Eudora always send English only). >I would also like to see how > mailers other than Outlook Express, NN4 and Mozilla deal with this. Momoi san, could do the research you mentioned in your comment #40? I tried a Japanese e-mail client "Becky" which supports MDN. It returns English in the first part (actually, it may mix English and other language because it quotes the original subject in the first part body), see the example below. Return-Path: <> Received: from judge.mcom.com ([205.217.237.53]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GVK1D900.21Z for <nhotta@dredd.mcom.com>; Fri, 3 May 2002 14:36:45 -0700 Received: from sushi ([10.169.97.113]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GVK1D900.JJQ for <nhotta@netscape.com>; Fri, 3 May 2002 14:36:45 -0700 Date: Fri, 03 May 2002 14:37:09 -0700 From: Naoki Hotta <naoki2@netscape.com> To: Naoki Hotta <nhotta@netscape.com> Sender: <> Subject: Read Receipt for =?ISO-2022-JP?B?IhskQiRGJEMkOSRIGyhCIBskQiRZJEMkLRsoQg==?= =?ISO-2022-JP?B?MiI=?= Message-Id: <20020503143703.B722.NAOKI2@netscape.com> In-Reply-To: <3CD3036F.9030503@netscape.com> References: <3CD3036F.9030503@netscape.com> MIME-Version: 1.0 Content-Type: multipart/report; report-type="disposition-notification"; boundary="------_3CD302FFB7220195E788_MULTIPART_REPORT_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 --------_3CD302FFB7220195E788_MULTIPART_REPORT_ Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit ** Read Receipt ** This message "$B$F$C$9$H(B $B$Y$C$-(B2" was opened by "Naoki Hotta <naoki2@netscape.com>" on Fri, 03 May 2002 14:37:03 -0700. This is, however, no guarantee that the message has been read or understood. --------_3CD302FFB7220195E788_MULTIPART_REPORT_ Content-Type: message/disposition-notification Content-Disposition: inline Content-Transfer-Encoding: 7bit Final-Recipient: rfc822;naoki2@netscape.com Original-Message-Id: <3CD3036F.9030503@netscape.com> Disposition: manual-action/MDN-sent-manually; displayed --------_3CD302FFB7220195E788_MULTIPART_REPORT_--
Comment 45•22 years ago
|
||
I would like to ask taka for his opinion on this. I believe he worked on NN4.51 spec for this.
Comment 46•22 years ago
|
||
Sending English only MDN is safe, but not so user friendly. Sending English/L10N mixed MDN probably works for most of users and probably better than English only message. If Accept-language header exists, we can send MDN in user's preferred language more safely. We don't have to ship all the localized resource with a distribution. We should be able to pull appropriate language version from ftp.mozilla.org when needed.
Comment 47•22 years ago
|
||
Just curious... What about backward and compatibility issues with Netscape 4.x, Outlook Express and Eudora? How would this shows up on 4.x, OE, or Eudora? Can users of those display them well? Chances are users of 4.x, OE or Eudora can request return receipts from mozilla 1.0/Netscape 6.2.x recipients.
Comment 48•22 years ago
|
||
There were some requests for multipart/alternative solution and indicated that would be more standdard complient (comment #36, comment #37). The proposal by Frank (comment #39) was about the solution using multipart/alternative with langage tag. I would like to know if that propose has been agreed. I am getting confused by the proposal of using the accept language. Is that proposed as a temporary solution or it is an alternative proposal for the multipart/alternative solution?
OS: Windows 2000 → All
Hardware: PC → All
Comment 49•22 years ago
|
||
Let me respond to the question about accept-language vs mutlipart/alternative. These two are more or less independent of each other although they can interact with each other. What I prefer is that if a sender/requester somehow indicates language preference, we should try to honor it. (Other mailers currently do not indicate language preference in mail header, but having Mozilla use this method could urge other mailers to adapt this method. I hope that Mozilla approach will eventually spread to other mailers.) So, let me describe 2 possible ways to use accept-language. One proposal does not use mutlipart alternative, the other one does. Proposal 1: Send non-English MDN back only if the accept-language of the requester matches the localization resource of the receiver, or if the request msg is in a charset which points to a single language. All other cases will use English MDN. Under this proposal MDN will always be in one language only and does not use multipart/alternative. This is a modified NN4 approach -- NN4 does not cover the single language per charset case. Proposal 2: Send non-English MDN back if the accept-language of the requester matches the localization resource of the receiver, if the request msg is in a charset which points to a single language. This MDN is in one language and does not use multi-part alternative. Send multipart alternative NDN as proposed above by ftang/nhotta if the condition in the 1st paragraph does not hold. In this case, the MDN receiver may have a chance to apply its lang preference. In both proposals, the use of the accept-language or the charset info in a msg (except multi-laguage charset like Latin 1 & 2) will let us best match the requester's expectation of language if that resource is available. Otherwise, we send a bilingual MDN using multipart/alternative and let the MDN receiver have a chance to choose one or the other.
Comment 50•22 years ago
|
||
I do not understand why using accept language has to be prefered over the solution suggested by RFC. Is that because Mozilla and 4.x mail send it?
Comment 51•22 years ago
|
||
If you are talking about RFC 1766, that's because almost none of MUA is using Content-Language header including Mozilla/Netscape implementation. Besides, it's meant to be used for representing the language of content, not a user's language preference.
Comment 52•22 years ago
|
||
>Besides, it's meant to be used for representing the language of content,
>not a user's language preference.
The sender of thetreturn receipt can specify the language of content then the
content to display can be selected based on the receiver's preference.
Comment 53•22 years ago
|
||
I think this is not urgent matter. Many MUA sends English return receipt. Nominating again for evaluation.
Comment 55•22 years ago
|
||
Currectly, the file has a localization note says: # LOCALIZATION NOTE: Do not translate anything in this file - see bugzilla bug 139615. But I think that's not true, for example, with "MsgMdnWishToSend" un-translated, the confirm dialog will show English message: The sender of this message has asked to be notified when you read this message. Do you wish to notify the sender? Please clean this file with proper l10n notes, and show us each one that really can not be translated at this moment. Thanks.
Comment 56•22 years ago
|
||
Ying, I reopened bug 140080.
Updated•22 years ago
|
Target Milestone: --- → mozilla1.2alpha
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → ---
Comment 60•21 years ago
|
||
Hello - and be a bit patient to me. My english isn't good and I do not understand much about RFCs and such things. So I might be wrong here, but I think I found at least something related to 'my' problem. What happened? I made a test with mozilla (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.5) Gecko/20031007). I sent a 'boomerang-mail' (just one returning directly to myself) and selected a return receipt. This worked, but the 'answer' is not displayed as it should. You can easily see the problem if you do this: 1. tell mozilla to use a non-standard(?) character encoding (I've UTF-8). 2. prepare a short mail to yourself. You should place some 'special characters' (non-ASCII) in it - even in the subject. 3. request for a return receipt 4. send it. The receipt carries the UTF-8 characters, but it is 'standard windows' here. If I select the windows-1252 charset, the mail and its parts are shown correct (as far I have seen). What should be done? Could the return receipt be made to use the original character encoding? This should match the senders capabilities.
Updated•20 years ago
|
Product: MailNews → Core
Comment 61•20 years ago
|
||
UA: Win32 French Thunderbird 1.0 When a TB10 send a french encoded return receipt, this is with a wrong codification for the subject: TB10: Subject: =?UNKNOWN?Q?Accus=E9_de_r=E9ception_=28affich=E9=29_-?= Re: NS47: Subject: =?iso-8859-1?Q?Accus=E9?= de =?iso-8859-1?Q?r=E9ception?= ( =?iso-8859-1?Q?affich=E9?=) - Re: NS47 and Outlook Express seem to use their default page code to display the RR's subject, the display may then be OK in these software. So TB10 don't do that and it displays RR's subject like "Sujet: ? Re:" in place of "Sujet: Accusé de réception (affiché) - Re:" because it seems to not use its default page code. Thanks
Comment 62•19 years ago
|
||
Hi everyone! i read all comments of this bug, but i still does not understand - why i can not use 2 langs return receipt in TB 1.0 ? can somebody add this patch in TB 1.1 ? i tryed to localized the subject by adding win 1251 charset in it (in MdnDisplayedReceipt - e.g. "=?windows-1251?Q?=XX=XX=XX?=") and it works, but how i can localized the message body? can someone answer to me please? why it so difficult to supports other encoders type, except 7bit encoding in message body? please let users to solve in what code and language write the return receipts! p.s. sorry for my english...
Comment 63•19 years ago
|
||
*** Bug 263709 has been marked as a duplicate of this bug. ***
Comment 64•18 years ago
|
||
*** Bug 325767 has been marked as a duplicate of this bug. ***
Comment 65•18 years ago
|
||
*** Bug 334433 has been marked as a duplicate of this bug. ***
Comment 66•18 years ago
|
||
Anything new here? Do we have any sign of solution?
Updated•18 years ago
|
Assignee: nhottanscp → smontagu
Status: ASSIGNED → NEW
QA Contact: marina → internationalization
Comment 67•18 years ago
|
||
Just made a brazilian portuguese version to the file. Here it worked perfectly.
Comment 68•17 years ago
|
||
> Just made a brazilian portuguese version to the file. Here it worked perfectly.
You're sending unencoded non-ASCII characters in the subject which is illegal.
Assignee | ||
Comment 69•17 years ago
|
||
see 335534 - it has a patch for some of these issues.
Assignee | ||
Comment 70•17 years ago
|
||
taking bug - for linkification, that's bug 335534
Assignee: smontagu → bienvenu
Assignee | ||
Comment 71•17 years ago
|
||
marking as dup
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•