Na documentação que você fornece, afirma:
Isso sugere que o grego não é suportado, pois não se enquadra em nenhum desses conjuntos de caracteres (acredito que o grego é o latim-7). Dito isso, você pode tentar definir um sinalizador de idioma em um nível de registro (já que você indica que seus dados incluem inglês e grego), supondo que cada idioma tenha seu próprio registro ou tente implementar um idioma global usando o
dgidx e dgraph parâmetros, mas isso afetará coisas como derivação de registros ou propriedades que não estão na linguagem global.
dgidx --lang el
dgraph --lang el
Embora eu não tenha certeza de que funcionará com base na declaração original.
Alternativamente, você pode implementar um processo de remoção diacrítica usando um Accessor personalizado , que estende o atg.repository.search.indexing.PropertyAccessorImpl class (uma opção já que você se refere a Nucleus , então presumo que você esteja usando o ATG/Oracle Commerce). Usando isso, você especifica um campo pesquisável normalizado em seu índice que duplica os campos pesquisáveis em seu índice atual, mas agora com todos os sinais diacríticos removidos. A mesma lógica que você aplica no Accessor então precisa ser aplicado como um pré-processador em seus termos de pesquisa para que você normalize a entrada para corresponder aos valores indexados. Por último, torne seus campos originais no índice (com os caracteres acentuados) somente para exibição e os campos normalizados pesquisáveis (mas não os exiba).
O resultado corresponderá ao seu texto normalizado, mas a desvantagem é que você tem dados duplicados para que seu índice seja maior. Não é um grande problema com pequenos conjuntos de dados. Também pode haver um impacto em como a funcionalidade OOTB, como lematização, se comporta com o conjunto de dados normalizado. Você terá que fazer alguns testes com vários cenários em grego e inglês para ver se a precisão e o recall são afetados negativamente.
