After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 251062 - Evolution 2.5.x does not support Thai
Evolution 2.5.x does not support Thai
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.6.x
Other All
: Normal normal
: Future
Assigned To: Harish Krishnaswamy
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2003-11-17 09:28 UTC by Kitt Tientanopajai
Modified: 2013-09-13 00:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to enable Thai/TIS-620 support (1.38 KB, patch)
2003-11-17 09:30 UTC, Kitt Tientanopajai
needs-work Details | Review
updated, untested patch to enable Thai/TIS-620 support (2.88 KB, patch)
2005-08-28 12:20 UTC, André Klapper
reviewed Details | Review
test message (1.78 KB, text/plain)
2006-03-01 05:48 UTC, Theppitak Karoonboonyanan
  Details
test message (1.78 KB, text/plain)
2006-03-01 05:51 UTC, Theppitak Karoonboonyanan
  Details
The UTF-8 version, for comparison (1.64 KB, text/plain)
2006-03-01 06:01 UTC, Theppitak Karoonboonyanan
  Details
test mail, without encoding header (1.54 KB, text/plain)
2006-03-02 14:27 UTC, Theppitak Karoonboonyanan
  Details
test message, incorrectly encoded as iso-8859-1 (1.56 KB, text/plain)
2006-03-02 14:40 UTC, Theppitak Karoonboonyanan
  Details
Sample mail - ISO-8859-1 (2.31 KB, text/plain)
2006-03-02 16:09 UTC, Kitt Tientanopajai
  Details
Sample mail - the whole message (78.27 KB, text/plain)
2006-03-03 03:00 UTC, Kitt Tientanopajai
  Details

Description Kitt Tientanopajai 2003-11-17 09:28:01 UTC
Evolution 1.4.x does not support Thai and TIS-620 charset. Thus, mail
component and the others could not display Thai characters.
Comment 1 Kitt Tientanopajai 2003-11-17 09:30:01 UTC
Created attachment 43079 [details] [review]
patch to enable Thai/TIS-620 support
Comment 2 Gerardo Marin 2003-11-17 19:41:43 UTC
kitt: you must submit your patch to evolution-patches@ximian.com for
review.
Maybe you have to subscribe to that list. To do so, check
http://lists.ximian.com
Comment 3 André Klapper 2005-08-27 19:03:47 UTC
reassigning to harish; patch needs rework, still missing in current cvs (evo
version 2.3.8)
Comment 4 André Klapper 2005-08-28 12:20:59 UTC
Created attachment 51458 [details] [review]
updated, untested patch to enable Thai/TIS-620 support

updated patch of the former, obsolete one (camel location changed to e-d-s)
Comment 5 Jeffrey Stedfast 2005-10-20 15:59:31 UTC
the list of charsets in the table in camel-charset-map.c is not something that
should be changed without a lot of careful thought and testing because it is
very fragile. also, the charsets in that table must remain 8bit and not include
any multibyte.

The table has a very important order.
Comment 6 André Klapper 2005-11-14 23:56:50 UTC
so, jeff, any ideas? shall i revert harish's "accepted-commit_now" setting on
the patch?
Comment 7 André Klapper 2005-12-26 01:47:48 UTC
changing patch status to commented_on
Comment 8 Theppitak Karoonboonyanan 2006-02-04 01:46:29 UTC
TIS-620 is plain 8bit and not multibyte, for that concern.
Comment 9 André Klapper 2006-02-12 18:26:31 UTC
setting priority to urgent - we're heading string freeze.
i'd really like to see a conclusion to give thai people the ability to use evolution. :-/
Comment 10 Jeffrey Stedfast 2006-02-13 16:26:07 UTC
the e-charset-picker.c portion of the patch is fine and I'd recommend committing that portion.

However, the camel-charset-map.c part I'm unconvinced is necessary and is likely to introduce breakage (for example, Evolution might choose to encode something in TIS-620 instead of iso-8859-* or windows-cp125* which are much more common charsets)
Comment 11 André Klapper 2006-02-13 16:41:13 UTC
committed the UI part:
http://cvs.gnome.org/viewcvs/evolution/widgets/misc/e-charset-picker.c?r1=1.23&r2=1.24

need to discuss the camel-charset-map.c part.
Comment 12 André Klapper 2006-02-13 16:42:42 UTC
lowering priority a bit now.

thep, any chance to attach a sample thai message (please remove any confidential data before)?
Comment 13 André Klapper 2006-02-26 15:15:25 UTC
thep?

any progress? otherwise i have to outcomment the strings for evo2.6.
Comment 14 Theppitak Karoonboonyanan 2006-02-27 06:58:10 UTC
Sorry for replying late. My evo build just crashes too easily to test
anything. (For other evo patches, I can test their functionalities in
tiny seperate programs.) So, I ask Kitt (the bug reporter) to do that.

However, IMO, having TIS-620 in the menu should be enough for reading
TIS-620 encoded Thai mails. I guess the camel code is for character set
detection, right?
Comment 15 André Klapper 2006-02-28 09:55:24 UTC
thep: i have no idea of thai and i don't have a sample message. can you please test this?
gnome 2.14 is only 10 days ahead and i have to outcomment the string otherwise.
Comment 16 Theppitak Karoonboonyanan 2006-03-01 05:48:06 UTC
Created attachment 60372 [details]
test message

Please try this message.

Sorry again for the delay.
Comment 17 Theppitak Karoonboonyanan 2006-03-01 05:51:23 UTC
Created attachment 60373 [details]
test message

Please try this message.

Sorry again for the delay.
Comment 18 Theppitak Karoonboonyanan 2006-03-01 06:01:06 UTC
Created attachment 60374 [details]
The UTF-8 version, for comparison

Could you compare the apperance with this UTF-8 version?

Really, I wish I could start my evo build to test it myself. But there must be something wrong in my configuration. So, I have to ask for your help to test.
Comment 19 Kitt Tientanopajai 2006-03-02 11:30:22 UTC
I have only evolution 2.4.1 in my hand right now so I report this based on 2.4.1. 

AFAICT, evolution cannot display a TIS-620-encoded message correctly if its content is specified as ISO-8859-1. This kind of mails exists, I believe, because ISO-8859-1 is the default encoding for many mail clients. Thai people just use it to compose Thai messages, and somehow, it works fine for them.

The only way I can read such mails on evolution is to force to display as TIS-620. So, having TIS-620 in the encoding menu really helps.
Comment 20 André Klapper 2006-03-02 11:49:20 UTC
note for anyone testing this: one has to add one line, like
               From example@example.com Wed Feb 26 15:32:08 2004
to the beginning of those two examples messages so they can be imported into evolution.


both messages are displayed absolutely perfectly here (evo 2.5.92), i did not had to change anything (ok, my character encoding setting is set to default, but of course it also works when chossing tis-620)!

that's very cool. :-)

so kitt, thep, how to proceed further? do you think this bug is fixed, or is anything still missing? "WORKSFORME". :-)
Comment 21 André Klapper 2006-03-02 11:50:42 UTC
kitt: any example message handy for the case you're describing that you could attach here (please remove confidential data before)? thanks in advance.
Comment 22 Theppitak Karoonboonyanan 2006-03-02 14:27:23 UTC
Created attachment 60493 [details]
test mail, without encoding header

Oops, I forgot to change the encoding header before posting. It was perfectly correct mail and needed no enforcing, thus not suitable test case. Please try this one instead.
Comment 23 Theppitak Karoonboonyanan 2006-03-02 14:40:16 UTC
Created attachment 60494 [details]
test message, incorrectly encoded as iso-8859-1

Simulating Kitt's case. Maybe, Kitt can also provide a real one.
Comment 24 Kitt Tientanopajai 2006-03-02 16:09:24 UTC
Created attachment 60504 [details]
Sample mail - ISO-8859-1

This is an example of mail that I have to select TIS-620 from encoding menu to read it. Actually, it has 3 parts, I cut two of them and provide only text/plain.
Comment 25 André Klapper 2006-03-03 01:42:14 UTC
whilst i can view thep's two example mails without any problems (YEEHAH! well, after manually setting the character encoding to tis-620), i am unable to view kitt's mail. perhaps it has been mangled when you set the mime type to "application/octet-stream" instead of "text/plain" by accident? hard to say. :-/

kitt, i also doubt that it's a valid mail since you've cut it - it says "Content-Type: multipart/mixed" at the beginning, but the second bounty in the message body is obviously missing. can you provide a complete one and add the correct mime type? thanks very much in advance... :-)
Comment 26 Kitt Tientanopajai 2006-03-03 03:00:03 UTC
Created attachment 60526 [details]
Sample mail - the whole message

This is the whole message of the previous. I 'save as' and change only the sender/cc to example@example.com.
Comment 27 André Klapper 2006-03-03 08:25:26 UTC
kitt, except for the subject it works.
hmm.
Comment 28 André Klapper 2006-03-03 08:28:08 UTC
the header is broken, see the source: "X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char C3 hex) in message header 'Subject': Subject: ..."

so... closing as fixed?
Comment 29 Theppitak Karoonboonyanan 2006-03-03 11:54:11 UTC
According to your test results, the bug seems to be fixed. Although the correct encoding detection for the case of unspecified encoding (by the patch to camel?) might be another benefit, but let's do it in later versions.
Comment 30 André Klapper 2006-03-03 12:22:17 UTC
ok, great so far. thanks everybody for your patience, and have fun with evolution-2.6 then :-)
Comment 31 Jeffrey Stedfast 2006-03-03 15:21:12 UTC
the camel charset table is for outgoing encodings only, it is not applied to inbound email.