在哪一层应该处理i18n /多语言？

Question

我们所处理的项目包括3层：表示层，业务逻辑层和数据层，我将在前面，中间和后面称呼它们。

前面是用PHP编写的，它通过Web服务（XML-RPC，SOAP等）与mid进行通信。用户还可以编写自己的客户端与中间人交谈。 nid是用Java开发的，它执行业务逻辑并向前端提供数据，它也可能会抛出异常。

我遇到的问题是，如果我希望将来能够提供多语言支持，我应该在哪里开发i18n？因为它有所有的文本，所以在前面是有道理的，那么来自中间的异常和其他消息呢？

如果用户开发自己的客户端并且mid有多语言支持，那么来自它的消息（如上所述的异常）可以使用他们选择的语言。这是我所看到的优势。我只是不喜欢有i18n代码的两层并且在处理异常时必须处理i18n的想法。

Answer 1

我会问你一个问题：i18n数据将在后面层（数据层）处理？ 如果你说是，那么你得到它，但如果你说不，那么我会把它放在中间层（忙碌层），因为中等和更大的项目用来与I18N互动（例外，货币，消息格式，时区，字符集等...）

我会将它放在较小项目的前层（表示层）中。

问候。

Answer 2

这很大程度上取决于你的申请。

如果您认为UI本地化，那么演示文稿肯定会受到影响。

我想说中间层不应该生成任何消息。 例外情况适用于开发人员，而不适用于用户。因此，在演示文稿中捕获异常，并以局部方式将其呈现给用户，如“发生致命错误12313，请将此报告发送给......” （可能更好，你根本不显示异常文本，提供“发送崩溃报告”按钮，带有“显示报告”按钮，供用户查看您没有发送任何私人数据）。

但是，如果你关于UI以外的东西，那么其他人也可能会受到影响。 业务逻辑可能会受到影响（例如税务系统的工作方式因国家/地区而异）。这与UI无关（加拿大或澳大利亚有另一个税收制度，而不是美国，即使用户界面仍然是英语）。 因此，您可能希望将此图层设计为非常模块化。

数据库的内容也可能受到影响。想象一下，某些国家/地区的产品不可用（或被禁止）。因此，您可能需要额外的字段（或表格）来传递该信息。

所以最后答案是“你必须在各个层面考虑i18n！”并问自己“如果”

Answer 3

如果您希望完全国际化，来自中间层的异常和其他消息不应包含文本。您应该指定客户端必须在表中查找的代码才能理解。