节点翻译与实体（字段）翻译

我想知道你们对多语言网站的建议。例如，考虑以下情况：页面及其内容应以3种语言（例如德语，英语和西班牙语）提供；该站点使用一种配置文件类型，几种内容类型和视图，分类法，分类法引用，节点引用，用户和字段引用，字段集合，菜单等。所有这些信息都应该是可翻译的。

据我所知，有两种方法可以做到这一点：使用实体转换和“基于节点”的方法，或者通常使用国际化模块和10n的方法。

我应该选择哪种方式？在这种情况下，为什么我应该考虑使用一种方法而不是另一种方法？

兰迪·费伊（Randy Fay）最近创建了一篇文章，讨论使用Entity Translations实现的可能性，Gabor Hojtsy在评论中考虑了一些要考虑的因素：

[老式]节点翻译提供的一些好处包括支持单独的节点注释（例如，您的德语和英语注释不会混合在一起）；支持每种语言的修订；发布工作流程（例如，德语节点可以处于发布前修订版本的工作流程中，而英语已经发布，当所有动作都到达工作流程中的某个步骤时，协调动作可以发布多种语言版本等）；由于Drupal过多的节点访问系统等，不同的权限处理（例如，某些人只能编辑德语翻译而不是英语原文）。考虑菜单。大多数站点都不打算为所有翻译版本提供1-1菜单结构。

我对内容/实体/字段级转换的主要警告现在归结为古老的Drupalism特殊情况：节点标题...它不是一个字段，因此如果没有其他模块就无法翻译，并且可能一些补丁工作。截至目前，我认为现场翻译仍是非常“实验”的领域，但对您推动新领域具有更大的推动力。

Suzanne Kennedy和Florian Loretan在DrupalCon丹佛的演讲中解决了这个问题。似乎实体翻译是未来的方式，并且至少部分计划集成到核心中。

他们的建议是使用实体翻译，除非需要修订支持。

我使用了Node翻译，但是现在尝试实体翻译后，它绝对是我最喜欢的一个！

我认为主要问题是实体翻译的导入功能，因为在Drupal社区中有很长的讨论。否则，我会读到一个新模块的信息，但是我还没有尝试过。但之后我会给您我的反馈！

如果将“实体翻译”与“ 标题”模块结合使用，则可以翻译所有内容。我也更喜欢“ 本地化更新 ” 模块。

因此，您必须安装并启用以下贡献的模块：

• 实体翻译。
• 标题。
• 本地化更新。

并且您必须启用以下核心模块：

• 语言环境。
• 内容翻译。

祝好运！

我知道我在这里抚养死者，但：

据我所知，六样式节点翻译方法（每个翻译都是一个新节点）仍然是翻译内容的唯一有用方法，它具有成为每个人都习惯并功能完善的优点。（节点标题不是7中的字段，因此除了其他愚蠢的缺点外，无法进行字段翻译。）

您将始终使用i18n / locale，唯一的选择（并不是真正的选择）是节点级别或字段级别的转换，其中只有节点转换才可能有用。

编辑：自从编写以来，实体翻译+标题模块使字段级翻译非常有效。如果可以使用它们，则应该使用。

在大多数情况下，实体翻译比节点翻译更有意义。但是遗憾的是，对于D7而言，它并不是一个切实可行的选择，因为许多模块仍不支持它。进行演示并展示其卓越性的人们只是在做非常简单的工作。例如，ET仍不支持与字段集合一样常见/受欢迎的内容。

当我们启动一个新的多语言站点时，我们总是从ET开始，因为这是一个好主意。我们一直坚持下去，直到发现太多与问题不兼容的问题，然后最终我们切换回旧的D6方法。