Karmic 发布后简体中文小组的调整

[tregedie]

要知道虽然只愿意使用不愿意做贡献的人确实是大多数，但满腔热血却不知道怎么出力的人其实也很多的。

[happyaron]

跟上游联系的事情，如果只是语言问题，我可以尽量出力，因为我自认为交流能力没什么问题。

但是，这些事情具体究竟是怎么运作的，需要有人打开一个“门”，简单的说，就是入门。

信息究竟怎么反馈上去的，bug谁去解决的，有哪些人在维护，具体的包什么时候被更新的，怎么把bug或者自己的patch反馈到最直接联系某个包的维护者，怎么知道某个bug属于哪个包，这些机制，没经验的人根本不懂，不理解。

编程并非参与开发的唯一途径，测试/报bug，提patch，帮助打deb包，帮助翻译，其实都是开发的一部分。因此，其实开发的大门应当对“所有人”敞开，即使很多人根本不会踏入这个门，但是我们敞开这个门，却有助于更多犹豫不决的人踏进来。——多写一些文档告诉大家怎么做，这里面是什么机制，很重要。——个人觉得，甚至比安装指南更有用。

个人觉得，开源社区还是应当放开为假定所有人都是开发者的心态，也就是说，虽然有些用户很可能只是使用，但文档完善方面，却更应当注重加强怎么加入开发怎么做贡献方面的描述。——要知道虽然只愿意使用不愿意做贡献的人确实是大多数，但满腔热血却不知道怎么出力的人其实也很多的。

我需要休息休息...
刚刚写完一堆翻译相关的文档，可以在一楼的链接里找到，而且那些链接的页面里还有很多带有详细的子页面。
接下来我会写写关于Bug反馈的东西，还有Launchpad让人头疼的组织结构...

[pedant]

有精神奖励伐

[xyf]

完善组织架构。

[FangQ]

多数反应到论坛的问题都没有人到相应的地方反应，敦促解决就更少了。在Launchpad或者上游活动的人很少，我现在也没有什么完整的想法能把这些事运作起来。要改变的事很多，大家一起努力！

我的意思并不是说这些事情必须要由现有的成员来完成，而是说，可以考虑添加“沟通”和"代用户提交正规的反馈意见"到小组的工作目的中，而有时间和能力来做这件事的朋友(可能主要是一些中文开发者)来参与这项工作。

[FangQ]

跟上游联系的事情，如果只是语言问题，我可以尽量出力，因为我自认为交流能力没什么问题。

但是，这些事情具体究竟是怎么运作的，需要有人打开一个“门”，简单的说，就是入门。

信息究竟怎么反馈上去的，bug谁去解决的，有哪些人在维护，具体的包什么时候被更新的，怎么把bug或者自己的patch反馈到最直接联系某个包的维护者，怎么知道某个bug属于哪个包，这些机制，没经验的人根本不懂，不理解。

编程并非参与开发的唯一途径，测试/报bug，提patch，帮助打deb包，帮助翻译，其实都是开发的一部分。因此，其实开发的大门应当对“所有人”敞开，即使很多人根本不会踏入这个门，但是我们敞开这个门，却有助于更多犹豫不决的人踏进来。——多写一些文档告诉大家怎么做，这里面是什么机制，很重要。——个人觉得，甚至比安装指南更有用。

个人觉得，开源社区还是应当放开为假定所有人都是开发者的心态，也就是说，虽然有些用户很可能只是使用，但文档完善方面，却更应当注重加强怎么加入开发怎么做贡献方面的描述。——要知道虽然只愿意使用不愿意做贡献的人确实是大多数，但满腔热血却不知道怎么出力的人其实也很多的。

用户反馈的问题有很大一部分都是以不严谨的语言来描述的，往往只能看到事情的表像，但无法找到产生问题的根本。这样的报告无法作为正规的反馈提交给ubuntu开发者。所以我认为帮助反馈的朋友可以做下面的几件事情：
1. 从用户的问题中找到产生问题的本质原因(哪个包，哪个文件)
2. 得到可以严格重现问题的命令／操作序列
3. (可选项)找到解决办法(patch etc)
4. 为launchpad对应包提交bug报告，上传问题描述、重现手段、效果差别和patch
5. 及时与admin沟通，敦促问题解决，并即使测试更新。

我想，如果能够做到1,2,4就已经很好了。

[gisworld]

不错，FangQ提的几个BUG一针见血，这应该作为中文小组一个重要的工作（不过，已经脱离translation team的范畴了）

[happyaron]

用户反馈的问题有很大一部分都是以不严谨的语言来描述的，往往只能看到事情的表像，但无法找到产生问题的根本。这样的报告无法作为正规的反馈提交给ubuntu开发者。所以我认为帮助反馈的朋友可以做下面的几件事情：
1. 从用户的问题中找到产生问题的本质原因(哪个包，哪个文件)
2. 得到可以严格重现问题的命令／操作序列
3. (可选项)找到解决办法(patch etc)
4. 为launchpad对应包提交bug报告，上传问题描述、重现手段、效果差别和patch
5. 及时与admin沟通，敦促问题解决，并即使测试更新。

我想，如果能够做到1,2,4就已经很好了。

类似的东西我也在考虑，可还没着手做。因为要准备的文档不少，工作量相应地也不小。我会在10.04开发周期的前期尽量把文档准备完。LP的东西有条理但是比较复杂，解释的时候不好表达，而且要解释的可能会比较多啊。

bug 406132应该已经Fix released。中文打印粗体的问题似乎bug号不对...
bug 424677看里面的描述没怎么和您在帖子里的描述对上号...

[FangQ]

bug 406132应该已经Fix released。中文打印粗体的问题似乎bug号不对...
bug 424677看里面的描述没怎么和您在帖子里的描述对上号...

中文粗体打印应该是 #344814
https://bugs.launchpad.net/ubuntu/+sour ... bug/344814

#424677的PUA问题看我在其中的回复。

[bennyao]

向你们致敬！你们幸苦了

[careone]

等了好久终于等到今天......

[xxzc]

You have been added to ubuntu-china-trans-contributors‏

YEAH！

[xinyujun]

很不错啊 !支持啊!

[547320073]

能不能把新的翻译以补丁的形式发布出来？话说很多软件的help文件都是纯英文的······

[poet]

不错，FangQ提的几个BUG一针见血，这应该作为中文小组一个重要的工作（不过，已经脱离translation team的范畴了）

中文小组不等于翻译小组。我一直认为解决中文支持方面的问题，其优先级要远高于中文翻译。

如果一个软件根本不能正常显示／输入中文，例如某些软件中文字符直接就显示成乱码，例如在某些关键处输入中文会造成解析错误，例如某些软件中使用Ctrl+空格根本无法激活输入法，那么谁都无法使用它。

如果一个软件可以正常处理所有中文相关的内容仅仅是界面没有翻译成英文，那么至少多数人可以使用它，少数人可能希望对其中的英文界面进行翻译，但这个工作可以逐步的进行。

毕竟来说：能正常处理中文是“温饱”问题，界面全中文是“小康”问题。。。
fangq提出的那些问题在我看来就是“温饱“问题，应当是重点解决的。翻译的问题也重要，不过至少应当对中文支持方面的那些真正实质性问题的解决给予一个门路。