我构建了一个包含以下图层的应用：
也可以从第三方调用BLL以集成到其他客户的系统中。
假设在运行时甚至BLL中发生了验证错误。放置翻译的地方会更好：
在SOA体系结构中支持多种语言的最佳实践是什么？
编辑： 我应该使用术语层而不是层。
答案 0 :(得分：1)
我对您的问题的建议是一般性的，因为我不知道您正在使用的.NET平台的具体细节。
从你的问题，我看到两个不同的问题。
您的网络表示层将依赖于语言。它需要自定义CSS，字体，间距甚至自定义内容。不要欺骗自己不需要这样做。这是人们在国际化Web应用程序时最初犯的最大错误之一。您将需要另一种语言风格。因此，如果您使用的是模板方法，则可以将大部分语言内容放在依赖于语言的模板中。
从您的问题描述中，听起来您还需要处理本地化的错误消息。有两种方法：您可以使用语言文件在使用资源文件解决方案引发错误时进行本地化。另一种方法是让您的错误消息使用公共标识符和参数，并使另一个层捕获消息并对其进行本地化。我自己更喜欢以前的解决方案，因为它更简单。
另请记住，如果您将错误消息写入日志文件，则错误消息使用开发人员可以阅读的语言。同样，对于在GUI中向用户显示的错误，您将需要某种方式让用户向不会说用户语言的开发人员识别错误。这可以通过使用数字来完成 - 我更喜欢使用像DATABASE_ERROR_BAD_QUERY这样的短键。
答案 1 :(得分：1)
翻译应由表示层处理，因为它与视图相关。可以添加到消息中的上下文越多越好，业务逻辑可能也不会意识到上下文，也不应该这样。
我使用的方法如下：
业务逻辑抛出唯一的，定义的 错误代码，可用作键 到一个资源包来获得一个 已翻译的消息。
表示层维护文本 包含所有错误代码的包 翻译与...分开 一般表示层代码。
表示层取决于
业务逻辑和文本
封装
业务逻辑的第三方客户端，如Web服务， 可以选择包含文字 如果他们想要包装作为依赖 标准错误代码翻译。 否则他们可以处理错误 业务逻辑抛出的代码 他们自己的。
答案 2 :(得分：0)
我不太确定您对WEB UI的定义是什么。如果您使用MVC模式，Controller将负责在UI中显示正确的语言版本，而文本本身将在View层中。我不明白的是在您的架构中扮演控制器的角色。 BLL是否仅包含处理逻辑并且UI和服务之间没有通信？如果是这样，那么Web UI层可能包含本地化逻辑。
我还会说，这很大程度上取决于您在项目中使用的技术。例如，ASP.NET有一个可以使用的内置本地化模型。我不是说它应该作为一个例子，即使相反 - ASP.NET打破了关注点的分离。但我认为这是一个问题，在不同的自定义架构模型中会有非常不同的解决方案，就像你的情况一样。
答案 3 :(得分：0)
根据您的应用程序的结构，您可能需要在两个位置进行国际化：
1）软件本身。菜单，对话框，消息，标签，报告等
2）内容。使用多种语言运行时，您的应用可能需要使用多种语言处理内容。
我非常幸运地将管理工具和发布逻辑分开到不同的层（到目前为止）。
首先，考虑将语言翻译管理和生成逻辑（资源包等）放在业务逻辑中。因此，对于所有翻译，您需要一种快速同步所有数据条目的方法它们以主语言（英语）以所有语言添加到系统中，然后填充和管理它们。因此，如果您正在使用资源包，请从数据库生成所有语言的rb文件。
其次，在表示层发布语言翻译逻辑。它更多地与表示和格式化有关。您不可避免地会遇到日期，时间，货币等本地化问题，您可以在这里处理得非常好。您可能会也可能不会构建自己的库来发布这些内容，因为您可能会或可能不会允许或不允许编程语言的灵活性。
如果您能提供更多详细信息，我相信每个人都可以获得其他见解。
祝你好运！