我应该将本地化内容存储在应用程序状态中吗
我正在开发我的第一个多语言 C# 网站，除了一个关键方面外，一切都很顺利。我不能 100% 确定存储字符串（通常是单个单词）的最佳选择是什么，这些字符串将由我的代码隐藏页面中的代码进行翻译。
在网站的前端，我将使用 asp.net 资源文件作为页面上的措辞。这部分很好。然而，该站点将进行 XML 调用，并且 XML 响应仅采用英语。我收到了一张 Excel 工作表，其中包含将由 XML 返回的所有单词分解为不同的语言，但我不确定如何最好地存储/访问此信息。大约有 80 个单词 x 7 种语言。
我正在考虑为应用程序运行时由我的 global.asax 文件创建的每种语言创建一个字典对象，并将其存储在内存中。这样做的好处是，字典对象只需创建一次（直到 IIS 重新启动），并且任何用户都可以访问而无需重建，但缺点是我有 7 个字典对象不断存储在内存中。服务器是 Win 2008 64 位，具有 4GB RAM，所以我是否应该担心使用此方法占用的内存？
你们认为存储/检索所有用户都会使用的不同语言单词的最佳方式是什么？
感谢您的意见。
富有的
I am developing my first multilingual C# site and everything is going ok except for one crucial aspect. I'm not 100% sure what the best option is for storing strings (typically single words) that will be translated by code from my code behind pages.
On the front end of the site I am going to use asp.net resource files for the wording on the pages. This part is fine. However, this site will make XML calls and the XML responses are only ever in english. I have been given an excel sheet with all the words that will be returned by the XML broken into the different languages but I'm not sure how best to store/access this information. There are roughly 80 words x 7 languages.
I am thinking about creating a dictionary object for each language that is created by my global.asax file at application run time and just keeping it stored in memory. The plus side for doing this is that the dictionary object will only have to be created once (until IIS restarts) and can be accessed by any user without needing to be rebuilt but the downside is that I have 7 dictionary objects constantly stored in memory. The server is a Win 2008 64bit with 4GB of RAM so should I even be concerned with memory taken up by using this method?
What do you guys think would be the best way to store/retrieve different language words that would be used by all users?
Thanks for your input.
Rich
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据您的说法，您正在查看 560 个单词，这些单词需要根据区域设置而有所不同。这是沧海一粟。您考虑的资源文件方法适合目的，我建议使用它们。它们与控件集成，因此您将充分利用它们。
如果它确实困扰您，您可以将它们放在滑动缓存上，即例如 20 分钟的滑动缓存，但我认为您在此解决方案中的选择没有任何问题。
OMO
干杯，
安德鲁
P.s.阅读本文，了解如何在不同资源文件中查找值并将其绑定到控件和文字，并以编程方式使用。
http://msdn.microsoft.com/en-us/magazine/cc163566。 ASPX
From what you say, you are looking at 560 words which need to differ based on locale. This is a drop in the ocean. The resource file method which you have contemplated is fit for purpose and I would recommend using them. They integrate with controls so you will be making the most from them.
If it did trouble you, you could have them on a sliding cache, i.e. sliding cache of 20mins for example, But I do not see anything wrong with your choice in this solution.
OMO
Cheers,
Andrew
P.s. have a read through this, to see how you can find and bind values in different resource files to controls and literals and use programatically.
http://msdn.microsoft.com/en-us/magazine/cc163566.aspx
只要您意识到这样做的影响，那么可以将这些数据存储在内存中（只要您有足够的内存）。一旦您知道什么适合当前用户，那么将其放入内存中就可以了。您可能会考虑使用 MemCached Win32 或 Velocity 之类的工具来将存储卸载到另一个应用程序服务器。即使暂时在您的本地应用程序上使用它，当需要将其推送到另一台服务器或扩展您的应用程序时，您在缓存层定义了明确的关注点分离。请记住，您支持的语言越多，您在内存中存储的内容就越多。请密切关注单个应用程序服务器内存中存储的数据量，因为随着时间的推移，这可能会变得不堪重负。另外，请确保您使用的键特定于该语言。否则，您可能会发现您正在为英语用户存储德语菜单。
As long as you are aware of the impact of doing so then yes, storing this data in memory would be fine (as long as you have enough to do so). Once you know what is appropriate for the current user then tossing it into memory would be fine. You might look at something like MemCached Win32 or Velocity though to offload the storage to another app server. Use this even on your local application for the time being that way when it is time to push this to another server or grow your app you have a clear separation of concerns defined at your caching layer. And keep in mind that the more languages you support the more stuff you are storing in memory. Keep an eye on the amount of data being stored in memory on your lone app server as this could become overwhelming in time. Also, make sure that the keys you are using are specific to the language. Otherwise you might find that you are storing a menu in german for an english user.