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

我们所从事的项目由3层组成：表示层、业务逻辑层和数据层，我在这里称它们为前端、中间和后端

前端是用PHP编写的，它通过web服务（XML-RPC、SOAP等）与mid通信。用户还可以编写自己的客户机与mid对话。nid是用Java开发的，它执行业务逻辑并向前端提供数据，还可能向前端抛出异常

我的问题是，如果我想在未来获得多语言支持，我应该在哪里开发i18n？站在最前面是有意义的，因为它有所有的文本，那么来自mid的异常和其他消息呢

---

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

我想问你一个问题：i18n数据将在后一层（数据层）处理？ 如果你说是，那么你就明白了，但是如果你说不是，那么我会把它放在中间层（业务层），因为中型和大型项目使用I18N（异常、货币、消息格式、时区、字符集等）进行交互

对于较小的项目，我会将其放在前端层（表示层）

---

注意。

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

这在很大程度上取决于您的应用程序

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

我认为中间层不应该生成任何消息。 例外情况是针对开发人员的，而不是针对用户的。因此，在演示文稿中捕获异常，并以本地化的方式将其呈现给用户，如“发生致命错误12313，请将此报告发送给…” （也许更好，你根本不显示异常文本，提供一个“发送崩溃报告”按钮，还有一个“显示报告”按钮，让用户看到你没有发送任何私人数据）

但是，如果你对UI之外的东西感兴趣，那么其他人也可能会受到影响。 业务逻辑可能会受到影响（例如，各国税收系统的工作方式不同）。这是独立于用户界面的（加拿大或澳大利亚有另一种税收制度，而不是我们，即使用户界面仍然是英语）。 所以你可能想把这层设计得非常模块化

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

因此，最终的答案是“你必须在各个层面上思考i18n！”并问自己“如果”