国际化的设计考虑因素

Question

我读过乔尔关于Unicode的文章，我觉得我至少从字符集的角度对国际化有了基本的把握。除了阅读this question之外，我还在设计考虑方面做了一些关于国际化的研究，但是我不禁怀疑还有很多我不做的事情。知道或不知道要问。

我学到的一些东西：

• 有些语言从右到左阅读 而不是从左到右。
• 日历，日期，时间，货币和 数字显示不同 从语言到语言。
• 设计应足够灵活 容纳更多的文字，因为 有些语言更冗长 比其他人。
• 不要带图标或颜色 当涉及到他们的时候被授予 语义，因为这可能会有所不同 从文化到文化。
• 地理命名法不同于 语言到语言。

我在哪里：

• 我的设计足够灵活 容纳更多文字。
• 我自动翻译每个 字符串，包括错误消息和帮助对话框。
• 我还没有到达某个地方 我需要显示时间单位， 货币或数字，但我会 不久之后，我们需要 制定解决方案。
• 我正在使用UTF-8字符集 全面。
• 我的菜单和应用程序中的各种列表已排序 每种语言按字母顺序排列，以便于阅读。
• 我有一个提取的标记解析器 过滤掉停用词的标签。该 停用词列表是特定于语言的 并且可以换掉。

我想了解更多信息：

• 我正在开发一个可下载的PHP Web应用程序， 所以关于的任何具体建议 PHP将不胜感激。 我已经开发了自己的框架和 我对使用其他人不感兴趣 此时的框架。
• 我对非西方人知之甚少 语言。有具体的吗？ 需要考虑的因素 考虑到我没有提到 以上？另外，PHP的数组如何 排序功能处理非西方 字符？
• 是否有任何特定的陷阱 你在实践中经历过吗？我正在考虑GUI和应用程序代码本身。
• 任何具体的建议 日期和时间显示？有没有 根据地区或 语言？
• 我见过很多项目和网站 让他们的社区提供 翻译他们的应用程序 和内容。你推荐这个吗？ 什么是一些好的策略 确保你有一个好的 翻译？
• 这个问题基本上就是这个问题 我所知道的 国际化。什么不是我 知道我不知道我应该 进一步研究？

编辑：我添加了赏金，因为我希望从经验中获得更多真实的例子。

Answer 1

Answer 2

当我们处理Dreamfall和柯南时代的i18n / l10n问题时，我们遇到了一些值得记住的问题。其中一些我们解决了，一些是为我们解决的，一些我们解决了。有些我们从未解决过......

• 确保所有工具和所有代码都支持您要使用的所有字符集，并在项目过程中再次检查该假设两次，并确保更多次。

  < / LI>

• 确保使用支持您要使用的所有语言的字体。声称为unicode的大多数字体只是unicode，因为它拥有的字符位于正确的代码点。这并不意味着它对所有代码点都有可用的字符。

• 文本换行不仅仅是在空格处完成，因为有些语言不会使用空间来分隔单词（中文会浮现在脑海中）。确保文本换行例程处理文本时没有任何空格。

• 在容易的情况下正确处理复数是很棘手的，并且在困难的情况下很难处理。确保您对将要使用的语言有足够的了解，以便能够编写代码来正确处理复数问题。请记住，英语（和其他“西方”语言是容易的。

• 永远不要破坏句子并使用它们构建字符串以适应变量，因为变量可能以不同的语言放在句子的其他位置。使用占位符。

• 请记住，对于某些语言，占位符的值可能会更改如何编写句子。语法很难。确保你有一个处理它的计划。 （具体来说，请确保您有办法根据性别，时间等对您在占位符中使用的值进行分类。）

Answer 3

  

  
• 我的菜单和各种列表   应用程序按字母顺序排序   为每种语言更容易阅读。
  

列表应该排序，菜单不应该排序。请记住，给定用户可能希望以多种语言使用您的应用程序，他仍然应该在同一个地方的任何地方找到它。

与快捷方式相同，如果您有，不翻译。

另外，请记住，国际化和翻译是两个截然不同的事情，分别管理它们。

Answer 4

我想发表以下评论 - 这些评论来自一些公司指南，其中第1类产品在 31 不同的语言环境中进行翻译。遵循这些指导方针为我们（我们的开发团队而不是整个公司）提供了最高的翻译效率。

• 不要尝试重用错误消息的片段。例如，不要认为这是因为您有两个错误"You selected the wrong menu item"和"That menu item is not yet available"，您可以将"menu item"提取到一个单独的项目中并在两个地方使用它。 所有消息应该是自包含的，因为它们的翻译可能会根据上下文而改变。

• 使用专业翻译了解技术。如果你去接近像BabelFish这样的服务，你将得到你应得的一切。例如，"Microsoft Windows"在地球上的任何地方都是"Microsoft Windows"，在德国不会变为"Microsoft Fenster"。

• 尽量不要在 中嵌入变量（例如"The %1 has failed"其中%1动态更改），因为职位和性别可能会发生变化：{{ 1}}与"La table est rubbish"或"L'Homme est drunk" vs "The red table"。最好使用附加参数的通用名词："La table rouge"。

• 只翻译用户期望看到的内容。日志文件中的日志消息（只有您将使用）应该是英文（或您的母语），而不是翻译对于像斯瓦希里语那样你无法读懂的东西。

• 菜单应按功能排序，而不是按整理顺序排序。

• 可翻译单元应 external 存储到代码中并在运行时加载。这使得翻译成为一个只关闭外部文件的问题，而不是试图将更改转变为代码中间。这也使得将来更容易添加其他语言。

现在已经够了。最好在你们都入睡之前停下来： - ）

Answer 5

关于数字的事情：在英语中，据我所知，你只使用1和1的复数和2或更多的复数。喜欢：“你有1条消息”; “2条消息”; “3 ...消息”。在俄语中，这些事情变得更加复杂。你使用单数为1,21,31,41 ... 101,121（因此，对于以1结尾的所有内容，除非它以11结尾）。然后你使用奇异的格式为2,3,4; 22,23,24; 32,33,34 ...... 102,103,104; 122,123,124。在所有其他情况下，你使用复数格式。

实施起来并不难。 很难实现的是实现一些知道如何处理任何先验未知语言的东西： - ）

这只是数字： - ）

Answer 6

到目前为止，我还没有很多内容可以添加到最佳答案中，但这里有一些需要考虑和检查的事情。

• 不要做出假设。这是捕获所有规则。很容易假设区域或语言特定的东西，很难注意到这些假设。
• 对字符串比较要非常小心。有一些语言，例如土耳其语，其字母与其他字母在视觉上相似但不同。
• 使用伪翻译作为冒烟测试。如果您从资源文件中读取已翻译的字符串，请创建该文件的伪翻译版本，这对您来说仍然是可以理解的，但会强调容量和功能应用程序中每个可翻译字符串的。例如，用“CancelXXXX！”之类的东西填充像“取消”这样的字符串。因此它与翻译字符串的宽度一样宽。然后，您可以测试以验证每个字符串是否将完全显示。额外的功劳还包括可能被渲染的最复杂的角色，以验证它在所有地方都能正确显示。
• 不要对键盘布局做出假设。“ASDW”可能是QWERTY键盘的一个很好的方向键控制集，但硬编码使得它不友好，如果不是不可能的话，用于有其他键盘布局的人。
• 测试各种日期设置，然后重新测试。我看到的问题是由于区域设置中“AM / PM”的格式不同。 mm / dd / yyyy与dd / mm / yyyy的关系也很多，但这里的每个设置都很重要。
• 测试各种数字格式，然后再次测试。例如，您不想依赖小数或千位分隔符。
• 使用和不使用用户登录服务器进行测试。这可能更具Windows特定功能，但很容易在服务器上配置一个组件，以便它使用登录用户的用户登录时的区域设置和用户未登录时的默认区域设置。这可能会导致奇怪的，间歇性的行为。
• 使用各种区域和语言设置进行测试。作为示例，Windows不仅具有区域和语言设置，而且IE还有自己的语言设置。例如，首先列出en-us的IE客户端的行为可能并不总是与首先列出的en-nz相同。
• 确保您的翻译人员了解业务和语言，然后与其他人进行交叉核对。每次使用特定于应用程序的术语时都要非常小心。如果您的程序使用特定的单词来表示应用程序中的特殊内容，请确保它们在每个实例中都以类似的方式进行翻译，包括在帮助文本中。如果你有特定的语言目标，你甚至可以提前翻译这些单词，并确保它们不会在目标语言中翻译得不好。这更像是一个产品研究的东西，但它可以改变界面中使用的单词，如果这些单词从一开始就适用于每个人，那就更容易了。你也想避免使用不能很好翻译的习语。

好的，我还有更多的话要说...

Answer 7

我学到了很多东西：如果你有几个需要翻译的文件，请在名称中加一个额外的标签，以便以后你可以在整个文件夹中搜索该标签。

e.g。而不是命名文件'sample-database.txt'命名英文版'sample-database-loc-en.txt'，意大利语版本'sample-database-loc-it.txt

Answer 8

我在StackOverflow中的第一个答案，如果说有些愚蠢，请原谅。

根据我的经验：

• PHP ：gettext非常有用;
  
• 非西方语言：到处都是UTF-8（代码，数据库），到目前为止我们做得很好;
  
• 您在练习中遇到过哪些特定问题？如果字符串在网站中重复多次，翻译时将i18n的长段落分成不同的句子可能会更便宜只需要翻译一次。但是，要小心，如果你将文本分段太多，翻译者就会失去语境;
  
• 我见过很多项目和网站让他们的社区为他们的应用程序和内容提供翻译。您是否建议这样做以及确保您获得良好翻译的一些好策略？如果您有大量的志愿者去做，但是根据您有多少文字，您可能真的需要一个大量的志愿者。始终确保您有一个您信任的人作为语言项目的领导者，成为控制翻译准确性的校对者。
  

Answer 9

• 整理/排序规则在不同语言之间可能存在很大差异：ä在德语中的排序与在瑞典语中的排序方式不同。因此，分类需要针对特定​​文化。
• 大写/小写可以让人惊讶：德语“sharp S”字符ß没有大写版本，可以转换为“SS”，如果正确性很重要，则保持小写。土耳其语有一个无点的小写字母i和一个大写的点缀我。
• 对于多语言网络应用，请仔细考虑如何确定要显示的版本以及如何将其应用到网址中。用户应始终能够手动选择语言，并希望搜索引擎在不同的URL下查找不同的语言版本。
• 一些东亚语言（即日语和中文，可能还有其他语言）之间没有空格
• 日语（也许是其他人）也有阿拉伯数字和空格的单独版本（“全宽”），甚至还有一些自己的角色（半角和全角片假名）的两个版本。

Answer 10

是的，这是大量主题。正确的做法是非常多的工作。

在我的程序中，我为每段文本使用一个整数键，并根据语言根据需要在文件中查找。代码中的任何地方都没有文字字符串，只有键。我用C ++中的“枚举”来定义它们，所以我实际上并没有输入数字。当我添加更多枚举时，我编写了一个实用程序来同步各种语言文件，并且翻译人员填写了空白。

每个键还有一个相关的工具提示，图像，键盘快捷键等。

至于时间和日期......再次，这比你想象的要复杂得多，但PHP不会为你处理这个问题吗？ （我不知道，我是C ++家伙......）

Answer 11

PHP在内部将字符串表示为字节流，并假设iso-8859-1，对于编码很重要的情况。在大多数情况下，你可以在整个地方使用UTF-8，你会没事的。一个问题是，如果您的网站从其用户那里获得输入，那么您永远无法100％确定他们是否以正确的编码提交内容。您可能希望使用mb_detect_encoding来验证输入，或使用带有“异国情调”字符的隐藏字段进行验证。

请注意，PHP中与字符串相关的所有函数都以字符为基础，假设character = byte。这意味着您通常不能信任字符串函数。有关详细信息，请查看this page。

PHP的另一个好资源是Nick Nettleton's cheatsheet。

与字符集/编码密切相关的主题是collation。您需要使用排序规则来匹配您正在使用的语言/文化。至少在MySql中（可能在其他RDBMS中），您可以在不同级别指定排序规则，例如每个数据库，每个表，每列甚至在查询本身。