Bug 228409 - Feature request: Additional 'Reading of name' fields for Kontact address book (+ sorting function)
Summary: Feature request: Additional 'Reading of name' fields for Kontact address book...
Status: RESOLVED DUPLICATE of bug 203952
Alias: None
Product: kaddressbook
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-25 05:48 UTC by homoludens
Modified: 2010-02-25 13:37 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description homoludens 2010-02-25 05:48:47 UTC
Version:            (using KDE 4.4.0)
Installed from:    openSUSE RPMs

This is likely going to be a rather time-consuming task, but would increase the appeal of Kontact immensely for Japanese, Chinese as well as Korean users (possibly others as well?):

It would be very useful for Japanese, Chinese and Korean speakers, or users of
the respective languages, to have an additional "Reading of name" fields in
Kontact's address book.

While it is sufficient for most languages to have single fields for last name,
first name, company name, etc, Japanese, Chinese and Korean names distinguish
between the (a) characters the name is written with (usually Chinese logograms,
called Hanzi in Chinese, Kanji in Japanese, or Hanja in Korean), and (b) the
reading = pronunciation of the name (for which different scripts are used,
including latin characters, Japanese hiragana or katagana, and Korean hangul
characters).

Users of these languages would, therefore, benefit greatly if additional fields
for the 'reading of name' were created in Kontacts address book. Which fields
receive such a field should be in line with localized operating systems for
PDAs / mobile phones in those countries in order to facilitate synchronization.
The would probably include (based on Japanese Palm-OS):
     1. last name
     2. first name
     3. company name

It should be address that internally, the extra fields are usually stored as
part of the name fields, but separated with special characters.

If address book entries make use of such extra fields, sorting of names ought
to be based on the 'reading of name' fields, not on the name fields themselves.

Since such extra fields might distract users of other languages, a nice
solution could be to have a check box on the address book entry whose clicking
would open up / add the additional fields (while leaving it unchecked would
hide the fields).

(I'm refiling this feature request for KDE 4.4. Filed it previously for an earlier version as Bug 197800)
Comment 1 Tobias Koenig 2010-02-25 09:06:56 UTC
You don't have to file this report for every released version...
It will be implemented if somebody findes time to do it.

*** This bug has been marked as a duplicate of bug 203952 ***
Comment 2 Tobias Koenig 2010-02-25 09:08:21 UTC
You don't have to file this report for every released version...
It will be implemented if somebody findes time to do it.

*** This bug has been marked as a duplicate of bug 203952 ***
Comment 3 homoludens 2010-02-25 13:37:43 UTC
Tobias,

I was only following your comment at Bug 197800:
"  -------  Comment #1 From  Tobias Koenig   2009-08-05 16:43:42   (-) [reply] -------

The development of the old KAddressBook will be discontinued for KDE 4.4.
Since the new application has the same name, but a completly new code base we
close all bug reports against the old version and ask the submitters to resend
there reports against the new product.

"

If possible, I think we should use this thread for all exchanges related to this issue since it's filed for KDE 4.4 & the new code base you mentioned, and rather close the other two bugs Bug 197800 and Bug 203952 which related to the previous code base. (I'm not sure why there are two identical bug reports anyway; probably my mistake when trying to file it, sorry ... )