Skip to main content

I’m using search block to find a contact in a table and it works fine as long as the name is transcribed in English, but when I try to apply the search to another field (name in the original, address, comments etc), which is not in English, e.g. Cyrillic, search returns no result.



I see that there are language settings in the block and you can choose from English, French, Spanish, German and Japanese but I cannot understand how a database search can depend on the language if both search query and DB record are the same unicode strings.



Regular Airtable search works fine with any language. However search block is more convenient to use when searching through 6000+ records tables.



Am I missing something or are there really limitations for search block in particular in terms of using Cyrillic (and some other non-English/Japanese etc.) characters?





This [likely] suggests that the full-text indexing used in the block is stripping away the unicode characters.

I’ve built a few cross-base full-text search solutions for Airtable clients using the underpinnings of Lucene (ElasticSearch) and now I’m curious if my indices of Airtable content are character-agnostic. I’ll give it a test tomorrow and see what happens.



This [likely] suggests that the full-text indexing used in the block is stripping away the unicode characters.




I’ve just created a new table with some text in Japanese. Seems that the search block works with hiragana/katakana (Japanese alphabetical systems) but not kanji when its language setting is switched to “Japanese”. Does it mean they use different charset for every language available in the settings and ignore unicode? Looks strange to me, and if so, I guess there is no workaround for the search block.





It’ll be interesting, I’ll be waiting for updates.



I’ve just created a new table with some text in Japanese. Seems that the search block works with hiragana/katakana (Japanese alphabetical systems) but not kanji when its language setting is switched to “Japanese”. Does it mean they use different charset for every language available in the settings and ignore unicode? Looks strange to me, and if so, I guess there is no workaround for the search block.





It’ll be interesting, I’ll be waiting for updates.




Correct, this would be my assessment as well. Why they would intentionally ignore unicode is puzzling to say the least; perhaps @EvanHahn could weight in?



I have advocated (a few times) in the forum that Airtable Blocks be open and based on open web standards making it possible for skilled users to extend and improve these plugins. This is a perfect example of where an open architecture would allow us to (a) understand the current behavior for possible workarounds, and (b) allow the energy of the community to make it better.

Reply


Terms & Conditions