我们所做的项目由三层组成:表示层、业务逻辑层和数据层，我在这里将它们称为前、中、后。
前端是用PHP编写的，它通过Web服务(XML-RPC、SOAP等)与中间通信。用户还可以编写自己的客户端来与mid交谈。 nid是用Java开发的，它执行业务逻辑并向前端提供数据，也可能向前端抛出异常。
我现在的问题是，如果我以后想要多语言支持，我该在哪里开发i18n？由于包含所有文本，位于前面是有意义的，那么来自中间的异常和其他消息又如何呢？
如果用户开发自己的客户端并且中间设备具有多语言支持，则来自它的消息(如上面所述的异常(exception))因此可以采用他们选择的语言。这就是我看到的优势。我只是不喜欢使用两层 i18n 代码并且在处理异常时必须处理 i18n 的想法。
最佳答案
这在很大程度上取决于您的应用程序。
如果你认为 UI 本地化，那么演示肯定会受到影响。
我想说中间层不应该生成任何消息。 异常是为开发人员设计的，而不是为用户设计的。因此，在演示文稿中捕获异常，并以本地化方式将其呈现给用户，例如“发生 fatal error 12313，请将此报告发送至...” (也许更好，您根本不显示异常文本，提供一个“发送崩溃报告”按钮，并提供一个“显示报告”按钮，让用户看到您没有发送任何私有(private)数据)。
但是，如果您关心的是 UI 之外的内容，那么其他内容也可能会受到影响。 业务逻辑可能会受到影响(例如，税收系统的工作方式因国家/地区而异)。这与用户界面无关(加拿大或澳大利亚有与美国不同的税收制度，即使用户界面仍然是英语)。 因此，您可能希望将这一层设计得非常模块化。
数据库的内容也可能受到影响。想象一下，您的产品在某些国家/地区不可用(或被禁止)。因此，您可能需要额外的字段(或表)来携带该信息。
所以最后的答案是“你必须在每个层面上考虑 i18n!”并问自己“如果”
关于web-services - i18n/多语言应该在哪一层处理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1443524/