C# 业务逻辑中的MVVM本地化

我正在将一个现有的WinForms应用程序重构为WPF和MVVM（除了MVVM中的理论知识外，几乎没有其他知识）。应用程序需要完全本地化。就UI而言，我对此没有意见（存储资源并基于枚举和其他结构绑定到它们）

应用程序必须向用户呈现动态生成的pdf。这些本地化信息应该放在哪里：

在后端使用pdf创建逻辑

赞成：更简单的逻辑流程

缺点：与MVVM理论相反，后端不应该知道它是如何显示的。也不易维护（2个地方有本地化数据）

将对象传递到要平移的视图。这意味着PDF生成代码需要进入视图

赞成：只有一个位置可以保持本地化

反对：也反对MVVM理论，因为视图不应该包含逻辑

---

这两种解决方案对我来说都不太理想。有什么想法吗

这些细节可能有助于全球化和本地化（）

---

还有一个关于codeplex的指南：WPF本地化指南（）

您的问题很难理解，但本地化的实际解决方案是：

1.使用.resx文件创建项目（项目名称可以是，例如本地化）

2.将名称空间添加到XAML文件中，例如

xmlns:localPresentation="clr-namespace:Localization.Presentation;assembly=Localization"

3.以这种方式本地化UI文本

Text="{x:Static localPresentation:PresentationResources.SomeResourceKey}"

---

这种本地化不是动态的。更改应用程序的语言时，必须重新启动它。动态本地化比较棘手，但一切都有可能。

我的问题不是UI的本地化。我的问题是关于本地化在后端生成的文件。如果我必须向用户提供一个已翻译的.pdf文件，我是否将对象传递到视图以进行翻译，然后返回到视图模型以生成pdf？或者我用pdf逻辑在后端存储翻译信息？我编辑了这个问题，希望能让你更容易理解我。你说得对。我没有正确理解这个问题。从我的观点来看，你必须在后台做。将数据传递到UI进行翻译不是一个好的解决方案，它没有意义。但也许我还是不明白你哪里有问题。如果您设置了Thread.CurrentThread.CurrentCulture和Thread.CurrentThread.CurrentUICulture，它应该可以工作。感谢您提供的链接，不幸的是，它们似乎都与我为用户翻译动态生成的数据文件的情况无关。