filter field labels are statically coded/untranslatable

Manual test in FOLIO Snapshot.

I'll close the ticket with the comments above from .

The ISBN and ISSN have been left as they in English for now. I will ask to translate them to ردمد and ردمك
The filters values, like (Local and Knowledge Base) for the Source filter, are hard-coded I believe. This is an area that is encountered in several FOLIO apps. I will prepare PRs for each app where work is needed.

Thanks,
Massoud.

Manual test in FOLIO Snapshot, using Chrome.

Several Codex Search search delimiters have been translated to Arabic, since this bug-report was filed; but not ISBN and ISSN, and not the filters - display of reference data from (https://folio-snapshot.aws.indexdata.com/settings/inventory/resourcetypes)

I'll put this story back in progress.

CC:

Thanks for your input ! I am copying as well, as he's tech lead for Core: Platform and a key decision-maker on these topics

Thank you ALL.
While Rethinking the vision of the CodexSearch app, I just hope that the idea of integrating a flll text engine, like Apache Solr or ElasticSearch, will be highly considered instead of relying solely on the Post-grey search capabilities, which maybe good enough for searching/retrieving English words/ phrases, but it is for sure way short of indexing/ retrieving Arabic/ Hebrew/ Urdu/ Farsi content in the fashion we are enjoying today with most of the global ILS staff clients, OPAC and/or Discovery Portals.

I have wrote an article on Feb 1st/19 in FOLIO Discussion about this issue before. I will share the article here since I noticed that most of the Advanced Search issues raised on using a fulltext engine to enhance the searching/ retrieval capabilities in FOLIO are now closed!

Here is the article:

This is a very critical topic for the Arabic searching and retrieval capabilities in FOLIO. Arabic searching requires stripping off prefixes and suffixes letters from Arabic words before they get indexed, because those letters are connected to the word! For example, in English you write "The Book" where "The" and "Book" are two separate words, and when indexed only the "Book" is inserted in the index table and "The" is likely to be kept out since it is a stop word. In Arabic, "The Book" is written like this "Alkitab الكتاب" which is compromised of two words: Al and Kitab, representing The and Book English. This means that there should be some mechanism to separate the "Kitab" word from its prefixing and/or suffixing letters first, so that only the core word gets indexed. There are more than ten prefixes like "Al" that can prefix an Arabic word, and sometimes they can go as many many as three prefixes proceeding a word. The same thing can be said about suffixes trailing Arabic words, which means they must be stripped off the Arabic word before they are indexed, so that when an Arabic word(s) is searched for, it will appear in the search results in all of its forms, proceeded and/or trailed by all prefixes or suffixes letters applicable to that word.

Based on our 20 years of experience with ILSs, such as Unicorn/Symphony and Koha, searching for Arabic words and phrases require a full text and retrieval engine (FTR) for these Arabic words to be handled properly. FTRs such as BRS (Unicorn/Symphony) or Solr (Sierra and VuFind) or Zebra (Koha) and now ElasticSearch (Koha), are popular in the library ILS business for long times. In fact, the only new addition in Sierra to differentiate it from Millennium is the addition Apache's Solr via Encore. Therefore, all new versions of the global ILSs are building their search and retrieval capabilities on FTR engines.

FTRs provide very easy way to define prefixes and suffixes letters, and infixes letters if needed, for a language using the Schema approach. We have been doing this with Solr and Elastic FTR for many years now, supporting DSpace IR, VuFind Federated Search and Discovery, and Koha ILS. To my knowledge, EBSCO EDS unique support of Arabic searching and retrieval is also due to the use of Apache's Solr. We look forward to see Solr and/or ElasticSearch readily integratable with FOLIO core indexing as an optional feature for libraries to use.

All the best,
Massoud AlShareef
KnowledgeWare Technologies Est.