几年内国际化桌面应用程序......我们现在应该怎么做？

Question

因此，我们确信我们将在国际上采用我们的产品，并最终需要将其国际化。你推荐我们做多少国际化？

我想换句话说，现在是否有任何国际化变得容易，但如果我们让代码库成熟并且如果我们现在选择开始这样做会不会减慢我们的速度，可能会更糟糕？

使用的技术：C＃，WPF，WinForms

Answer 1

在编写代码库本身的所有字符串之前，立即做好准备。

此后的一切都为时已晚。它现在或永远不会！

现在做好准备是一件额外的努力，但不这样做会最终变得更加昂贵。

如果您不遵循以下链接中的所有指导原则，至少要注意摘要中的1,2和7点，这些点现在非常便宜，并且在我的经验中会造成最大的痛苦。

检查这些指南，亲自了解为什么现在开始做好准备并做好一切准备。

1. Developing world ready applications

2. Best practices for developing world ready applications

小提取物：

1. 将所有可本地化资源移动到单独的仅资源DLL。可本地化的资源包括用户界面元素，例如字符串，错误消息，对话框，菜单和嵌入的对象资源。 （之后将资源移动到DLL会很麻烦）
2. 不要硬编码字符串或用户界面资源。 （如果你没有准备，你知道你会硬编码字符串）
3. 不要将非本地化资源放入仅限资源的DLL中。这会给译员带来困惑。
4. 不要使用在连接短语中在运行时构建的复合字符串。复合字符串很难本地化，因为它们通常采用不适用于所有语言的英语语法顺序。 （在界面设计之后，更改短语会变得更难）
5. 避免使用诸如“空文件夹”之类的模糊结构，其中字符串可以根据字符串组件的语法角色进行不同的转换。例如，“空”可以是动词或形容词，这可以导致意大利语或法语等语言的不同翻译。 （同一问题）
6. 避免在应用程序中使用包含文本的图像和图标。本地化它们很昂贵。 （使用在图片上呈现的文字）
7. 在用户界面中为字符串的长度留出足够的空间。在某些语言中，短语可能需要50-75％的空间。 （同样的问题，如果你现在没有计划，重新设计会更贵）
8. 使用System.Resources.ResourceManager类根据文化检索资源。
9. 使用Microsoft Visual Studio .NET创建Windows窗体对话框，以便可以使用Windows窗体资源编辑器（Winres.exe）对其进行本地化。不要手动编写Windows窗体对话框。

Answer 2

恕我直言，声称某事将在几年内发生“字面意思是”我们希望有一天“真正意味着”永远“。虽然我仍然会浏览各种教程，以确保你不会犯任何可怕的错误。现在做正确的国际化支持意味着将来工作量减少，一旦你习惯了它，它就不会对今天的生产力产生任何实际影响。但如果你能用多年来衡量目标，那么现在可能不值得做。

我参与了两个实现国际化的项目：一个C＃ASP.NET（在我加入项目之前就存在）应用程序和一个PHP应用程序（使用免费的国际化控制和我自己的管理应用程序自制我自己的方法）。

您应该将所有文本（标签，按钮文本等）作为数据存储在数据库中。用键引用这些（我更喜欢使用前4个单词，大写，空格转换为下划线和非alpha数字被剥离），当你有副本时，在末尾添加一个数字。这个关键方法的好处是程序员只需通过查看密钥就可以非常了解文本内容。

编写实用程序以提取数据并构建您添加到项目中以进行编译的.NET资源文件。为每种语言创建单独的资源文件。在您的代码中，使用键指向正确的条目。

我会浏览有关该主题的MS文件： http://www.microsoft.com/globaldev/getwr/dotneti18n.mspx

要避免的一些基本事项：

• 永远不会使用翻译软件，聘请专业人士或实习生在当地大学学习该语言
• 永远不会尝试通过附加两个现有条目来创建文本，因为语法在每种语言中都有很大差异，这将永远不会起作用。因此，如果您有一个字符串显示“Click”并想要一个显示“Click Now”的字符串，请不要尝试创建合并两个条目的设置，或者在翻译期间，复制单词以进行单击并立即翻译该单词。将每个字符串视为从头开始的全新翻译

Answer 3

我将添加存储和操作字符串数据为Unicode（MS SQL中的NVARCHAR）。

Answer 4

认为关于......

的一些问题

您是否可以将您的应用程序的英文版本的发货延迟，以节省一些国际化费用？

如果您没有快速收到英文版的现金流，您还会进行交易吗？

如果您没有从某些客户那里快速获得有关它的

，那么您将如何获得正确的用户界面？

在必须将UI国际化之前，您多久会重写一次UI？

英语客户是否希望能够在UI中自定义字符串，例如不是每个人都称之为“发货单”的想法。

国际化的痛苦很大一部分是确保你不打破英文版，对UI的自动系统测试是否有更好的投资？

我认为我将永远做的唯一事情是：“不要使用从连接短语构建的复合字符串”，如果你这样做，不要传播代码通过许多方法构建单个字符串。

让您的UI自动调整大小（和布局）以应对标签的长度等，如果您能够以低廉的价格购买，这将为您节省大量时间。有许多用于Windows窗体的第三方控件集，可以让您标记文本框等，而无需将标签作为单独的控件放置。

我刚刚开始国际化WinForms应用程序，我们希望大多能够使用每个控件的“名称”作为查找键，而不必将批次移动到资源文件等。它并不总是像你一样难首先想想......

Answer 5

您可以使用NGettext.Wpf（可以从NuGet进行安装，是的，我是作者，但出于其他答案中列出的无奈之意，我做到了。）

它是托管在github repository上的，这里是撰写本文时的入门部分：

NGettext.Wpf旨在与依赖项注入一起使用。您需要在应用程序的入口处调用以下命令：

NGettext.Wpf.CompositionRoot.Compose("ExampleDomainName");

"ExampleDomainName"字符串是域名。这意味着当当前区域性设置为"da-DK"时，将相对于WPF应用程序的运行位置从"Locale\da-DK\LC_MESSAGES\ExampleDomainName.mo"加载翻译（您必须在应用程序中包含.mo文件，并确保将其复制到输出目录）。

现在您可以在XAML中执行以下操作：

<Button CommandParameter="en-US" 
        Command="{StaticResource ChangeCultureCommand}" 
        Content="{wpf:Gettext English}" />

哪个演示了此库的两个功能。最重要的是Gettext标记扩展，它将确保将Content设置为相对于当前区域性的“英语”翻译，并在更改当前区域性时对其进行更新。它演示的另一个功能是ChangeCultureCommand，它将当前区域性更改为给定区域性，在这种情况下为"en-US"。

我也强烈建议您从gettext实用程序手册中阅读Preparing Strings。

Answer 6

如果您使用测试数据，请使用非英语（例如：俄语，波兰语，挪威语等）字符串。 编码偷看它在每个角落都有点难看。如果不在你自己的库中，那么在外部库中。

我个人偏爱俄语，因为虽然我不会说俄语（尽管我的名字来源），但它里面有外国字符，它占用的空间比英语还要多，因此测试你的间距。
不知道这是否是语言特定的，或者仅仅因为我们的俄语翻译喜欢冗长的字符串。

Answer 7

国际化将让您的产品在其他国家/地区使用，这很容易并且应该从一开始就完成（这样一来，全世界的英语人都可以使用您的软件），这3条规则将帮助您完成大部分工作：

1. 支持国际字符 - 在文件和数据库中仅使用Unicode数据类型。
2. 支持国际日期，时间和数字格式 - 在将数据存储到文件或计算机可读存储时使用CultureInfo.InvariantCulture，在显示数据或解析用户输入时使用CultureInfo.CurrentCulture，从不进行自己的解析，从不使用任何其他文化对象
3. 用户输入的文本数据应被视为黑盒子，不要试图将其分解为单词或字母，尤其是在向用户显示时 - 不同的语言有衍生规则，操作系统知道如何显示左从右到右的文字，你没有。

本地化正在将软件翻译成不同的语言，这是困难且昂贵的，一个良好的开端是永远不要硬编码字符串，也不要用较小的字符串构建句子。