There still is no viable solution to this problem, so it doesn't make 
sense to raise the priority.

may be it is worth to cinsider raising of the importance from low to 
medium or even High as Horde seems to be used quite a lot in 
non-English speaking countries.

even if I manage to get Latvian alphabet in alphaPager.inc and it is 
displayed, the links represented by ?, ?, ? etc are not working, 
returning "A"-s page instead.

I looked at database records and found that the info is stored not as 
UTF8 but Latin1 (???) - may be that is one of possible reasons. What 
surprises me is that search is working OK.

Unfortunately, this solution does not fit to Latvian, plus, ir removes 
almost all ASCII characters.

Add second patch, because only one patch can be added at one time

I have done (partly) this issue, but it is only "quick hack" and 
conatin "destructive" code, which cannot use for any locales, exclude 
ru_RU. Subpages links generation goes in 
turba/templates/list/alphaPager.inc and checking on "current" page 
goes in turba/lib/ListView.php. Patches with current "destructive" 
code attached, may be will usable :-)



To make it universal, I think, we need to know locale and where in 
current locale located letter, which will first subpage link? Locale 
we can take from login screen. So, this is only problem to know which 
in current locale is "start" letter, and which is their code

Mm. I have some users with more than 1000 contacts, and about 50 users 
with more than 500 contacts. If they were to see all their contacts on 
one page, wouldn't that take quite a while to load?





--Janne

Before start this issue,perhaps we can consider a simple  solution   
ref. ticket 6790

I buy this being an enhancement, but we do need to do it somehow.

That would defeat the paging on the server side, i.e. on the SQL or 
LDAP server.

Could you use the collation information of the locale to determine the 
set of initial characters that should be shown? (I'm not completely 
familiar with how locales work in this respect.) A Finn would expect 
to see in the end of the initial letter list the local letters "Å Ä Ö" 
when using his/her own language, and so would a Swede... a Russian 
would like to see the list of cyrillic characters (maybe in addition 
to the latin letters, for Western contacts). I don't know what a 
Japanese or a Chinese would like to see...



A completely different way to attack the problem would be to determine 
the actual initial characters from the actual contacts of the user, 
sort them according to the selected language's (locale's) collation 
rules and only show those initial characters in the list. I think that 
Cyrillic locales, for example, also contain collation rules for latin 
characters.

Well, and how would you want to fix that? It might be easy for Ä, 
though it's already harder than it looks like, to map it to A. But how 
about characters not from latin1 charsets, like cyrillic, chinese, 
japanese, etc.?

(First, sorry if this went into a wrong queue, but I couldn't see a 
queue for Turba...)



If a user has so many contacts that Turba separates them into 
different pages according to the first letter of a name, there is 
trouble with international characters. If I have sorted my contacts 
according to the surname and have a contact with the surname of, say, 
"Äärelä", there are still only sub pages for contacts that begin with 
[A-Z]; there appears no page for contacts that begin with "Ä" (that 
is, A with two dots). I can only find contacts with non-low-ascii 
first letter on the page that contains "All" my contacts.