GNOME Bugzilla – Bug 600389
UTF8 characters in contacts not shown properly
Last modified: 2010-06-08 09:41:09 UTC
Testing with 0.28.0-1 in Fedora 12 beta In the Contacts view norwegian characters don't display correctly. Samme issue that used to be with Email headers, sender names, etc... They are now ok. It's starting to come together. :-)
related to bug 598564
Correct. There is a downstream bug report about the same: https://bugzilla.redhat.com/show_bug.cgi?id=573955 The reporter also claims he cannot create a contact with UTF8 letters included, so let's have it here together with the fetch issue (I guess both are closely related anyway).
I also tried adding tasks, memos (notes) and calendar entries with unicode characters and all failed. I don't have any non-English entries of those types in my account so I can't verify how it looks but I'm assuming that the same problem in the contacts (which I understand also happened in e-mail) is probably in all data types and should be fixed globally.
Created attachment 156360 [details] [review] proposed ema patch for evolution-mapi; This is a patch to have it read/write values properly, but it requires a change in openchange as well, because my workaround on ema side didn't work. (See the other attachment.)
Created attachment 156361 [details] proposed oc patch for openchange; The problem with GetPropsAll, which addressbook is using, is that it always requests non-unicode strings. This patch adds an API to openchange to set on a mapi_session a flag what is the application expecting. The above ema patch requires this one applied to behave properly (and actually to compile too). This is just one possibility how to achieve the needed. There shouldn't be much problem to adapt ema patch if OpenChange developers will use different approach.
Thanks for the patch! Is there a bug report for OpenChange were we can vote for this feature or some other way that we can help apply presure on OpenChange to resolve this quickly (hopefully in time for Fedora 13) ? I looked in the OpenChange Trac but counldn't find something related (OTOH I don't handle Trac well).
It's too late for F13, as it'll be part of OpenChange 0.10 or later, which will not be backported in F13 for sure. I wanted to add it to their Trac, but I do not have an account there, and I didn't find a way how to create it. Last time I asked, Kerihuel told me that they removed account creation because of spammers (if I recall correctly). So I sent an email (actually two) to their devel list, which apparently didn't receive it yet. Maybe it's waiting in a moderation queue, as I'm not subscribed to the list.
Created attachment 158631 [details] [review] ema patch ][ for evolution-mapi; Even without change in openchange, though I hope I didn't break more than I fixed. Let's see.
Created commit 7e71d71 in ema master (0.31.1+) Created commit ef1663c in ema gnome-2-30 (0.30.1+)
Oh, I forgot to mention, I tried to avoid call of GetPropsAll, and ema is using unicode props where-ever possible, thus should be fine. The only problem is that this requires more attention from developers, when adding new properties to calendar/addressbook, that also the array of known properties should be updated, otherwise it'll not be fetched. he other benefit is it's fetching less information from the server know, so should be theoretically quicker. I still do not know how this fits to distribution lists, but will see in the other bug.
*** Bug 606842 has been marked as a duplicate of this bug. ***