Closed
Bug 531403
Opened 15 years ago
Closed 14 years ago
No German quotatation marks are shown any longer in the mail
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: gmmail2000-bugzilla, Unassigned)
Details
(Keywords: testcase)
Attachments
(6 files)
User-Agent: Opera/9.64 (Windows NT 5.1; U; de) Presto/2.1.1
Build Identifier: Thunderbird 2.0.0.23 German
When typing German quotation marks with Alt-0132 „ or Alt-0148 “ they are shown in the email. However when I try to send the email there is a message and these signs are not sent in the email. I made no changes in coding. I was able to send those signs in the email before.
Reproducible: Always
Comment 1•15 years ago
|
||
Can you :
* write an email and send it containing those signs ?
* save the send version as .eml and attach it here (using the add an attachment link above)
* save the received and attached it here too ?
Version: unspecified → 2.0
| Reporter | ||
Comment 2•15 years ago
|
||
The German signs „ and ” are not shown correctly.
| Reporter | ||
Comment 3•15 years ago
|
||
Signs „ and ” arenot shown properly
| Reporter | ||
Comment 4•15 years ago
|
||
Mesage sent with ISO-8859-1: The signs are shown properly
| Reporter | ||
Comment 5•15 years ago
|
||
Mesage received with ISO-8559-1: Signs are shown properly
| Reporter | ||
Comment 6•15 years ago
|
||
Settings
| Reporter | ||
Updated•15 years ago
|
Attachment #415027 -
Attachment description: Mesage received ISO-8859-15 → Message received ISO-8859-15
| Reporter | ||
Updated•15 years ago
|
Attachment #415029 -
Attachment description: Mesage sent with ISO-8859-1 → Message sent with ISO-8859-1
| Reporter | ||
Updated•15 years ago
|
Attachment #415032 -
Attachment description: Mesage received with ISO-8559-1 → Message received with ISO-8559-1
| Reporter | ||
Comment 7•15 years ago
|
||
Message appearing before sending
Updated•15 years ago
|
Attachment #415015 -
Attachment mime type: application/octet-stream → text/plain
Updated•15 years ago
|
Attachment #415027 -
Attachment mime type: application/octet-stream → text/plain
Updated•15 years ago
|
Attachment #415029 -
Attachment mime type: application/octet-stream → text/plain
Updated•15 years ago
|
Attachment #415032 -
Attachment mime type: application/octet-stream → text/plain
Comment 8•15 years ago
|
||
> Message sent with ISO-8859-15
> Mesage received ISO-8859-15
> Signs „ and ” arenot shown properly
Content-Type: text/plain; charset=ISO-8859-15; ...
With any View/Character Encoding:
"Hallo2"
> Mesage sent with ISO-8859-1
> Mesage received with ISO-8559-1
> Signs are shown properly
Content-Type: text/plain; charset=windows-1252; ...
With View/Character Encoding=windows-1252:
„Hallo4”
> Message appearing before sending
What did you answer to the dialog?
Did Tb send the mail in iso-8859-15 or windows-1252 even though you requested to send in UTF-8?
Comment 9•15 years ago
|
||
ISO-8859-1/ISO-8859-15 doesn't have mapping of 0x84/132, 0x94/148 to U+201E, U+201D, although windows-1252 have such mapping.
> http://en.wikipedia.org/wiki/ISO/IEC_8859-1
> http://en.wikipedia.org/wiki/ISO/IEC_8859-15
> http://en.wikipedia.org/wiki/Windows-1252
If you requested not to send in UTF-8 at the dialog when you composed the mail in ISO-8859-15, i.e. you requested to send data for U+201E, U+201D in ISO-8859-15, Tb or OS probably mapped them to 0x22(" in us-ascii) to avoid garbled display and/or wrong binary data in ISO-8859-15 data.
Comment 10•15 years ago
|
||
(In reply to comment #0)
> Build Identifier: Thunderbird 2.0.0.23 German
> I was able to send those signs in the email before.
Which build do you mean by "before"?
Patch for Bug 448842 was landed on Tb 2.0.0.x branch and worked with de version or on iso-8859-15?
Comment 11•15 years ago
|
||
gmmail2000-bugzilla could answer to comment #9 and comment #10, please?
Keywords: testcase
Whiteboard: closeme 2009-12-30
| Reporter | ||
Comment 12•15 years ago
|
||
(In reply to comment #10)
With Thunderbird Version 2.0.0.14 it was able to send the signs without getting the comment.
> (In reply to comment #0)
> > Build Identifier: Thunderbird 2.0.0.23 German
> > I was able to send those signs in the email before.
>
> Which build do you mean by "before"?
> Patch for Bug 448842 was landed on Tb 2.0.0.x branch and worked with de version
> or on iso-8859-15?
Updated•15 years ago
|
Whiteboard: closeme 2009-12-30
| Reporter | ||
Comment 13•15 years ago
|
||
(In reply to comment #9)
I ignored the message (button on the right). I cannot see whether the signs
were mapped.
> ISO-8859-1/ISO-8859-15 doesn't have mapping of 0x84/132, 0x94/148 to U+201E,
> U+201D, although windows-1252 have such mapping.
> > http://en.wikipedia.org/wiki/ISO/IEC_8859-1
> > http://en.wikipedia.org/wiki/ISO/IEC_8859-15
> > http://en.wikipedia.org/wiki/Windows-1252
> If you requested not to send in UTF-8 at the dialog when you composed the mail
> in ISO-8859-15, i.e. you requested to send data for U+201E, U+201D in
> ISO-8859-15, Tb or OS probably mapped them to 0x22(" in us-ascii) to avoid
> garbled display and/or wrong binary data in ISO-8859-15 data.
Comment 14•15 years ago
|
||
(In reply to comment #12)
> With Thunderbird Version 2.0.0.14 it was able to send the signs without getting the comment.
You wrote next for mail of "Content-Type: text/plain; charset=windows-1252;".
> Mesage sent with ISO-8859-1
> Mesage received with ISO-8559-1
> Signs are shown properly
Did you change default character encoding for mail compisition from windows-1252 to iso-8859-1 or iso-8859-15?
Comment 15•14 years ago
|
||
gmmail2000-bugzilla, please, could you answer to comment #14?
Whiteboard: [closeme 2011-01-25]
| Reporter | ||
Comment 16•14 years ago
|
||
(In reply to comment #15)
> gmmail2000-bugzilla, please, could you answer to comment #14?
Default is iso-8859-1. It is working now with the right quotation marks.
Comment 17•14 years ago
|
||
WFM per comment #16
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-01-25]
You need to log in
before you can comment on or make changes to this bug.
Description
•