Closed Bug 105389 Opened 23 years ago Closed 15 years ago

Enable auto-completion for First names in CJK

Categories

(MailNews Core :: LDAP Integration, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: momoi, Unassigned)

Details

(Keywords: intl)

** Observed with 10/17/2001 Win32 trunk and branch builds **

Currently we are NOT able to auto-complete against First name
data with some LDAP servers if the language is one of 
Chinese, Japanese, or Korean. For example, this is true
if LDAP servers used are Netscape DS 3.1 and later.

Yet, first name auto-completion works against non-CJK entires.

I noticed this problem when looking at Bug 101086. 
Even though I did not have time to look at this issue
during 0.9.4 branch period, I think we should come up
with a solution to this problem for the next NS release
time frame. 

1. First and foremost, not being able to auto-complete against
   first name is simply incorrect. (This might have been 
   4.x behavior also. But in any case, we have a chance to 
   correct this problem now.)

2. The reason that we cannot do so is bacause currently we
   are auto-competing against 2 default attributes:

   cn  (common name)
   sn   (surname)

   For languages in which the cn order is First Last, completing
   against these 2 attributes will let you have search
   against First and Last Names.

   But for CJK languages, the cn order is Last First. So if we
   are searching for cn and sn in CJK and if we don't do 
   non-word initial matching, then for CJK, we are searching
   aginst only Last names!

3. This is incorrect since any CJK users know that effective
   searching/auto-completing against native CJK names is
   finding a rarer word-initial character. For some people, you 
   know the first name will get you a quick match rather than
   the last name character, and vice versa.

   Thus current implemenattion is not practical for the
   auto-completion behavior CJK users will want. And besides
   not letting CJK user use First name as the search key is 
   incorrect anyway.

4. Some LDAP servers, e.g. Netscape servers, let administrators
   enter First name and Last name and then automatically fill in
   the Full Name (i.e. cn). For CJK names, the auto-fill in 
   is Last - First order. For non-CJK names, auto fill-in would
   produce First - Last order. So, the current Mozilla behavior
   is not good when we consider how LDAP server data base creation
   works for CJK names. 

I would like to suggest a few possible ways to correct this problem.

Proposal 1:

Use 3 attributes **always** w/ no UI control:

cn (common name)
givenname (given name)
sn (surname)

Propsal 2:

Use only 2 attributes w/ no UI control:

cn (common name) + sn for non-CJK scripts
cn + givenname for CJK scripts

Proposal 3:

Create an UI item to let user choose any comibinations
(1-3 items) among the 3 or possibly limit the choice to cn and 
one of givenname or sn.

{cn | givenname | sn}   OR 
cn AND {givenname OR sn}   

Personally I like option 3 best. This is because we don't 
probably always know if LDAP servers create search data for
some attributes. I believe it is unlikely that servers 
holding CJK data will neglect to generate givenname search
data. Nonetheless, it would be best to give users a choice. 

My personal favorite is: cn AND {givenname OR sn}
Status: NEW → ASSIGNED
QA Contact: yulian → gchan
Product: MailNews → Core
Assigning bugs that I'm not actively working on back to nobody; use
SearchForThis as a search term if you want to delete all related bugmail at
once.
Assignee: dmose → nobody
Status: ASSIGNED → NEW
is this still a problem?
QA Contact: grylchan → ldap-integration
Simon, can you or someone else check this and bug 102954?  No response from reporter
Keywords: intl
Product: Core → MailNews Core
Currently we are searching using such filter
Filter: (|(|(|(mail=*nikolay*)(cn=*nikolay*))(givenName=*nikolay*))(sn=*nikolay*))
It will find name in spite of first name or last name are cn starts from.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.