国际化最佳实践¶
这些是应用程序开发者应该遵循的最佳实践，以确保他们的项目能够更轻松、更高效地进行本地化。
使用清晰、简洁和一致的语言¶
使用清晰、简洁和一致的语言和术语非常重要。这不仅对软件的美国英语版本用户有益，而且还能显著帮助翻译过程，最终惠及本地化版本的用户。请记住，大多数翻译人员不是英语母语者。因此，对于软件中消息的解释，任何疑问都可能导致意外的误译和本地化版本最终用户的问题。即使翻译人员正确理解了消息，模糊的原始消息在翻译后也常常会变得更加模糊。
具体来说，切勿使用俚语，并避免使用缩写。这些通常很难正确翻译。作为这些准则的示例，尽可能写“IP 地址”而不是仅仅写“IP”，写“字符集”而不是“charset”，写“应用程序”而不是“app”，写“/foo 文件夹”而不是仅仅写“/foo”，写“代理服务器”而不是仅仅写“proxy”，写“信息”而不是仅仅写“info”，写“数据库”而不是仅仅写“db”，如果指的就是“应用程序启动器”，则写“应用程序启动器”而不是仅仅写“launcher”。
同时，尽量保持一致。避免在软件的不同地方使用不同的术语或不同的拼写。例如，避免同时使用“e-mail”、“E-Mail”、“email”和“Email”的多种变体。此外，尽量与其它软件的术语保持一致，尤其是同一软件项目中的软件，例如，如果您的应用程序是 GNOME 应用程序，则与其它 GNOME 软件保持一致。 GNOME 词汇表 在选择术语时是一个有用的资源，并且应尽可能使用其中的术语和拼写。这在很大程度上帮助了翻译人员，因为他们可以在翻译其它应用程序时保持翻译数据库的小巧，并且仍然能够获得有用的结果，如果可以避免不同术语和相同术语的不同拼写的数量级差异的话。
消息应使用美式英语编写。请抛开（潜在的）个人感受，并避免使用除常用美式英语以外的其它拼写。具体来说，避免使用英式英语拼写，例如“colour”和“centre”。在原始软件消息中使用“color”和“center”代替。英式英语拼写可以通过英式英语翻译提供，并且在原始消息中使用统一的拼写方式有助于所有翻译人员的翻译工作。
使用一致的排版风格¶
请记住，在设计消息时保持一致不仅仅是使用一致的写作。它还在于一致地使用空格和换行符。否则相同的消息中空格或尾部换行符的任何更改都意味着翻译人员需要翻译的额外消息。因此，如果可能，请尽量避免尾部空格和换行符。此外，尽量保持一致，不要在冒号、问号、感叹号和其他标点符号前使用空格。
还应避免在消息中使用制表符。制表符通常用于控制台文本消息中的对齐，但制表符字符 (\t) 代表的空格量不容易通过视觉检查来确定，并且很难在翻译后的消息中使用正确的制表符数量以使翻译后的消息正确对齐，因为翻译后的单词或句子通常与原始文本的长度不同。请在消息中使用空格代替制表符（如果需要在消息中使用空格）。
在消息中标准化大写。GNOME 人机界面指南 (HIG) 有一个关于 排版 的章节，其中包含有关何时使用大写字母以及何时不使用大写字母的指南。
避免扩展缩写¶
无论好坏，当今互联网和计算机的使用都涉及许多缩写，例如 Tag Image File Format (TIFF)、Portable Network Graphics (PNG)、Internet Relay Chat (IRC)、Rich Text Format (RTF) 和 Plain Old Documentation (POD)。自然地，应用程序也需要在其界面消息中处理这些缩写。
这些通常被其缩写所熟知，而对其完整名称的了解则少得多。因此，避免在应用程序的消息中使用完整的名称。使用广为人知的缩写代替。例如，如果您的应用程序以 PNG 格式保存图像，那么就这么说，而不是说它以 Portable Network Graphics 格式保存图像。
在处理翻译时，这个问题变得更加突出。缩写跨越语言障碍。英语或西班牙语中的“PNG”图像仍然用印地语或日语中的“PNG”图像来指代。一位日本用户会通过其广为人知的原始“PNG”缩写来识别文件格式。
使用注释¶
Gettext 具有一个很好且非常有用的功能，即在源代码中紧挨着标记为翻译的消息的任何注释，都会被自动提取并在 .po 文件中与相关消息一起显示为注释。
为了区分面向开发者的注释和面向翻译人员的注释，请在注释前加上“Translators”，例如在 C 源代码文件中
/* Translators: This is a verb, not a noun */
gtk_label_set_label (label, _("Profile"));
在 GtkBuilder UI 定义文件中
<property name="label" translatable="yes" comments="Translators: This is a verb, not a noun">Profile</property>
在 GSettings 模式中
<!-- Translators: This is a verb, not a noun -->
<summary>Profile</summary>
在 Mallard 文档文件中
<p xmlns:its="http://www.w3.org/2005/11/its" its:locNote="Translators: Comment about text to translate.">Text to translate</p>
仅在消息中使用有效的 UTF-8¶
尽量始终将标记为翻译的消息保存在纯 7 位 ASCII 或 UTF-8 字符集中。避免使用任何其它字符集。
原因是技术性的。由于原始字符串及其翻译存储在相同的 po 文件中，它们需要使用通用的编码才能使 gettext 在访问特定字符串的翻译时能够正常工作。Gettext 在访问翻译时不会执行任何字符集转换。纯 7 位 ASCII 是大多数编码之间的唯一公共子集，因此它传统上是编写可翻译应用程序字符串的唯一选择。
或者，您可以最近在应用程序的可翻译字符串中使用 UTF-8。由于所有 GNOME 翻译都应编码为 UTF-8，因此这也将解决使用通用编码的需求。
不要标记空字符串进行翻译¶
在 po 格式中，空字符串（“”）是保留的，并且具有特殊用途。它始终用作 po 文件的 msgid 和键，并且在 po 文件中将其翻译作为 po 文件头。因此，标记空字符串进行翻译将无法按预期工作，因为 gettext () 调用返回的结果将是整个 po 文件头。解决方案是简单地不要标记空字符串进行翻译。
不要硬编码换行符¶
原因在于，使行具有适当的宽度，使用与编辑时不同的可变宽度字体，不仅是开发人员的难题，也是所有翻译人员的难题。此外，当开发人员更改硬编码的换行（从而需要更新所有翻译）时，换行符“移动”的危险被消除，如果删除了换行符。