Help:Extension:Translate/Translation memories/zh

翻译扩展的翻译记忆 支持ElasticSearch. 该页面旨在指导您安装ElasticSearch，并更详细地探索其规格.

与其他翻译辅助工具（例如外部机器翻译服务）不同，翻译记忆库会不断更新您的维基中的新翻译. 如果您选择使用ElasticSearch，也可以在Special:SearchTranslations中获得跨翻译的高级搜索.

比较
The database backend is used by default: it has no dependencies and doesn't need configuration. The database backend can't be shared among multiple wikis and it does not scale to large amounts of translated content. Hence we also support ElasticSearch as a backend. It is also possible to use another wiki's translation memory if their web API is open. Unlike ElasticSearch, remote backends are not updated with translations from the current wiki.

条件


ElasticSearch 后端
ElasticSearch is relatively easy to set up. If it is not available in your distribution packages, you can get it from their website. You will also need to get the extension. Finally, please see for specific configuration needed by Translate.

The bootstrap script will create necessary schemas. If you are using ElasticSearch backend with multiple wikis, they will share the translation memory by default, unless you set the index parameter in the configuration.

When upgrading to the next major version of ElasticSearch (e.g. upgrading from 2.x to 5.x), it is highly recommended to read the release notes and the documentation regarding the upgrade process.

安裝
在满足基本要求后，安装需要您调整配置，然后执行引导程序.

-{zh-hans:配置; zh-hant:組態;}-
包含翻译记忆的所有翻译辅助功能都通过设置變數来配置.

The primary translation memory backend must use the key. The primary backend receives translation updates and is used by Special:SearchTranslations.

TTMServers的配置示例：

可能的键值为：

目前只支持MySQL数据库後端.

Bootstrap
Once you have chosen ElasticSearch and set up the requirements and configuration, run  to bootstrap the translation memory. Bootstrapping is also required when changing translation memory backend. If you are using a shared translation memory backend for multiple wikis, you'll need to bootstrap each of them separately.

Sites with lots of translations should consider using multiple threads with the  parameter to speed up the process. The time depends heavily on how complete the message group completion stats are (incomplete ones will be calculated during the bootstrap). New translations are automatically added by a hook. New sources (message definitions) are added when the first translation is created.

Bootstrap does the following things, which don't happen otherwise:
 * adding and updating the translation memory schema;
 * populating the translation memory with existing translations;
 * cleaning up unused translation entries by emptying and re-populating the translation memory.

When the translation of a message is updated, the previous translation is removed from the translation memory. However, when translations are updated against a new definition, a new entry is added but the old definition and its old translations remain in the database until purged. When a message changes definition or is removed from all message groups, nothing happens immediately. Saving a translation as fuzzy does not add a new translation nor delete an old one in the translation memory.

TTMServer API
如果您想实现自己的 TTMServer 数据库，请看详细说明.

查询参数：

您的服务必须接受下列参数：

您的服务必须提供对象数组中含有键  的 JSON 对象. 这些对象必须包含下列数据：

例如：


 * 链接：http://translatewiki.net/w/api.php?action=ttmserver&sourcelanguage=en&targetlanguage=fi&text=january&format=jsonfm
 * 应答：



数据库后端
后端包含了三个表： 、 和. 分别对应于源、目标和完整的文本. 您可以在  中看到表格的定义. 源包含了所有信息组定义. 尽管通常它们总是使用相同的语言（例如英语），但在极少数情况下，文本的语言也会存储，这是不正确的.

每个条目都有唯一的 ID 和两个附加字段：长度和上下文. 查询时使用长度作为首个过滤器，这样就无需把要搜索的文本和数据库中每个条目进行比较. 上下文中保存了文本来源的页面标题，例如“MediaWiki:Jan/en”. 根据该信息，我们可以把建议链接到“MediaWiki:Jan/de”，这样有助于译者快速修复问题或确定使用哪个译文.

第二个过滤器来自全文索引. 它的定义与 ad hoc 算法混合. 首先通过 MediaWiki 的  把文本分割为片段（词）. 如果有足够的片段，我们主要去除所有非单词字母的那些内容来常态化. 接着获取开头的十个唯一单词，必须至少五个字节长（英文中的五个字母，对于多字节字符则更少字数）. 然后把这些词保存在全文索引中供将来过滤更长的字符串.

过滤出候选列表后，则从目标表中获取匹配的目标. 然后使用编辑距离算法进行最后的过滤和排序. 定义如下：


 * E : 编辑距离
 * S : 用于搜索建议的文本
 * Tc : 建议文本
 * To : 译文 Tc 的原始文本

通过 E/min(length(Tc),length(To)) 计算 Tc 建议的质量. 我们使用 PHP 内置的 levenshtein 函数，但当某个字符串长于 255 字节时，则使用 PHP 实现的 levenshtein 算法.  It has not been tested whether the native implementation of levenshtein handles multibyte characters correctly. This might be another weak point when source language is not English (the others being the fulltext search and segmentation).