Nella documentazione che fornisci afferma:
Ciò suggerisce che il greco non è supportato poiché non rientra in nessuno di questi set di caratteri (credo che il greco sia Latin-7). Detto questo, potresti provare a impostare un flag di lingua a livello di record (poiché indichi che i tuoi dati includono sia l'inglese che il greco) supponendo che ogni lingua abbia il proprio record o provare a implementare una lingua globale usando il dgidx e dgraph parametri, ma ciò influirà su cose come lo stemming per i record o le proprietà non nella lingua globale.
dgidx --lang el
dgraph --lang el
Anche se non sono sicuro che funzionerà in base alla dichiarazione originale.
In alternativa, puoi implementare un processo di rimozione dei segni diacritici utilizzando un Accessor personalizzato , che estende atg.repository.search.indexing.PropertyAccessorImpl classe (un'opzione poiché fai riferimento a Nucleus , quindi suppongo che tu stia utilizzando ATG/Oracle Commerce). Usando questo si specifica un campo ricercabile normalizzato nell'indice che duplica i campi ricercabili nell'indice corrente ma ora con tutti i segni diacritici rimossi. La stessa logica che applichi nell'Accessor quindi deve essere applicato come preprocessore sui termini di ricerca in modo da normalizzare l'input in modo che corrisponda ai valori indicizzati. Infine, rendi i tuoi campi originali nell'indice (con i caratteri accentuati) di sola visualizzazione e i campi normalizzati ricercabili (ma non visualizzarli).
Il risultato corrisponderà al tuo testo normalizzato, ma lo svantaggio è che hai dati duplicati, quindi il tuo indice sarà più grande. Non è un grosso problema con piccoli set di dati. Potrebbe anche esserci un impatto sul modo in cui la funzionalità OOTB, come lo stemming, si comporta con il set di dati normalizzato. Dovrai eseguire alcuni test con vari scenari in greco e inglese per vedere se la precisione e il ricordo sono influenzati negativamente.
