代码之家  ›  专栏  ›  技术社区  ›  Justin Bozonier

几年内将桌面应用程序国际化…我们现在该怎么办?

  •  16
  • Justin Bozonier  · 技术社区  · 16 年前

    我想换言之,是否有任何国际化现在很容易,但如果我们让代码库成熟,那么国际化可能会更糟糕,如果我们选择现在就开始这样做,这不会让我们慢很多?

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

    6 回复  |  直到 6 年前
        1
  •  33
  •   Vinko Vrsalovic    16 年前

    以后的一切都太晚了。要么现在,要么永远!

    的确,现在做好准备需要付出额外的努力,但如果不这样做,成本会高很多。

    如果你不愿意遵循下面链接中的所有指导原则,那么至少要注意总结中的第1、2和7点,这三点现在做起来非常便宜,而且在我的经验中,这会给我带来最大的痛苦。

    检查这些指导方针,亲自看看为什么现在就开始,做好一切准备更好。

    1. Developing world ready applications

    2. Best practices for developing world ready applications

    1. 将所有可本地化的资源移动到单独的仅限资源的DLL。可本地化资源包括用户界面元素,如字符串、错误消息、对话框、菜单和嵌入式对象资源。 (之后将资源移动到DLL将是一件痛苦的事情)
    2. (如果您不准备,您知道您将硬编码字符串)
    3. 不要使用在运行时从连接的短语生成的复合字符串。复合字符串很难本地化,因为它们通常采用不适用于所有语言的英语语法顺序。 (在界面设计之后,更改短语变得更加困难)
    4. 避免使用模棱两可的结构,例如“空文件夹”,其中字符串可以根据字符串组件的语法角色进行不同的翻译。例如,“empty”可以是动词或形容词,这可能导致意大利语或法语等语言的不同翻译。 (同一期)
    5. (使用在图像上渲染的文本)
    6. 在用户界面中为字符串的长度留出足够的扩展空间。在某些语言中,短语可能需要50-75%的空间。
    7. 使用System.Resources.ResourceManager类根据区域性检索资源。
        2
  •  4
  •   TravisO    16 年前

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

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

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

    http://www.microsoft.com/globaldev/getwr/dotneti18n.mspx

    要避免的一些基本事项:

    • 永远不要试图通过附加两个现有条目来创建文本,因为每种语言的语法差异很大,这是行不通的。因此,如果您有一个显示“单击”的字符串,并且想要一个显示“立即单击”的字符串,请不要尝试创建一个合并两个条目的设置,或者在翻译过程中,为“单击”复制单词并立即翻译单词。将每个字符串视为从头开始的全新翻译
        3
  •  2
  •   Hapkido    16 年前

        4
  •  1
  •   Ian Ringrose    15 年前

    一些问题 关于

    如果你不能很快从英文版本中获得现金流,你还会交易吗?

    迅速地 从一些客户那里得到了什么?

    在国际化UI之前,您多久重写一次UI?

    国际化的痛苦很大一部分是确保你不破坏英文版本,那么UI的自动化系统测试是更好的投资吗?

    我认为我将永远做的唯一一件事是: 如果你这样做了,不要把构建一个字符串的代码分散到很多方法上。

    我刚刚开始国际化一个WinForms应用程序,我们希望能够使用每个控件的名称作为查找键,而不必将大量内容移动到资源文件中等。这并不总是像您最初想象的那样困难。

        5
  •  1
  •   Robert Jørgensgaard Engdahl    6 年前

    您可以使用NGettext.Wpf(它可以从NuGet安装,是的,我是作者,但我是在其他答案中列出的挫折中完成的)。

    它是在今天举行的 github repository

    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" .

    Preparing Strings 从gettext实用程序手册。

        6
  •  0
  •   Nir    16 年前

    国际化将使您的产品在其他国家可用,这很容易,而且应该从一开始就做到(这样全世界讲英语的人都可以使用您的软件),这三条规则将让您在实现这一目标的过程中发挥最大的作用:

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

    本地化就是将软件翻译成不同的语言,这既困难又昂贵,一个好的开始就是不要硬编码字符串,也不要用较小的字符串造句。

        7
  •  0
  •   Boris Callens    16 年前

    如果使用测试数据,请使用非英语字符串(例如:俄语、波兰语、挪威语等)。

    我个人喜欢俄语,因为尽管我一个字都不会说俄语(尽管我的名字来源于俄语),但俄语中有外来字符,而且比英语占用更多的空间,因此也测试了你的间距。
    我不知道这是否是特定于语言的,或者只是因为我们的俄语翻译喜欢冗长的字符串。