几年内将桌面应用程序国际化……我们现在应该做什么？答案

【问题标题】：Internationalizing Desktop App within a couple years... What should we do now?几年内将桌面应用程序国际化……我们现在应该做什么？
【发布时间】：2010-09-21 05:07:16
【问题描述】：

因此，我们确信我们将把我们的产品推向国际，并最终需要将其国际化。在我们进行的过程中，您建议我们进行多少国际化？

我想换句话说，是否有任何国际化现在很容易但如果我们让代码库成熟可能会更糟，如果我们选择现在开始这样做不会让我们非常慢？

使用的技术：C#、WPF、WinForms

【问题讨论】：

标签： wpf winforms internationalization

【解决方案1】：

现在就准备好，然后再将所有字符串写入代码库本身。

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

确实，现在做好准备确实需要付出一些额外的努力，但不这样做最终会变得更加昂贵。

如果您不遵循以下链接中的所有指南，请至少注意摘要中的第 1,2 和 7 点，这些点现在做起来非常便宜，但根据我的经验，这会导致最痛苦。

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

一点提取物：

将所有可本地化的资源移动到单独的纯资源 DLL。可本地化资源包括用户界面元素，例如字符串、错误消息、对话框、菜单和嵌入式对象资源。 （之后将资源移动到 DLL 会很痛苦）
不要对字符串或用户界面资源进行硬编码。 （如果你不准备，你知道你会硬编码字符串）
不要将不可本地化的资源放入纯资源 DLL。这给翻译者带来了困惑。
不要使用在运行时从连接的短语构建的复合字符串。复合字符串很难本地化，因为它们通常采用不适用于所有语言的英语语法顺序。 （界面设计后，词组变难了）
避免歧义的结构，例如“空文件夹”，其中的字符串可以根据字符串组件的语法角色进行不同的翻译。例如，“empty”可以是动词也可以是形容词，这会导致意大利语或法语等语言的不同翻译。 （同样的问题）
避免在应用程序中使用包含文本的图像和图标。它们的本地化成本很高。 （使用在图像上渲染的文本）
为字符串长度在用户界面中的扩展留出足够的空间。在某些语言中，短语可能需要多出 50-75% 的空间。 （同样的问题，如果你现在不计划，重新设计会更昂贵）
使用 System.Resources.ResourceManager 类根据文化检索资源。
使用 Microsoft Visual Studio .NET 创建 Windows 窗体对话框，以便使用 Windows 窗体资源编辑器 (Winres.exe) 对它们进行本地化。不要手动编写 Windows 窗体对话框。

【讨论】：

【解决方案2】：

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

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

您应该将所有文本（标签、按钮文本等）作为数据存储在数据库中。用键引用这些（我更喜欢使用前 4 个单词，大写，转换为下划线的空格和去除非字母数字），当你有重复时，在末尾附加一个数字。这种key方法的好处是程序员只要看key就对文本的内容有很强的理解。

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

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

要避免的一些基本事情：

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

【讨论】：

就 YAGNI 而言......是的，我认为很多东西都是这样。这是我一直在努力的一个领域。国际化是扩大产品用户群的常用方法，因此您要确保自己能够做到。我从事的一个项目确实做不到。那很糟糕。

【解决方案3】：

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

【讨论】：

【解决方案4】：

一些需要思考的问题...

你怎么能承受延迟你的应用程序的英文版的发货，以节省一点成本以后国际化？

如果你不能从快速发布英文版中获得现金流，你还会交易吗？

如果您没有快速从某些客户那里获得反馈，您将如何正确地设计 UI？

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

您的英语客户是否希望能够在 UI 中自定义字符串，例如并非每个人都以相同的想法称呼“装运单”。

由于国际化的很大一部分痛苦是确保您不会破坏英文版本，因此 UI 的自动化系统测试是更好的投资吗？

我认为我会一直做的唯一一件事是：“不要使用在运行时从连接的短语构建的复合字符串”，如果你这样做了，请不要传播那些通过许多方法构建单个字符串。

让你的 UI 自动调整大小（和布局）以适应标签的长度等，如果你能以低廉的成本做到这一点，那么多年来将为你节省大量时间。有许多适用于 Windows 窗体的 3rd 方控件集，可让您标记文本框等，而无需将标签作为单独的控件放置。

我刚开始国际化一个 WinForms 应用程序，我们希望大部分能够使用每个控件的“名称”作为查找键，而不必将大量移动到资源文件等中。这并不总是像你那么难一开始想……

【讨论】：

【解决方案5】：

您可以使用 NGettext.Wpf（它可以从 NuGet 安装，是的，我是作者，但我是从其他答案中列出的挫败感中做出来的）。

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

NGettext.Wpf 旨在与依赖注入一起工作。您需要在应用程序的入口点调用以下内容：

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

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

现在您可以在 XAML 中执行类似的操作：

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

这展示了这个库的两个特性。最重要的是 Gettext 标记扩展，它将确保 Content 设置为相对于当前文化的“英语”翻译，并在当前文化更改时更新它。它演示的另一个功能是ChangeCultureCommand，它将当前文化更改为给定文化，在本例中为"en-US"。

我还强烈建议阅读 gettext 实用程序手册中的 Preparing Strings。

【讨论】：

【解决方案6】：

国际化将使您的产品在其他国家/地区可用，这很容易并且应该从一开始就完成（这样全世界讲英语的人都可以使用您的软件），这 3 条规则将帮助您顺利到达那里：

支持国际字符 - 在文件和数据库中仅使用 Unicode 数据类型。
支持国际日期、时间和数字格式 - 将数据存储到文件或计算机可读存储时使用 CultureInfo.InvariantCulture，在显示数据或解析用户输入时使用 CultureInfo.CurrentCulture，永远不要自己解析，永远不要使用任何其他文化对象.
用户输入的文本数据应该被认为是一个黑盒子，不要试图把它分解成单词或字母，尤其是在向用户显示时——不同的语言有衍射规则，操作系统知道如何向左显示-to-right 文本，你不需要。

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

【讨论】：

【解决方案7】：

如果您使用测试数据，请使用非英语（例如：俄语、波兰语、挪威语等）字符串。编码在每个角落都可以看到它的小丑头。如果不在您自己的库中，则在外部库中。

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

【讨论】：

奇怪！打了三遍同样的错字。即使在我的母语中也不是这样写的。而我写的其他语言是正确的.. 有时我连自己都自欺欺人