CiviCRM Community Forums (archive)

Hello, everyone.

Please pardon a question from someone who is not yet a CiviCRM user, but I am curious about how well CiviCRM handles Chinese, Japanese, and Korean, particularly with respect to searches conducted by site users in those languages. I am asking in part because I am now seeking developers to provide professional services for a Tokyo-based NPO (please see the RFP post at the URL below if interested), and the project requires flawless CJK support.

http://forum.civicrm.org/index.php/topic,12153.0.html

I would imagine that these languages should be no problem, but am I correct in that assumption? Please let me know.

Thank you,

Patrick Eaton
http://jat.org

I’m not very good at the technicalities behind how CJK characters are represented in UTF-8, but assuming the representation is consistent, then I don’t see any show-stoppers – CiviCRM is in UTF-8 from grounds up.

The only problem I can think of if the same characters are represented in various ways (e.g., a single character can be represented either as X or as Y plus a combining character Z), but I hope it’s not a common problem in CJK (it’s quite rare in Central- and Easter-European characters).

Hi all,

We don't have full testing on CiviCRM 3.x about l10n in Chinese. Some basic search does work for me, but sometimes we need care about specific situation, such as full name sorting in Chinese is different than in English. Fo example, if we search lastname+firstname without comma, we cant find anything. (But in fact, "ChuangCharles" is the format we use, not "Chuang, Charles" or "Charles Chuang")

Any suggestion?

Where should I go to change the rules for {contact.display_name}?

Thanks!

at some point, we might want to make both the display_name and sort_name hookable so modules can change the behavior if needed

…or make them virtual columns (view columns) built on-the-fly by MySQL. Perhaps harder to make hookable then, though (at the benefit of not having to handle regeneration on the PHP side).