本地化 GNOME 应用程序

您想要翻译 GNOME 吗？

介绍

GNOME 程序在编写时就考虑到了本地化的需求。这意味着这些程序可以在不同的地区以不同的方式运行：美国的打印纸张和欧洲的不同；在不同的地区温度会以当用户习惯显示为华氏或者摄氏；用户用到的程序界面使用的是用户的本地语言。

翻译是本地化过程的主要部分。绝大多数的 GNOME 翻译是由以该语言为母语的人作为志愿者完成的。他们将英文原文翻译为合适的内容，并且将包含这些信息的文件提交到 GNOME Git 仓库，以使得下一个发布版本中的软件包含新的翻译。

这篇文档将尽力为您解释如何加入 GNOME 翻译流程。

寻找您的小组

首先，已经有人在为您的语言工作了吗？如果有，他们应当在 GNOME 翻译项目小组列表中被列出。联系他们将是您要做的第一件事。您还可以查看已有语言列表。

如果您找到了您的语言的本地化小组，但是却无法与他们取得联系，请联系 GNOME 国际化(i18n)邮件列表。那里将有人告诉您应该如何处理接下来的问题。

如果还没有您的语言的本地化小组，您也应当联系上述邮件列表，这样您将可能被邀请成为该语言的协调人。

如果您已经成功地联系到了一个活跃的小组，您可以放心地跳过下一节，直接阅读“翻译”小节。

建立一个小组

如果还没有您的语言的本地化小组，同时您勇敢地志愿建立一个小组并成为其协调人，那么应当说，您是好样的！

协调人的角色

作为小组协调人，您是小组中的主要联系人并且有责任组织小组中的其他翻译者。这包括防止多个翻译者在互不知情的情况下同时翻译同一个文件。

协调人需要订阅 GNOME 国际化(i18n)邮件列表。我们强烈推荐所有 GNOME 翻译者这样做，同时要求协调人应当这样做。

此外，小组协调人需要使他们的语言在 l10n.gnome.org 中的页面保持更新。在 GNOME 翻译项目小组列表中找到您的语言的小组页面。如果有任何细节不是最新的，请将需要更新的详细信息发送至 GNOME 国际化邮件列表。您可以要求您的小组中的翻译者在 GNOME 翻译管理网站中创建一个账号（点击右上角的登陆连接）。并要求您的组员在创建账号时在他们账号的偏好设置中选择你们的语言。这样他们就会被添加到您的小组的页面中了。

最基本地，与您的翻译小组相关的Bug将会指向您。(在您的翻译被使用前可能不会接收到很多Bug。)正如前面所描述的，您的语言将在Bugzilla中拥有一个“组件”。翻译Bug将会在product项中填写为"l10n"，查看GNOME Bugzilla 中的L10N预览页面，也许您会得到更多启发。

协调人经常被期望处理更多有关翻译的技术工作，诸如复数形式，更新LINGUAS文件以及生成POT文件。(现在Damned-Lies已经可以自动生成大多数项目的POT文件。)

您可能还需要参与招募更多成员加入小组。更多的人的携手工作可以让翻译进展得更加快速，这也可能意味着您的工作将更有意义！

作为一个协调人，您同样有责任在需要的时候离职：比如说您不再有时间贡献给这项工作。如果您知道自己不能继续扮演这个协调角色，我们希望您尽可能找到一个可以替代您的人。您应当在更换协调人的时候在GNOME 国际化(i18n)邮件列表进行公告。

语言代码

首先，您应当找出您的语言代码。这是一个 2-3 个字母组成的代码。常见的语言一般拥有 2 个字母的代码，一些相对少见的语言则是 3 个字母。对于那些在多个国家/地区使用的语言，在语言代码后将会以一个下划线连接，后面是用大写字母表示的国家或地区的代码。这样可以进一步附加符号以及更合格的信息。现在，请记住典型的语言代码应当像以下的样子"fr"(法语French)或者"en_GB"(使用在英国 Great Britain 的英语)。

如果您不知道您的语言代码，可以尝试查看是否有人在其他项目上为相同的语言努力(比如 KDE, Mozilla以及OpenOffice 等) — 这些项目使用的是相同的代码。如果这也无济于事，请询问 GNOME 国际化(i18n)邮件列表寻求帮助。

GNOME 使用 ISO 标准 639(语言代码)以及 ISO 标准 3166(国家代码)中所定义的标准代码，gnome-i18n 成员将帮助您找到您的语言代码。

您的语言代码是用来识别您的本地化工作的，就像地名和文件名。一旦您的代码被确定，就可以开始翻译了。

开始时您所需要的

有一些东西可以在您的翻译工作中提供极大的帮助。

一个邮件列表

• 您的小组需要一个可以谈论的论坛，且最好是用你们自己的语言。您可以使用它来监控谁正在翻译什么、讨论困难的词句或者术语，并推敲出一个术语表。与在其他项目翻译同一语言的小组（例如 KDE）共享邮件列表是一个不错的选择。这里也是您宣布关于翻译的公告的好地方。 邮件列表也可以作为用户给翻译者提供反馈和常规问题讨论的场所。

一个网站

• 网站有利于向人们介绍你们的努力、分发工作以及跟踪谁在做什么，这里同样可以保存诸如术语表等有用的东西。

一个术语表

• 在翻译中使用相同的术语以使用户不感到迷惑是一件很重要的事。一个标准术语表将帮助您确保不将同一个事物命名为多个不同的名称。不要总是尝试创造新的术语，而应尽量重复使用已有的 — 寻找您的语言的管理机构，或者在其它项目中使用的翻译，抑或是使用在 Microsoft Windows 或者 Apple OS X 上的术语。特别地，最好与其他自由桌面比如 KDE 保持一致。如果您觉得确实需要创建一个新的术语或者使用一个词语而不是另一个，请在您的术语表中对此进行说明。这样可以在将来的工作中减少误解和迷惑。您可以考虑在翻译进行一段时间后对您初始的术语表进行修订，因为那时您可能会注意到一些从前忽略的问题。

  一些语言小组同时还担负着翻译 KDE、Mozilla 或者 LibreOffice 的任务。在另一些语言中不同的小组负责不同的项目。在后一种情形下，保持与这些小组的联系并了解他们所使用的、废弃的将是一个非常好的办法。

  GNOME 文档项目风格指南和在 gnome-i18n 模块的 GNOME Git 仓库中的术语表应当说是您建立术语表的良好基础，当然这些内容需要您的一些调整和更新。

  另外的一个值得一提的建议是使用 Open-tran.eu 查阅您正要翻译的英文单词的已有翻译。此项服务同样可以搜索翻译中的不一致项。

一个IRC频道

• 一个IRC频道所带来的好处有很多，因为它如同邮件列表一样，除了能更方便各种讨论，更可以用于快速查询。它同样可以帮助到使用您的翻译的用户。Freenode 网络是一个专用于自由软件相关讨论的IRC网络，是一个适合您托管您的频道的地方。

Gettext 工具集

• gettext是一个用于创建可以翻译字符串、将这些字符串排列以便翻译、更新字符串以及将其转换为计算机可用格式的软件包。您小组中的任何人(尽可能多的真正)需要了解如何使用这套工具的基础知识。很多Linux发行版默认安装了这个软件包。如果您的没有安装，它通常仍然可用。您还应当看一下 intltool，这更像是一个 gettext 的前端，它可以帮助您处理一些作为 GNOME 翻译者所需要的任务。通常情况下您所使用的发行版中这个工具是可选的，但是通常最新的版本总是比发行版仓库中的高 1-2 个版本。您可以在 GNOME Git 中找到它。

翻译

这是我们最重要的地方。在 GNOME 2.4 的基础发行版中大约有 17,000 个独立的字符串。这不包括 Evolution，Epiphany，任何的IM客户端或者其他您可能认为必须的东西。您有很多策略和方法可以选用，但是无论如何都需要翻译这些字符串。

不同的方法

有很多不同的翻译方法。一些小组简单地打包“po 文件”给不同的成员，这些成员使用文本编辑器翻译它们并反馈给能提交到 GNOME 的人。还有一些小组使用基于 Web 的系统。所有的这些方法都有其优点和缺点。

.po 文件的详细信息作为最长的章节在本页的末尾。如果您不打算使用任何其他工具，您可以跳到 关于.po 文件部分。

Web 界面

一个Web界面通常是为所有人提供一系列等待翻译建议的字符串。有人定期清理所有的结果，并将它们反馈到 Git 仓库中。这样做的优点是只有小组协调人和 Web 界面维护者需要关心如何处理.po文件。这使的那些没有 GNOME 或者其他有用的翻译工具的人可以做这项工作。一个缺点是这样无法看到完整的文件，贡献者们可能不知道其他人是如何翻译同一个应用程序的。如果您的小组正准备保证一致性，这将是一个需要考虑的问题。另一个可能存在的问题是开发者给翻译者的注释不是总能被显示出来。

现有的 Web 界面包括：
Prevod
Kyfieithu

po 文件

有一篇非常好的文档讲述如何检出项目，创建.pot文件，转换为.po文件并且将其送入Git仓库：GNOME翻译者Git Howto。它解释了如何使用Git来维护GNOME的翻译。

请注意您可以通过语言状态页面来查看.po文件并获得最新的.pot文件。虽然一些非ASCII的特殊字符会因此而被表示错误，但它确实是Git外的一个绝佳选择。

一个.po文件通常是来自源程序的一些字符串的罗列，其中有您可以放置您的内容的空间。在其开始有一系列的文件头，其中的一些您可能必须要编辑。

• Project-Id-Version 应当是您所翻译的模块名称。
• POT-Creation-Date 通常是自动生成的。
• PO-Revision-Date 项您必须自己修改。
• Language-Team 应当是您的小组语言以及可以联系到至少一名小组成员的电子邮件地址。

• Content-Type 项必须是UTF-8而且您必须确保文件最终是UTF-8格式。

在UNIX和类UNIX系统中，file 命令将告诉您文件是什么格式。在一个已经安装了全套gettext工具的机器上，您可以使用msgfmt -cv filename.po。如果这个文件不是UTF-8格式的，msgfmt -cv命令将会产生一条错误信息来说明这种情况。

在文件中您会看到注释。当其中写道“c-format”，这意味着这些字符串中的一些将由程序本身来填充。例如，gnome-applets的时钟小工具有一条字符串是“%H:%M”，您可以将其直接放在翻译项中表示已翻译。这样程序将会显示时钟，%H是小时，%M是分钟。

这里有一个独立的关于常用C-format字符串的索引。

您还会遇到程序员留给翻译者的消息。例如在gnome-applets，紧挨着上述字符串您可以找到这样的注释：“translators: reverse the order of these arguments if the time should come before the date on a clock in your locale”。

您还将需要替换菜单项：键盘快捷键可以用来替代在菜单上的点击。在过去这可能是存在矛盾和冲突的一件事。现在它可能是一件首先影响gtk+，进而影响每一个单个GNOME应用程序的重要加速器。然后您可以使用保持的字母并找出哪些组合工作得最好。不要担心两个或更多的菜单项使用了相同的菜单项。从2.4开始，GNOME使得您可以在它们之间循环。

您将会很经常地遇到GConf键的描述。通常情况下一个键包含一个简短介绍和一个较长的描述。键描述字符串可以在 .schemas.in.h 中找到原文。

当翻译键描述是，请注意样例键值，通常是被双引号所引用的。他们不应当被翻译。例如：

#: src/gnome-terminal.schemas.in.h:70
msgid ""
"Default color of terminal background, as a color specification (can be HTML-"
"style hex digits, or a color name such as \"red\")."
msgstr ""
"Rhagosodiad lliw cefndir y terfynell, fel penodid lliw (gall fod mewn hecs-"
"ddigidau fel yn HTML neu fel enw lliw megis \"red\")." 

在例子中，“red”就是样例键值，并且必须被原样复制到翻译中。请注意因为双引号在.po文件中有特殊含义，必须使用反斜杠以使其表示通常含义。

如果您遇到了无法理解的英语内容，请毫不犹豫地向这个程序提交一个Bug来告诉开发者存在的问题。在提交前请在Bug报告表格的"Keywords"栏中添加"L10N"。如果您遇到了无法被很好翻译的英语内容(过于繁琐、不够准确等)，请同样提交一个Bug。翻译者是一组提交非常非常多的此类Bug的人，因为翻译者正是发现这些问题的人们。您越早提交这些问题越好。当您明白内容的含义时，您可能会忘记提交Bug。提交它们并且修正它们，会使其他翻译者不再需要与这些字符串费尽脑筋。

不要碰 msgid 行

不要编辑文件中的英文字符串。如果您那样做了，合并翻译到主程序的程序将会遇到问题。您在英文字符串上做的更改将会丢失，您的翻译也可能不会被合并入内。

处理变更

很不幸的一件事是软件在改变的同时所包含的需要翻译的内容也在改变。一些字符串被添加，另一些被修改，还有一些被删除。同时，很幸运的是，我们有一些工具和流程来帮助您紧跟正在翻译的软件里的变更。

状态表格

在关于GNOME的胡言乱语站点上您可以看到GNOME项目上每个语言、每个软件包的翻译状态表格。

点击“语言”，将显示出GNOME所包含的全部翻译语言。点击上面的任意一项将显示该语言的各个GNOME发布的软件界面以及对应文档翻译的详情。通过点击每一个发布，可以查看分软件包的翻译状态。这些页面上包含了最新.pot文件的连接以及最近的.po文件(如果翻译已经开始)。您可以直接在状态页面上下载而不一定要从Git仓库中取出。

在这个站点上，从2.14开始所有的版本都被维护，其中包括最新的稳定版本以及在下一个稳定版本中将会包含的开发版本软件包。

一旦翻译者的语言文件被提交到Git仓库中，您的语言将在站点中有其自己的显示位置。您可以将这个页面打上书签，这将会非常实用。

简体中文小组的页面是： http://l10n.gnome.org/teams/zh_CN

更新变更过的软件包

通常情况下当您提交翻译副本到GNOME Git仓库后刷新浏览器页面就可以看到新的翻译进度页面了，再一次地，GNOME翻译者Git Howto是为您准备的Git指南，其中讲述了必须的Git命令的使用方法。如果您使用Git检出了整个模块，您可以在终端中进度po子文件夹并输入intltool-update zh_CN，其中zh_CN代表简体中文，zh_TW和zh_HK代表繁体中文。这个命令将会更新您的po文件以使其包含最新的需要翻译的字符串。

另一种选择：如果您知道更多的字符串需要被翻译，那么您可以生成一个新的.pot文件，它包含了所有要翻译的字符串，然后将其与原有的.po文件进行合并。在po/子目录中使用intltool-update --pot命令生成最新的.pot文件，再使用msgmerge -o new.po zh_CN.po filename.pot将两者合并然后输入到new.po中。请务必注意以上命令几个文件名的顺序！

然后运行msgfmt -cv new.po查看还有多少工作要进行。如果您很幸运，会有很多被标记为“fuzzy”的字符串：一些与已翻译消息相似的内容，msgfmt程序将原来的翻译建议到新的字符串下供您参考。

Fuzzy 的翻译是...

msgmerge总是将fuzzy的翻译一遍一遍地搞错。每一个翻译者都会遇到它将本应翻译得很好的内容建议得很糟糕的时候：我最喜欢的一个是建议在“Open window”下的翻译应当被用在“Close window”下...

浏览整个新文件并找出所有标记为“fuzzy”的字符串。如果您觉得其中的翻译正确，就删除“fuzzy”。如果您不删除“fuzzy”，那么下面的翻译在最后不会被使用。例如：

#, fuzzy
msgid "Blah blah blah."
msgfmt "La la la."

在这里，如果您觉得翻译正确，那么删除整个含有"fuzzy"的一行就可以了：

msgid "Blah blah blah."
msgfmt "La la la."

然而您可能还会遇到下面的情形：

#, fuzzy, c-format
msgid "Very important: %s"
msgstr "非常重要: %s"

在这里，如果您想要清除fuzzy状态，"c-format"标签必须仍被保留：

#, c-format
msgid "Very important: %s"
msgstr "非常重要: %s"

有的时候一个全新的模块会带来一整套字符串。这经常让人感到沮丧，因为您可能觉得这些已经翻译过的内容又不得不再翻译一遍。您可以使用msgmerge来从其他模块中合并这些翻译以节省时间。您还可以生成一个自己的字符串数据库来保存、编辑已经翻译过的内容，并用做将来翻译建议的来源。您可以使用msgcat来完成这项工作：msgcat a.po b.po c.po > compendium。您应当在使用这个数据库来进行翻译前对其内容进行检查，尤其是形式上为“#-#-#-#-#”的，代表与原.po文件不同的条目。这个特性也允许您使用msgcat来查看不同.po文件之间的差异。一旦您使用msgcat创建了数据库，您可以使用msgfmt来检查格式，就像对其他.po文件一样。

您可能发现有很多消息在一个应用程序中都不再被使用了。它们将被移动到文件的底部，去除所有注释并在行首用#注释掉。它们通常是被忽略的。除非它们的数量非常之大以至于影响了您的工作，否则您不需要删除它们，也许它们还会回到应用程序中。它们同样可以被msgmerge作为fuzzy翻译的来源，将它们留在原处。

选择进行翻译的第一个软件包

这里有一些因素可能帮助您选择先翻译哪些内容。

第一次翻译最好是选择一些很小的东西来进行，以便由此来熟悉正在使用的翻译工具。选择翻译一个程序而不是函数库也是一个不错的建议。这样，您可以直接运行该程序并看到它的样子。所以一个小而独立的应用程序是不错的选择。

除非您的机器上运行的GNOME是从Git仓库中取出并构建的，您使用的应当是最近的稳定版本。因此，尝试翻译当前版本的软件是一个很好的初始选择。例如您有bug-buddy-2.4，就翻译Git仓库中2.4版本的bug-buddy，这样您可以在测试的时候看到全部的翻译。不过在将来的翻译中，简体中文组还是建议尽量参与最新开发版本的翻译，旧版本的翻译除非特殊需要将由专人从最新版本向下维护。

当您测试全新的语言文件时，可能会注意到一些常用的按钮仍然是英语的，这是因为它们来自GNOME的共享函数库。要将这些也翻译成您的语言，您需要查看GTK+，libgnome和一部分的libgnomeui。这些文件包含了一些非常难的字符串，但是您不需要将其全部完成，只要把您需要的字符串翻译即可，这已是极大的帮助了。

GTK+是一组名为“GNOME开发者平台”的软件包的一部分。它包含了这组软件包中接近半数的字符串。一旦您翻译了GTK+，您将在统计信息中看到进度的一个飞跃。当您浏览统计信息页面时，这个软件包的名称是“GKT+, 软件界面翻译”。

如果您的时间很有限，您可以考虑把一些不常见的字符串留下而不翻译(比如错误信息、属性等)。GTK+主干翻译被很多程序所使用，这将在您工作伊始给您一个做最少工作而获得最大收效的动机。举几个主干翻译的例子：“OK”, “Cancel”, “Open”, “Save”, “Print”, “Warning”, “Undo”, “Preferences”，这些内容的翻译将被大多数应用程序使用。

另一个附加的重要软件包是“gnome-menus”。它包含了您在系统的“应用程序”栏中看到的基本分类，包括“应用程序”本身，“附件”“Internet”“图形”“办公”等。

还有一个很有用的小文件是xdg-user-dirs，它并不在GNOME项目上维护。这个软件包包含了常用目录例如"Videos", "Pictures", "Documents"等。这将使您以最少的工作获得一个很大的效果。

部分用在Epiphany网页浏览器的字符串是来自于Mozilla的。所以即使您完成了整个的Epiphany，您还是可能遇到一些由Mozilla所提供的字符串没有被翻译。如果您的语言下有Mozilla语言包，可能您不会感觉到这一点，否则我们也做不了太多的什么。(当然，您可以说服一个朋友去翻译Mozilla...)

安装翻译

如果您有在一台安装有最新版本GNOME的机器上的root权限，您可以在您的机器上测试翻译并且查看其内容。这是被强烈推荐的。计算机需要一个消息目标文件(.mo)文件，您可以使用msgfmt -cv命令来创建。对您的文件运行该命令，例如msgfmt -cv zh_CN.po，您将在相应的文件夹内得到一个名字为“messages.mo”的文件。这个文件应当被放在“/usr/share/locale/zh_CN/LC_MESSAGES/”文件夹下，并且以程序名命名该文件。例如它们可能为“metacity.mo”或者“nautilus.mo”。有的时候一些程序名要求同时有版本号。不幸的是，没有什么简单的办法可以仅仅通过给出的软件包来决定.mo文件的名称。您可以查看“/usr/share/locale/“中其他姐妹文件夹(即其他locale)内的文件名称以做参考。

然后运行对应的应用程序。程序运行过程中更改.mo文件可能会导致应用程序崩溃，所以首先要保存您的工作；如果您正在将一个“gnome-terminal.mo”放在对应的地方，那么您需要提前为崩溃做好准备:)一旦文件处于正确的位置，程序将可以正常运行。仅仅是更新文件的过程可能导致问题。

对应的 locale 必须存在

以上的工作仅仅在对应的locale在您的计算机上存在。如果它不存在，您需要创建一个。在Debian上这件工作再简单不过了：那里有一个命令专门做这个工作。这个过程在不同的发行版本上可能不尽相同，而且这个话题不在我们这篇文章讨论的话题之内，欢迎补充。:)

当您掌握了如何在一台计算机上安装您的翻译后，将这些方法提供给那些可能感兴趣测试它的人们。其他人通常会比您找到更多的错误。他们也可能因此而产生加入并帮助的想法！

测试翻译

当您的桌面有一个很大的部分完成的时候，测试就显得至关重要了。这时您将发现您用了“安装”的地方也许其他人用了其他的词汇；或者是单词“body”在一些场景下并不指一个人的身体。

您自己或者您说服您的朋友做越多的测试越好。

编辑器和编辑器秘诀

很多编辑器拥有专门编辑.po文件的特殊模式，并且多数能够自动开启对应的模式。

您需要确保编辑器是在UTF-8编码下。如果文件不是UTF-8格式的，提交到GNOME Git仓库时将会遇到问题。

已知的可以处理UTF-8编码的编辑器： Emacs Vim GEdit KEdit

对于VIM，将以下内容放在~/.vimrc中可能会有所帮助:

set fileencodings=utf-8
" A vim macro that makes control-E copy the msgid to the msgstr:
map <C-E> :s/msgid "\(.*\)"\nmsgstr ""/msgid "\1"<C-V><CR>msgstr "\1"/<CR>

VIM还有一个专门为编辑.po文件而设计的插件，它提供了另外几个有用的功能。这个插件可以在Vim 网站或者po.vim处获得。

GNU-Emacs 拥有一个完整的PO模式。

还有一个程序叫做gtranslator可以帮助您翻译应有程序，尤其是翻译GNOME。

欢迎大家继续补充编辑器秘诀。

其他提示

有一些东西本是通过痛苦的经历才积累下的，现在我们把它们列举在这里以告诉其他人不要再这样做。

• 不要花费过多的时间到各个分支上。我们觉得是这样。您花费多少时间检出分支并且更新翻译，那么您的痛苦也就持续多长时间。如果您准备同时维护master和其他分支，那么请同时更新那些更改。如果不这样作，您会有一天划分很多很多时间来仅仅是把更新版本的翻译文件合并到较旧的版本中。
  如果您使用了一个慢速的网络连接或者是按流量计费的连接，检出每个分支到不同的目录中就不如在不同的目录中切换。使用Git这样做可能在最初的一次花费较多的时间，但是在将来可以节省更多的时间。

• 使工作自动化可能是更安全的。例如当您添加新的翻译的时候，您需要添加同样的内容到Changelog文件中以说明您在LINGUAS文件中添加了您的locale，也许这样工作最终您需要做五十次。那么使用一个文件编辑好所有的内容并每天更新，然后使用一个编辑器宏指令来完成剩下的工作。这比您手工地输入五十次要好的多。记得给经常使用的命令添加一个Shell别名。

• 寻找一个语言爱好者！您将会遇到各种各样奇怪的字符串，比如说在Gnumeric的英文原文中“The quick brown fox jumps over the lazy dog.”一句是用在字体选择器的预览框中的，因为它包含了所有的英文字母，您需要在自己的语言中找到一个与之等价的句子放在这里而不是简简单单地将其翻译。您将可能需要为您的语言找到或者发明一句包含所有字母的话。(对于中文一类的语言这件事可能很困难...)
  如果您的语言已经有了被广泛接受的对术语的翻译集合，那么您需要清楚它们，即使您不喜欢。准备好调整使用“官方”术语...

• 接受一些偶然出现被故意制造的可笑字符串。您将会在翻译越来越多的文件时遇到GNOME的hacker们开的玩笑。例如说GEGL，本应当是一个函数库，但是它也是“Genetically Engineered Goat, Large“(基因改造过的大山羊)的缩写，这只是GNOME中有趣玩笑的一个。这些内容没有必要被翻译。在一些文件中，会有关于它们的信息。
  忍受它们、接受它们，它们实际上是使GNOME变得有趣的一部分，尽管在您刚刚带着字典开始查找后再了解到这些含义会感到非常难以置信...

• GNOME 国际化(i18n)邮件列表和#i18n IRC频道可能非常忙碌(gnome-i18n)抑或是有点冷清(#i18n)，但是那里的人们也曾经遇到过您遇到的问题，他们可以告诉您如何对付这些问题。使用这两样东西。

• 工作中我们很容易乎落键盘快捷键前面的下划线。我们可以使用msgfmt --check-accelerators=_来检查msgids和msgstrs项中的"_"数目是否一致。

• 避免使用带有修饰的字符作为快捷键。当前情况下，如果您把快捷键设置为 Á, Å, ᾈ 一类的字符，用户就需要按住Alt键然后在去找这些字符。如果您的键盘布局需要一些死键，那么这样做便使得快捷键无法使用了。更多此方面的信息，参阅键盘快捷键和键盘修饰。

• 测试，测试，测试。虽然本地化您机器上的所有东西很困那，但是为几个程序安装您自己最新的翻译文件还是一件简单的事情。请这样做，它会很有帮助。
• 为所有已完成的翻译创建一个tarball。(又一个自动化的候选方法。)把它们放在互联网上以方便别人可以随时安装它们。这样可以使您更容易地获得回馈和帮助，而不是仅仅等着官方的发行。为不同发行版本准备的安装指导可能不尽相同，但是其结果告诉我们值得这样去做。

术语表

Git

• Git: 维护GNOME源代码仓库在一个中心位置的系统。

I18N

• 单词“internationalization“的缩写(起始字母和结尾字母中间包含18个字母)：确保应用程序可以被本地化的过程。

L10N

• 单词“localization”的缩写 (起始字母和结尾字母中间包含10个字母)：使程序可以在特定地区工作的过程。包括翻译信息，修改诸如度量衡单位、货币符号以及温标等内容。

A. po文件中的特殊字符和一个特殊字符串

这是一个关于C-format字符串的单独附录。这里列出了可能导致问题一些内容。

转义字符

• po文件中的一些字符将会被解释程序自动解析，如果要使它们在翻译中保持原样，需要在前面加上反斜杠。

  最常见的字符是双引号， " 。

格式标记

• 您可能遇到“\n”或者“/t”，他们分别代表这换行和制表符(Tab)。您不需要将同样数量的格式标记放在翻译中，但是如果它们之一有在原文开始或者结束位置的时候，您必须在翻译中使之包含在对应的开始或者结束之处。

GConf 文件中的角括号和&号

• 有一些模块中XML被频繁地使用。GConf是最明显的。XML将<, > 和 & 视为保留字符。 您不能将其直接添加到翻译中。您必须将其实体以下面的形式表示：

  &lt 代表 <； &gt 代表 >； &amp 代表 &。

TRUE 和 FALSE

• “TRUE”和“FALSE”出现于gtk+和Gconf，以及很多Glade所生成的文件中(这些文件以.glade为文件名结尾)，不要翻译它们。如果程序找不到它们，将会出现问题。

在.po文件中还有一个很特别的字符串：translator-credits。它会出现在您运行过程中选择查看鸣谢信息时。查看者可以看到一个翻译项，其中包含了“translator-credits”项下的内容。这里是放置您名字的地方，别人将可以从这里知道您的劳动。一个典型的格式是将名字和电子邮件地址列表如下：

msgid "translator-credits"
msgstr
"Telsa Gwynne <hobbit@aloss.ukuug.org.uk>\n"
"Dafydd Harries <daf@muse.19inch.net>"

不要忘记做这件事。

B. 一些需要保持的 C-format 字符串 — 或者需要重新排序的

这是一个您可能需要了解的C-format字符串列表。

%s

• 这代表一个字符串，在nautilus中的一个例子：

    #: components/emblem/nautilus-emblem-view.c:834
    #, c-format
    msgid "The file '%s' does not appear to be a valid image."
    msgstr ""

包含此C-format序列的字符串都同例子中一样被打上了"c-format"标签。您需要知道如果有两个或两个以上的此类条目，它们的内容通常是不一样的，另一个nautilus中的例子：

#: components/hardware/nautilus-hardware-view.c:483
#, c-format
msgid "Uptime is %d days, %d hours, %d minutes"
msgstr ""

如果您需要修改它们的顺序以使意思通顺，可以像下面这样做：

#, c-format
msgid "%d out of %d"

其显示结果可能是“10 out of 100”。如果您的语言中要说 “100 个中的 10 个”，您可以使用下面的方法调整顺序：

#, c-format
msgid "%d out of %d"
msgstr "%2$d 个中的 %1$d 个"

原作者

这篇文档的原作者是：

Telsa Gwynne

Dafydd Harries

翻译者

这篇文档的简体中文翻译者是：

Aron Xu <aronxu at gnome dot org>

Mandy Wang <wangmychn at gmail dot com>（更新）

许可

这篇文档可以在GNU通用公共许可证下修改或重新发布；或者是第2版或者是更新的版本。完整的许可证信息可以在以下位置获得：http://www.gnu.org/copyleft/gpl.html。

CategoryGnomeI18n