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 206386 - Searches containing 8-bit characters broken
Searches containing 8-bit characters broken
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other All
: Normal normal
: ---
Assigned To: Not Zed
Evolution QA team
Depends on: 216733
Blocks:
 
 
Reported: 2001-08-04 20:25 UTC by Kjartan Maraas
Modified: 2013-09-10 13:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kjartan Maraas 2001-08-04 20:25:41 UTC
If I search for a string containing 8-bit characters in the search bar
above the message list it looks like it disregards the 8-bit chars.

searching on "él" turns up messages from Ismael, so it looks like it treats
é as e
Comment 1 Jeffrey Stedfast 2001-08-04 21:28:54 UTC
this is intentional, we currently decompose (is that the right word?)
8bit chars so that the match is a little more flexible.

I guess if this isn't the desired effect, we could change it.

Now, if you search for "él" and messages that it should match don't
come up, then that would be a bug.

I'm not gonna close this bug because perhaps we should decompose text,
I feel it's a nice thing but if it's not the expected/desired effect,
perhaps we shouldn't? I dunno.

dawn? ettore? what do you guys think?
Comment 2 Dan Winship 2001-08-06 16:25:54 UTC
This was done intentionally, as you said.

If we were going to change it, I'd suggesting asking on the list
(and maybe gnome-i18n-list) for opinions.
Comment 3 leedjarv 2001-08-30 11:56:32 UTC
I agree with Kjartan, this is not the desired effect. For example, if
I search for öö I don't want to find oo. Most non-English languages
have diacritic characters and we don't want to search them without
diacritics.
Comment 4 Not Zed 2001-10-05 01:08:32 UTC
i'm not sure if this is a 1.0 bug.

searches are approximate at best anyway, with most peole's spelling
abilities.
Comment 5 Kjartan Maraas 2001-10-05 19:23:10 UTC
Yeah. Blame it on the users, that works :)
Comment 6 Not Zed 2001-10-19 22:58:03 UTC
naah i'm just saying that you need to fuzzify any search string you
use when searching.

It also reduces the size of the indexes we generate for body indexed
folders.

Having said all that, not decpomosing is an easy fix, but i dont think
we have time do decide what's best for 1.0, so i'm marking 1.1 (if
someone strongly disagrees of course that could change)


Comment 7 Luis Villa 2001-11-26 17:04:41 UTC
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be
moving a large number of bugs around in the bugzilla. You can just
search on 'body contains' 'Because of the decision to remap' and mark
all as read. Please direct all questions about this change to
evolution@ximian.com, not the bug.
Luis

Comment 8 Not Zed 2001-12-09 22:55:40 UTC
making it part of indexing 'rewrite'
Comment 9 Not Zed 2002-03-26 01:03:28 UTC
This should be fixed, but i'm not sure, i dont think it'll handle case
properly for example ...

Can anyone confirm?  You need HEAD.
Comment 10 Kjartan Maraas 2002-03-26 20:36:39 UTC
It seems to work for me. I searched for "påske" which got me two
matches  - namely "påsken" and "Påskeferie". On the other hand, if I
search for "PÅSKE" it finds no matches.
Comment 11 Gerardo Marin 2002-03-26 22:15:04 UTC
Cool.  Can we close this?
Comment 12 Not Zed 2002-04-25 05:30:36 UTC
I'd say its fixed ...