查看“上游项目”的源代码

上游(upstream)代表软件的上级维护者，例如 GNOME、KDE 等是 Debian/Fedora 的上游项目，Ubuntu 是 Debian 的下游项目，又同时是 GNOME、KDE 等的下游项目。于上游贡献因为会直接作用于所有下游项目，所以其效应显然比贡献于下游项目更加明显。我们推荐尽可能在上游项目上开展工作。

''本条wiki目前只涉及翻译相关的内如，欢迎编辑和添加其他方面的内容。''

==部分项目列表==

* [[上游项目/TP | Translationproject (aka TP)]]
* [[上游项目/GNOME | GNOME]]
* [[上游项目/KDE | KDE]]
* [[上游项目/XFCE | XFCE]]
* [[上游项目/Mozilla | Mozilla]]
* [[上游项目/OpenOffice.org | OpenOffice.org]]
* [[上游项目/Debian | Debian]]
* [[上游项目/Enlightenment | Enlightenment]]
* [[上游项目/其他项目 | 其他项目]]: 其他未列出的项目请在此页查找

==其他链接==
* [http://groups.google.com/group/i18n-zh i18n-zh] - 汇集众多大小软件项目的上游中文翻译工作者
* [[Ubuntu 简体中文小组]]
* [[Launchpad 简体中文小组]] - 负责很多将翻译设于 Launchpad 的上游项目的工作
* [[软件翻译]] 页面 - Ubuntu 中文 Wiki 翻译资料索引

==常规提交方式==
'''如果您要翻译的软件已经出现在上面的列表里，那么您不需要再继续阅读。'''<br><br>
虽然这组页面提供了很多主流项目的参与方法，但是必然还有很多软件无法照顾到。在此大致介绍一下比较常见的翻译工作方法。这些方法一般不适用于上述介绍的软件，越著名的软件的翻译项目也就越有自己的特点，所以往往会不同于小众软件而拥有自己独特的方式，切记。<br>
如果通过下面的方法依然找不到翻译的途径，那么请致函 [[Ubuntu 简体中文小组]]或[http://groups.google.com/group/i18n-zh i18n-zh]，这两个地方中的任意一个都会有人帮您寻找正确的路径。
# 找到要翻译的软件的真实名称。比如说 Vuze 这个软件曾经叫 Azureus，如果只安装过较老版本的软件，找项目的时候就可能找错。另外的例子还有 Gscrot 改为 Shutter。
# 找出项目的真实地址。可以通过搜索引擎来寻找，至于如何确定是真的就靠观察和研究了。谁能保证不再出现类似 emule.org 不是开发场所，真正的是 emule-project.org 这样的例子呢？
# 找到地址后查看一下首页上有没有 Translate, Localize, Contribute 一类的词语，有的话打开相应的页面看有没有各种指南，说明用什么平台来进行翻译或者指定什么方式提交。
# 很多项目使用 Launchpad, Transifex 这样的公共平台进行翻译；也有一些使用 pootle 这样的来协作。如果没有发现使用这些平台，则多数使用bug提交或者是邮件列表。同时还要确定软件的翻译技术形式，如果是 gettext 或者说使用 po 文件来翻译，那么下面的路径是一直有效的，否则只能作为一个参考。因为很多除了 gettext 这个在自由软件中最常用的工具外软件还有其他的办法实现国际化。如果因为这一点遇到问题，那么请联系本段开始时给出的两个小组之一寻求解决方法。
# 下面应该做的是设法得到最最新的翻译模板，如果以前有人进行过翻译还要找到最新的 PO 文件。要说明的一点是，翻译一定要做当前开发版本的，一般叫 trunk/head/master/development，这样才能在下次发布的时候随官方的 tarball 一起流传出去使最多的人受益。如果您的系统里已经装上了一个版本那么基本说明再做这个版本已经没有意义了，翻译也只能是到论坛发发帖子给几个看到的人用用。
##很多项目会在自己的翻译进度统计页面上给出 POT/PO 文件相关的链接，如果没有，很好的办法是找到其源代码仓库并下载其中的相关文件。多数的小众项目会在软件的相应目录(一般是 po 子目录)下把 .pot 文件生成好。当然也一定有很多没有的，这时有两个办法，一个是自己从源代码生成 POT 文件，相应的方法可以在[[软件翻译]]页面列出的文章中找到；另一个是发邮件到邮件列表或者到项目的论坛上发帖求助(如果有的话)，不过论坛可能很少有人会帮助您，一些时候是大半个月后有人给您回个帖子，说我路过...
##首先查看最近一个翻译的人是否还在维护，如果年代很久远一般就可以直接开始，否则应当尝试与之取得联系。如果联系不上，那么就要与该项目的相关邮件列表取得联系。关于邮件列表请继续往下阅读。
##当您确信现在没有人在维护或者是维护的人希望您能替代/帮助他，就可以开始按照常规的翻译流程进行翻译了。
# 提交的时候除了项目指定的方式外还常常可以使用两种方式，bug 和发送到邮件列表。
#* 提交 bug 的平台有很多，常见的一般是 bugzilla 和 Trac，提交的时候一般需要把组件设置为L10N(localization)或者I18N(internationalization)，如果两者都没有还应看是否有 INTL 之类的，如果没有就把组件处留空，版本一般选择开发版本，即前面提到的trunk/head/master/development。
#* 提交到邮件列表时应当优先考虑用户邮件列表。用户邮件列表一般是带 user 字样的，当然如果有专门的翻译/国际化列表发送到那里更好，一般是带 i18n/intl/l10n的，注意尽量不要直接发送到开发者列表，即带 dev/devel 的，但是这是最后的选择。
# 经过以上步骤后，一个版本的翻译周期就几本完成了。有一些项目的作者会在有字符变更的时候通知翻译者，但这样勤快的维护者并不多。在一个新版本发布的时候就要去研究下一个版本的发布时间，选择一个不早不晚的时间开始下一个周期。