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:
Created attachment 134422 [details] before add to TO
Created attachment 134423 [details] after click Add button
> 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
Can you please recheck this bug with evolution-2.8.0-1.fc6 or above versions & report the findings? Thanks, Mayank
Ok, verified, this bug is still there in evolution-2.8.0-1.fc6. Removing the NEEDINFO flag. Re-assigning the bug to myself.
Changing version to devel.
This bug is included CJK. I test with Korean, Chinese and Japanese on evolution-2.8.0-1.fc6
From initial investigation... this is how the control moves e-d-s -> add_destination (EDestinationStore *destination_store, EContact *contact, gint email_n)
Confirmed, this happens with indic contacts also. Checked with a contact in hi_IN language.
$e-d-s/libedataserverui/e-name-selector-dialog.c:transfer_button_clicked is used to transfer contacts from source to destination
$e-d-s/libedataserverui/e-name-selector-dialog.c:destination_column_formatter might be one function to concentrate on.
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.
The function that does the final blow... camel_header_encode_phrase
Created attachment 137058 [details] 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.
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
Changed bug description to a more meaningfull heading.
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)
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);
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!
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?
Created attachment 137639 [details] Patch for list preview Patch as mentioned in #19, patch is for Evo
> Patch as mentioned in #19, patch is for Evo This line should be read as... Patch as mentioned in #20, patch is for Evo
Created attachment 137901 [details] patch for enabling display of i18n mail ID's in the addressbook This patch completely solves this bug.
Over to you Matthew :)
Created attachment 137905 [details] new patch as per guidelines - for evo patch for enabling display of i18n mail ID's in the addressbook
Created attachment 138026 [details] Updated patch
(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.
Bug 210606 - filed for evo.
Thanks Mayank.
You are welcome Matthew :)
Mayank, While looking over your patch some more, I noticed that e-vcard.c in evolution-data-server might be a more appropriate place for your quoted printable string decoder. There's even some placeholders in the code to guide you: case EVC_ENCODING_QP: g_warning ("need to implement quoted printable decoding"); break;
Hi Matthew, The patch in #14 solves this bug. I think this can be closed & that related to evo can be continued in bug 210606. Thanks, Mayank
Right, I posted comment #31 to the wrong bug. Actually I just noticed that you had the same observation in comment #17. D'oh! Fixed in evolution-data-server-1.9.2-2.fc7.
Thanks :)