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)
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}
Updated•22 years ago
|
Status: NEW → ASSIGNED
Updated•20 years ago
|
Product: MailNews → Core
Comment 1•17 years ago
|
||
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
Comment 3•16 years ago
|
||
Simon, can you or someone else check this and bug 102954? No response from reporter
Keywords: intl
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 4•15 years ago
|
||
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.
Description
•