分发本地化 winforms 应用程序

发布于 2024-07-26 00:43:20 字数 360 浏览 2 评论 0原文

这与我今天早期的帖子相关:链接文本

所以现在我有演示 winforms 应用程序,具有两种不同的本地化版本,一种是英语,一种是西班牙语。 现在假设我有一个大应用程序,假设它支持 15 种不同语言的本地化。 在上一篇文章中,建议我在初始化表单时添加几行来设置本地化。 目前我正在使用单击一次来部署我的应用程序。 我正在尝试找到一种无需 15 种不同风格的应用程序即可进行部署的方法。 有没有办法查看当前用户的本地化,以及它是否与我编写屏幕时使用的语言之一匹配,否则使用默认值?

This is related to my early post today: link text

So now I have demo winforms app with two different localizations, one english, one spanish. Now let's say I have a big app, let's say it supports localizations in 15 different languages. In the previous post, it was suggested that I add a few lines when the form is initialized to set the localization. Currently I'm using click once to deploy my application. I'm trying to find a way to deploy without having 15 different flavors of the app. Is there a way to look at the current user's localization and if it matches one of the languages I've written my screens in to use that, otherwise use the default?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

执手闯天涯 2024-08-02 00:43:20

.NET 框架的内置本地化系统已经可以处理这种后备情况。 您只需安装本地化表单和控件的附属 DLL,然后,如果正确的 DLL 与用户的区域设置相匹配,.NET 将使用它,否则它将回退到下一个相关的父区域设置。 例如,如果您的应用程序的默认语言是 en-US,但您提供了 en-GB 翻译和 en 翻译,则后备方法为:

en-GB->en->en-US

即当 en-GB 不可用时,它会查找 en,如果不存在,则使用默认值 en-US。

因此,在分发时,您可以仅分发主要的 en-US 应用程序,然后为特定语言提供附加的附属 DLL,例如语言包。 有一个属性 SatelliteContractVersionAttribute< /a>,它允许您的主应用程序程序集指示所需的附属版本,这使您的本地化能够跨程序集版本工作(例如,如果您的程序集版本随着构建而增加 - 您可以有效地忽略构建号)。

MSDN 有大量关于全球化和本地化及其工作原理的信息,甚至在 ClickOnce 部署的上下文中也是如此。 请查看全球化 Windows 窗体部分

当然,如果您选择不依赖 .NET 系统来支持全球化产品,那么您将必须想出一些适合您选择的方向的东西。

The built-in localization system of the .NET framework already handles this fallback situation. You just install the satellite DLLs that localize your forms and controls and then, if the right one matches the user's locale, .NET will use it, otherwise it will fallback to the next related parent locale. For example, if your application's default language is en-US but you have provided an en-GB translation and an en translation, then the fallback is:

en-GB->en->en-US

i.e. when en-GB is not available, it looks for en, and if that isn't there it uses the default, en-US.

Therefore, when distributing, you can distribute just your main en-US application and then provide additional satellite DLLs for particular languages as, say, language packs. There is an attribute, SatelliteContractVersionAttribute, that allows your main application assemblies to indicate the satellite versions that it wants, which enables your localizations to work across assembly versions (such as if your assembly versions increment with the build - you can effectively ignore the build number).

MSDN has a lot of information on globalization and localization and how this works, even within the context of ClickOnce deployment. Check the Globalizing Windows Forms section.

Of course, if you have chosen not to rely on the .NET system for supporting globalized products, then you will have to come up with something that fits your chosen direction.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文