Bug 210606

+++ This bug was initially created as a clone of Bug #203058 +++

Description of problem:
I can see the korean in the contact text box.
but when I add korean into TO, it shows Wrong words.

Version-Release number of selected component (if applicable):
evolution-2.7.4-4
scim-1.4.4-29.fc6
scim-hangul-0.2.2-6.fc6

How reproducible:
allways

Steps to Reproduce:
1. Make New mail and Click TO button
2. make korean contact like ê³ ì¢ë°°<jko>
3. click Add button
  
Actual results:
?UTF-8?Q?=EA=B3=A...

Expected results:
ê³ ì¢ë°° or ê³ ì¢ë°°<jko>

Additional info:

-- Additional comment from jko on 2006-08-18 00:09 EST --
Created an attachment (id=134422)
before add to TO


-- Additional comment from jko on 2006-08-18 00:10 EST --
Created an attachment (id=134423)
after click Add button


-- Additional comment from majain on 2006-09-14 05:43 EST --
> Steps to Reproduce:
> 1. Make New mail and Click TO button
> 2. make korean contact like ê³ ì¢ë°°<jko>
> 3. click Add button

Hi,

Is it reproducible with any korean input? I'm asking because I'm not able to add
your address as i dont have LDAP setup. Is there any other way to reproduce this
bug?

Thanks,
Mayank

-- Additional comment from majain on 2006-09-14 05:45 EST --
Can you please recheck this bug with evolution-2.8.0-1.fc6 or above versions &
report the findings?

Thanks,
Mayank

-- Additional comment from majain on 2006-09-14 06:04 EST --
Ok, verified, this bug is still there in evolution-2.8.0-1.fc6. Removing the
NEEDINFO flag. Re-assigning the bug to myself.

-- Additional comment from majain on 2006-09-14 06:05 EST --
Changing version to devel.

-- Additional comment from jko on 2006-09-14 20:05 EST --
This bug is included CJK. I test with Korean, Chinese and Japanese on
evolution-2.8.0-1.fc6

-- Additional comment from majain on 2006-09-18 09:28 EST --
From initial investigation...

this is how the control moves
e-d-s -> add_destination (EDestinationStore *destination_store, EContact
*contact, gint email_n)

-- Additional comment from majain on 2006-09-19 01:25 EST --
Confirmed, this happens with indic contacts also.
Checked with a contact in hi_IN language.

-- Additional comment from majain on 2006-09-25 06:46 EST --
$e-d-s/libedataserverui/e-name-selector-dialog.c:transfer_button_clicked is used
to transfer contacts from source to destination

-- Additional comment from majain on 2006-09-25 07:29 EST --
$e-d-s/libedataserverui/e-name-selector-dialog.c:destination_column_formatter
might be one function to concentrate on.

-- Additional comment from majain on 2006-09-25 08:18 EST --
Exact reason of bug...

contact_column_formatter - does correct rendering because it generates the names
which are added to the GtkTreeView by using g_strdup_printf

destination_column_formatter - does NOT works because it generates the names
(which are added to destination GtkTreeView) bu using e_destination_get_address
function, which in turn uses camel_address_encode (or internet_encode) to mess
up the encoding of names.

Hence, IMHO this bug can be fixed from two viewpoints...

1) Either continue the method used in contact_column_formatter - ie, use
g_strdup_printf to create the addresses.
2) or modify Camel's internet_encode function to return with proper encoding &
hence a viable address which can be added to the destination box.

But since camel_address_encode looks like an overloaded function, i'd suggest
that following (1) would be a better option as just fixing internet_encode wont
help. All the overloader functions need to be fixed.

Besides, Camel is not in the scope of this bug.

**Changing component to evolution-data-server.

-- Additional comment from majain on 2006-09-25 08:27 EST --
The function that does the final blow... camel_header_encode_phrase

-- Additional comment from majain on 2006-09-25 11:32 EST --
Created an attachment (id=137058)
Patch for solving problem related to i18n text in contacts

I modelled destination_column_formatter on the basis of how
contact_column_formatter is implemented.

-- Additional comment from majain on 2006-09-25 11:34 EST --
Matthew, before actually building this patch into rawhide, can you please give
it a quick check... specially with actually sending an email on live internet.

Thanks,
Mayank

-- Additional comment from majain on 2006-09-25 11:35 EST --
Changed bug description to a more meaningfull heading.

-- Additional comment from majain on 2006-09-27 10:11 EST --
One straight forward way to solve this bug would have been to implement 

case EVC_ENCODING_QP:
			g_warning ("need to implement quoted printable decoding");
			break;

in function 
GList*
e_vcard_attribute_get_values_decoded (EVCardAttribute *attr)

-- Additional comment from mbarnes on 2006-09-27 13:32 EST --
Mayank, the patch produces this block of logic:

    if (e_destination_list_show_addresses (destination)) {
            const gchar *name;

            name      = e_destination_get_name (destination);

            string = g_strdup_printf ("%s", name ? name : "?");
    } else {
            string = g_strdup (e_destination_get_name (destination));
    }

Can this be simplified?  How important is the question mark when name is NULL?

Maybe something like:

    name = e_destination_get_name (destination);
    if (name == NULL && e_destination_list_show_addresses (destination))
            name = "?";
    string = g_strdup (name);


-- Additional comment from majain on 2006-09-28 03:56 EST --
Hi Matthew,

I just replicated the functionality of source_column_formatter (the function
above destination_column_formatter). 

I have no issues with either of them... but for the sake of consistancy, i'd
suggest that either both functions should be changed or both should be kept
same... or the different logic might confuse other developers.

Your pick Matthew... i'm just concerned with getting the bug fixed. :)
You are the maintainer... choose the best way :)

BTW... I think both code segments act seemingly in the same way. :) Nice finding!

-- Additional comment from majain on 2006-10-03 07:09 EST --
Matthew, this bug is related to different components.

The patch #14 is fro e-d-s
The next patch in #20 will be for evo
Then another one will be for evo.

Should we file new bugs for evo components?

As seen here... http://bugzilla.gnome.org/attachment.cgi?id=67834&action=view
The bug in "contact list selector" dialog box is from e-d-s
The bug in "List Preview" is for evo

Matthew... what say?

-- Additional comment from majain on 2006-10-03 07:36 EST --
Created an attachment (id=137639)
Patch for list preview

Patch as mentioned in #19, patch is for Evo

-- Additional comment from majain on 2006-10-03 07:52 EST --
> Patch as mentioned in #19, patch is for Evo

This line should be read as...

Patch as mentioned in #20, patch is for Evo


-- Additional comment from majain on 2006-10-06 03:53 EST --
Created an attachment (id=137901)
patch for enabling display of i18n mail ID's in the addressbook

This patch completely solves this bug.

-- Additional comment from majain on 2006-10-06 03:55 EST --
Over to you Matthew :)

-- Additional comment from majain on 2006-10-06 04:47 EST --
Created an attachment (id=137905)
new patch as per guidelines - for evo

patch for enabling display of i18n mail ID's in the addressbook

-- Additional comment from majain on 2006-10-09 02:33 EST --
Created an attachment (id=138026)
Updated patch


-- Additional comment from mbarnes on 2006-10-12 15:08 EST --
(In reply to comment #20)
> Should we file new bugs for evo components?

Yes, please move the Evolution patch to a new bug.  That way we can track it
easier for RHEL5.  Bug #208805 doesn't include the Evolution stuff.