572182 - German umlaut searching for email addresses could be improved to find alternate spellings

Status: NEW

(Thunderbird :: Address Book, enhancement)

Description

[Mitra Ardron]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.4) Gecko/20100527 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100526 Lanikai/3.1.1pre

German umlauts are often entered wrongly in emails, especially when working between english and German speakers - for example Jürgen might appear as Jurgen or Juergen (the former being incorrect, the latter being correct transcription to English).

It would improve searches I believe if searches could handle this better, e.g. a search query for Jurgen should offer someone in the address book as Jürgen or Jurgen as an option (or even the totally incorrect Jüergen ). 

Different software does this with differing levels of effectiveness, for example OSX Address book searches for Jurgen return Jürgen (and vica-versa), but a search for Juergen won't.

Reproducible: Always

Steps to Reproduce:
1. Enter an address book entry Jürgen Schmidt
2. Start a message
3. Type Jurgen and it will NOT auto-complete



This is similar, but not the same, as Bug 563717 which refers to incorrect searching. 

There are probably names in other languages where there is a non one-to-one transliteration with english characters which would have the same problem?

Comment 1

[Wayne Mery (:wsmwk)]

this would be an interesting feature. .I'm not in a position to judge, but I wonder if we can gauge how useful it would be?

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=umlaut&field0-0-0=short_desc&short_desc_type=allwordssubstr&type0-0-0=nowords&resolution=---&resolution=INVALID&resolution=WONTFIX&product=MailNews%20Core&product=Thunderbird

Comment 2

[Thomas D. (:thomas8)]

Thumbs up, this makes perfect sense. -> Recommending confirmation of this RFE. This problem will affect TB users from all over the world who correspond with folks with German names, where umlauts are common. Searching for such names is all but impossible from an English keyboard layout. Try entering u-umlaut in your TB search to see what I mean. This is not a deal-breaker, but it's a worthwhile usability issue.
If other languages are also affected, we might want a standardized way of specifying alternate spellings, maybe even an API.

Although I'd think other autocomplete bugs like 405190 and 445175 should be fixed as a matter of priority by the power of 10, as they are serious workflow breakers in daily usage for an assumedly very large number of users.

Comment 3

[Mitra Ardron]

I think we have two related issues 
1: Specific problems - e.g for Umlaut's, and I suspect French accents have the ame problem where even if its possible to enter the key (e.g. on a Mac its Option-U U to get  german umlaut) 99% of people won't know how to and don't need EXCEPT to find someone in their address book. 

2: Generic problem of alternate (character coding) and incorrect spelling. 

A long time ago there as an english database program where search was done using a phonetic transliteration. i.e. an index was made of this special coding, and searching was done against that. It was surprisingly good and was popular among people managing databases of people etc (especially if doing customer support over the phone).  because even in English its often unclear how a name is spelled when you just know what it sounds like. 

If I remember right - the API was fairly simple and looked something like, whenever a word was stored in an index it was passed through the filter to obtain the canonical (in this case phoentic) coding, and when anything was searched against the index it was also passed through this filter first.

Comment 4

[Thomas D. (:thomas8)]

Missing links from comment 2
The bugs that should take priority are bug 405190 and bug 445175.

Comment 5

[D. Beijer]

still a problem; "daniel" doesnt bring up "daniël" in the autocomplete

Comment 6

[Wayne Mery (:wsmwk)]

bug 1042681 has more detailed discussion