W dostarczonej dokumentacji stwierdza się:
Sugeruje to, że język grecki nie jest obsługiwany, ponieważ nie należy do żadnego z tych zestawów znaków (uważam, że greka to łacina-7). To powiedziawszy, możesz spróbować ustawić flagę języka na poziomie rekordu (ponieważ wskazujesz, że twoje dane obejmują zarówno angielski, jak i grecki), zakładając, że każdy język ma swój własny rekord lub spróbować zaimplementować język globalny za pomocą dgidx i dgraph parametry, ale wpłynie to na takie rzeczy, jak pochodzenie rekordów lub właściwości nie w języku globalnym.
dgidx --lang el
dgraph --lang el
Chociaż nie jestem pewien, czy to zadziała w oparciu o oryginalne oświadczenie.
Alternatywnie możesz zaimplementować proces usuwania znaków diakrytycznych za pomocą niestandardowego Akcesora , który rozszerza atg.repository.search.indexing.PropertyAccessorImpl klasa (opcja, ponieważ odwołujesz się do Nucleus , więc zakładam, że używasz ATG/Oracle Commerce). Używając tego, określasz znormalizowane przeszukiwalne pole w twoim indeksie, które powiela przeszukiwalne pola w twoim bieżącym indeksie, ale teraz z usuniętymi wszystkimi znakami diakrytycznymi. Ta sama logika, którą stosujesz w Akcesorze następnie musi zostać zastosowany jako preprocesor w wyszukiwanych terminach, aby znormalizować dane wejściowe, aby pasowały do indeksowanych wartości. Na koniec ustaw oryginalne pola w indeksie (z zaakcentowanymi znakami) tylko do wyświetlania, a znormalizowane pola do przeszukiwania (ale ich nie wyświetlaj).
Wynik będzie pasował do Twojego znormalizowanego tekstu, ale wadą jest to, że masz zduplikowane dane, więc Twój indeks będzie większy. Nie jest to duży problem z małymi zestawami danych. Może również mieć wpływ na zachowanie funkcji OOTB, takiej jak stemming, ze znormalizowanym zestawem danych. Będziesz musiał przeprowadzić kilka testów z różnymi scenariuszami w języku greckim i angielskim, aby sprawdzić, czy nie ma to negatywnego wpływu na precyzję i zapamiętywanie.
