About searchcode concept

In order to quickly search and select the CJK strings, In China, most softwares have the concept of search code. For example, if we want to search for “感冒”, CJK user can type: gm, ganmao, dgjh or other search codes to search, no need to active Input method to input “感冒”, these search codes are predefind or auto generated from CJK string.

My question is: how to define these concepts in gnuhealth and Tryton, which software level is more appropriate to implement this function?

searchcode is different ID, many CJK string will have same searchcode.

Does pyson support user defined function? for example:

(get_search_code(‘cjkstring’) “like” “gm”)

In those software how do they search for “gm” as in the word “pragmatic”?

I tried to find a way how to infer that “感” is (I presume but I may be wrong) “gm”. I guess it comes from the way it’s pronounced but it’s not in the unicode data of the glyph. It’s probably a database or something.

I would say that the client level have to somehow understand that you’re inputting searchcode and then turn them into their character using this database before sending the data to the server.

But then I wonder why would this way be easier than activating another input method? As I never needed to do that I don’t know how painful switching from one input method to another is in reality :slight_smile:.

The problem is that we have a mix of locale strings (which may be Chinese) and non-locale. So the client can not really know if it needs to make conversion or not.

So for me we have to look at the fulltext search features. There are maybe options to match using phonetic comparison.

I think this seem to be not a simple way, because “gm” maybe can link to 1000 possible Chinese Words

while a chinese word may be have only <10 search codes

maybe this is a good idea

There are PostgreSQL: Documentation: 14: F.15. fuzzystrmatch extension but unfortunately it does not combine with tsvector: sql - Could PostgreSQL perform phonetic search over tsvector? - Stack Overflow

A poor man’s approach maybe: adding a searchcodes field to models, this search_codes auto update and no view.

You could indeed use a function field with two underlying fields one with the data the other with the searchcodes of the data and searching on it would search on both.