17

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

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

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

4

7 回答 7

33

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

现在以后的一切都为时已晚。机不可失，勿失良机！

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

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

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

  1. 开发世界就绪的应用程序

  2. 开发世界就绪应用程序的最佳实践

少量提取物：

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

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

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

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

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

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

一些基本的事情要避免：

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

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

于 2008-11-07T00:38:36.243 回答
1
于 2009-06-02T11:45:01.990 回答
1

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

它托管在这个github 存储库中，这是撰写本文时的入门部分：

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。

于 2019-03-29T09:34:30.143 回答
0

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

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

于 2008-12-29T09:44:44.143 回答
0

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

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

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

于 2008-12-29T10:39:10.507 回答