如果我想在国际上部署我的软件，我应该考虑哪些架构考虑因素？

Question

我正计划为国际市场开发软件。

我应该考虑哪些架构决策，而不仅仅是将文本从一种语言转换为另一种语言？

Answer 1

存在大量问题，具体取决于您对此感兴趣的程度。

1. 数字 - 包括千位和小数分隔符。实际上，并非所有语言环境都使用每三位数的分隔符。将数字写成文本（比如写支票）的规则差异很大。
2. 货币和度量 - not all currency has two digits of decimals。标志可以是前导或尾随。否定指标可以是符号，括号或前导或尾随文本（如“dr”和“cr”有时在美国英语中使用）。测量的类似问题（英语与公制与本地相比）。
3. 语言脚本 - 它是not always left-to-right, top-to-bottom。 Unicode是必须的。此外，文本布局按语言更改。翻译时，相同的文本可以更短或更长，这意味着表格必须是灵活的。
4. 文字字符串与可翻译字符串 - 某些文字是文字的，不会被翻译;如果您预先设计并确保可翻译的字符串得到一致处理（通过资源或任何可用的东西），它会很有帮助。您还需要为插入文本模拟“abc {1} xyz”或“abc％1 xyz”之类的字符串而不是“abc”+ n +“xyz”，因为插入文本的位置会因句子结构。
5. 日期和时间 - 并非每个国家/地区都使用相同的日历;有些人有不同的年度计算系统。为了获得乐趣，有时可以浏览java.util.Calendar或System.Globalization.Calendar类。
6. 图标和颜色 - 在一种文化中看起来像是一只粗鲁的手可能是另一种文化中的冒犯性举动。颜色也有不同的含义。

国际化（I18N）可能是一个大问题，但它不是压倒性的。选择您的范围，然后深入。一旦完成前几个区域设置，它就会变得更容易。 ：）

希望这有帮助。

Answer 2

法律后果。微软现在是going through that with the EU。

将文本从一种语言“转换”为另一种语言也是不够的。不同的文化有不同的规范：在加拿大的某些地方，法语必须高于英语翻译。

Answer 3

处理应用程序中显示的任何文本的资源文件。在为其他国家/地区进行翻译时，这将使事情变得更加容易。

还要确保您的控件/布局能够处理不同的文本长度/宽度，因为一种语言中的按钮文本可能比您为其设计/创建应用程序的原始语言长得多。 / p>

Answer 4

• 考虑语言的细微差别。例如，“家常”在某些英语区域意味着舒适，在其他地方意味着丑陋
• 同时考虑到文化差异 - 竖起大拇指并不是一件好事

Answer 5

• 确保您的申请通过The Turkey Test
• 确保您的人不仅知道目标国家/地区的语言，而且还知道他们的文化和俚语，因此您不会以某种主要冒犯某人的方式命名您的应用或其任何组件
• 确保处理图形的人知道如何正确绘制国旗并了解世界地理位置，因此您要么不冒犯它们，要么drown any country。

您的软件必须是可本地化的，因为翻译人员不仅可以轻松翻译GUI中的文本，还可以调整其外观，使文本真正适合那里。

如果您的软件使用任何在线服务，请确保它使用目标国家/地区的服务，因此德国用户不会使用获得位于美国的在线照片打印服务。

Answer 6

1. 研究并了解您的平台对本地化软件的支持。
2. 使用平台的工具来满足您的行为要求。

当我们不知道您是在使用Mac还是使用嵌入式微波炉系统时，我们无法真正了解具体细节。

Answer 7

没有关于你在这里工作的项目类型的信息，但是......

1）使您的资源可以轻松交付给翻译人员。这在很大程度上取决于您当前所处的环境，但大多数人都有一些干净的方法。尽早设置它以避免大规模的转换项目。

2）如果您的环境允许，最好使包含翻译的UI可以在每种语言的基础上进行配置（例如对话框）。通过这种方式，翻译人员（或您）可以调整chrome以适应语言。这避免了某些语言中的剪切文本比其他语言更长。或者更糟糕的是，我已经看到UI被实现，这样控件之间有很大的空间来解释那些冗长的语言（我在看你，德语）。最低公分母实现应始终为红旗。

Answer 8

您完全没有提供有关什么类型的软件或什么平台的任何信息。另一方面，你听起来像是要写软件，所以你不会因为糟糕的决定而陷入困境。

最重要的是显示屏，因此请将显示屏功能与其余部分分开。不要，重复不要，对任何字符串进行硬编码。它们需要保存在一个单独的功能表中，具有您可以轻松提供的上下文。不要硬编码显示布局，特别是因为英语是大多数用途的非常简洁的语言，并且大多数字母语言通常需要更多空间来说同样的事情。警惕用case做任何事情，因为大写和小写用不同的语言做不同的事情。确保您对用户可能看到的所有文本使用Unicode。

请记住异常字符串应保持一致，如果您正在使用它们，并且要记录的错误消息最好保存为英语（或者您的母语），具体取决于您或当地人是否将要检查它们。

无论您使用何种系统，都可能拥有某种语言环境。将它用于它处理的一切。你不想在2009年2月9日在英国写出2月9日，因为他们会把它读作9月2日。人们会理解写出一百万作为1,000,000.0，但对于一些人来说这是明确的外来构造，他们希望它为1.000.000,0。

尽量避免将数字嵌入句子中。在英语中，人们会说“打印1页”和“打印2页”，可能是“没有打印页面”。在其他语言中，事情变得非常复杂。像“打印页数：2”这样的东西更容易翻译。

确保用户可以使用公制系统和Celcius温度。要么全部使用度量标准，要么在显示层中转换它。

为您将要本地化的每个地方获得真正的翻译。谷歌最适合初始模型，但你可能希望在你销售的国家/地区听起来更有文化，比如说“你所有的基地现在属于我们”。确保他们有足够的信息来完成这项工作;英语中的一些单词和短语含糊不清，其含义取决于语境，因此如果没有语境，它们可能无法翻译。一些好的翻译软件的预算（如果适用于您的平台）。翻译并不便宜，花几千美元来帮助他们更快地工作会很快得到回报。

如果可能的话，让本地人进行beta测试本地化版本，并注意他或她抱怨的内容。

这就是我现在所学到的，而且我正在慢慢地将我们的软件在日本使用。

Answer 9

国际化有两个方面：文化和语言。

语言是最明显的，这里的其他评论总结得很好。

资源用户可见的所有内容，包括错误消息。确保您的设计中有足够的空间，例如德语提示，其大小是英语的两倍。确保正确显示数字和日期。对于从右到左的文化，可能需要颠倒工具栏和显示工件。

Subtler在很多方面都是文化差异。这需要从一开始就考虑正确，因为有些会影响您设计软件的方式。首先：

• 期望什么样的工作流程？一些文化（如西班牙，意大利）比其他文化（如瑞典或芬兰）更具协作性。

• 该软件的预期客户是否会使用它？在某些文化（例如中东），对于根本无法访问计算机的管理者存在强烈偏见。相反，他们的工作人员代表他们阅读邮件。

• 本地软件生态系统不一定符合西方规范。例如，本地社交网站可能比Facebook和Twitter更受欢迎。

如果您希望在非本地市场销售软件，那么在编码甚至开始之前都需要考虑这些因素。有一个完善的产品营销专家基础设施，可以帮助这种当地的观点。

即使对于内部IT应用程序，也值得与本地用户合作以确定其软件的特定需求。公司主要国家以外的分支机构的经理有时可以抵制不符合其文化规范的系统的实施。