混合语言的陷阱

如果你只需要处理一种语言，那么你很幸运。找到一个正确的策略用于处理多语言文档是一项巨大的挑战。

在索引的时候

多语言文档主要有以下三个类型：

  • 一种是每份 document （文档）有自己的主语言，并包含一些其他语言的片段（参考 one-lang-docs。）
  • 一种是每个 field （域）有自己的主语言, 并包含一些其他语言的片段（参考 one-lang-fields。）
  • 一种是每个 field （域）都是混合语言（参考 mixed-lang-fields。）

（分词）目标不总是可以实现，我们应当保持将不同语言分隔开。在同一份倒排索引内混合多种语言可能造成一些问题。

不合理的词干提取

德语的词干提取规则跟英语，法语，瑞典语等是不一样的。 为不同的语言提供同样的词干提规则将会导致有的词的词根找的正确，有的词的词根找的不正确，有的词根本找不到词根。 甚至是将不同语言的不同含义的词切为同一个词根，合并这些词根的搜索结果会给用户带来困恼。

提供多种的词干提取器轮流切分同一份文档的结果很有可能得到一堆垃圾，因为下一个词干提取器会尝试切分一个已经被缩减为词干的单词，这加剧了上面提到的问题。

每种书写方式一种词干提取器

只有一种情况, only-one-stemmer （唯一词干提取器）会发生，就是每种语言都有自己的书写方式。例如，在以色列就有很大的可能一个文档包含希伯来语，阿拉伯语，俄语（古代斯拉夫语），和英语。

  1.     אזהרה - Предупреждение - تحذير - Warning

每种语言使用不同的书写方式，所以一种语言的词干提取器就不会干扰其他语言的，允许为同一份文本提供多种词干提取器。

不正确的倒排文档频率

在 relevance-intro（相关性教程）中，一个 term （词）在一份文档中出现的频率越高，该term（词）的权重就越低。为了精确的计算相关性，你需要精确的统计 term-frequency （词频）。

一段德文出现在英语为主的文本中会给与德语单词更高的权重，给那么高权重是因为德语单词相对来说更稀有。 但是如果这份文档跟以德语为主的文档混合在一起，那么这段德文就会有很低的权重。

在搜索的时候

然而仅仅考虑你的文档是不够的 。你也需要考虑你的用户会怎么搜索这些文档。通常你能从用户选择的语言界面来确定用户的主语言，（例如， mysite.de 和 mysite.fr ） 或者从用户的浏览器的HTTP header（HTTP头文件）accept-language 确定。

用户的搜索也注意有三个方面:

  • 用户使用他的主语言搜索。
  • 用户使用其他的语言搜索，但希望获取主语言的搜索结果。
  • 用户使用其他语言搜索，并希望获取该语言的搜索结果。（例如，精通双语的人，或者网络咖啡馆的外国访问者）。

根据你搜索数据的类型，或许会返回单语言的合适结果（例如，一个用户在西班牙网站搜索商品），也可能是用户主语言的搜索结果和其他语言的搜索结果混合。

通常来说，给与用户语言偏好的搜索很有意义。一个使用英语的用户搜索时更希望看到英语 Wikipedia 页面而不是法语 Wikipedia 页面。

语言识别

你很可能已经知道你的文档所选用的语言，或者你的文档只是在你自己的组织内编写并被翻译成确定的一系列语言。人类的预识别可能是最可靠的将语言正确归类的方法。

然而，或许你的文档来自第三方资源且没经过语言归类，或者是不正确的归类。这种情况下，你需要一个学习算法来归类你文档的主语言。幸运的是，一些语言有现成的工具包可以帮你解决这个问题。

详细内容是来自 Mike McCandless 的 chromium-compact-language-detector工具包，使用的是google开发的基于 (Apache License 2.0)的开源工具包 Compact Language Detector (CLD) 。它小巧，快速，且精确，并能根据短短的两句话就可以检测 160+ 的语言。它甚至能对单块文本检测多种语言。支持多种开发语言包括 Python，Perl，JavaScript，PHP，C#/.NET，和 R 。

确定用户搜索请求的语言并不是那么简单。 CLD 是为了至少 200 字符长的文本设计的。字符短的文本，例如搜索关键字，会产生不精确的结果。这种情况下，或许采取一些简单的启发式算法会更好些，例如该国家的官方语言，用户选择的语言，和 HTTP accept-language headers （HTTP头文件）。