Идеальной стратегией было бы иметь дополнительное языковое поле и другие существующие поля, которые могут занимать контент на многих языках. Значение языкового поля динамически выбирает различные языковые анализаторы для многоязычных полей. Но по сути, одно поле будет иметь содержимое на многих языках, что влияет на термин статистика.
Поскольку термин в Lucene является полем: термин, для языков, имеющих общие слова, термин статистики будет представлять собой проблему, особенно если на одном языке термин является часто используемым словом, а в другом - необычным словом. Худший случай - слово остановки на одном языке и важный термин на другом языке. Если это так, это не стратегия. Тем не менее, для вашего языка, возможно, что нет никакого влияния на термин статистика, а словари на разных языках являются взаимоисключающими. В этом случае вы можете ожидать, что TFIDFS будет работать. Если вы используете другие классы сходства, они должны в основном работать хорошо, если TFIDF работает.
Для других стратегий:
Это, безусловно, зависит от а) Нет языков для поддержки (говорят м) б) Нет полей, которые должны быть многоязычным (скажем, п)
В случае. как т и п меньше, то вы можете пойти на multifields подход:
(en -english, jp - Japanese, fr - French)
field1_en, field1_jp , field1_fr,
field2_en, field2_jp , field2_fr.
Если вы не попали т * п больше чем 1000+ полей, это безопасная стратегия. Эффект Лученей снижается, когда ни один из полей не огромен.
В случае, если языков не очень мало, может работать другая папка индекса (другая схема), но обратите внимание, что если вам нужно возвращать результаты с разных языков, это вызывает беспокойство во многих поисковых системах. Однако Elastic Search делает все возможное.
В моем единственном документе имеется около 50 полей, и я планирую поддерживать 7-8 языков, что будет лучшей стратегией для индексирования и поиска для поддержания производительности. –