好事成双，在OSD Lyrics有了自己的图标的同时，也有了RPM包。

说来惭愧，因为一直用着Ubuntu，所以只有条件给OSD Lyrics做deb包，其他的发行版只能通过编译源代码来安装。虽然说OSD Lyrics的依赖不多，但是源码安装毕竟是很多人不喜欢干的事。

OSD Lyrics 0.2发布后，Ray Chen同学提出了很多有益的建议，同时也提出找人为OSD Lyrics打个RPM包。今天liangsuilong提交了一个Issue，说RPM包已经打好了。打包的地址在http://liangsuilong.fedorapeople.org/osd-lyrics/，我把源码以外的四个包都上传到了网站上，方便下载。

另外某日在搜索的时候，发现原来已经有人给OSD Lyrics做了Arch Linux的Tarball了，而且还发现我手滑把版本号里的年份写成了2008，那时我才用Ubuntu不久，连GTK都不会呢-_-。

突然想我是不是应该加大宣传了。软件要做好是很重要，让有需要的人知道也是很重要的。ERS在《TAOUP》里说软件要常发布，不能总是想着万事俱备。同样地，我也不应该等着都完善了才让别人用吧，软件的完善是无止境的呀。

在OSD Lyrics刚推出的时候，系统托盘的图标是sarmolapple在实现时临时找的WMP图标，我就很不显眼地挂出了征集图标的启事。在推出0.2之后，觉得一个自由软件顶着WMP这专有软件的图标实在有伤风化，忍无可忍自己凑合了一个。

现在，OSD Lyrics终于有了正式的图标了！图标的设计者是easy同学，他今天（应该说是昨天）早上把他自己设计的图标发给了我，图标如下：

挺好看的吧？比我设计的强多了。而且还有它的含义：“图标的光碟和火焰组成了OSD三个字母，画笔代表歌词的自定义，组成了R的字母”。

感谢easy同学，虽然他因为使用的是KDE而无法用这个软件，但依然热心地为它设计了图标。

虽然只是个小项目，但是OSD Lyrics依然得到了大家的帮助，这就是开发自由软件最大的动力吧。

由于有朋友要求，给OSD Lyrics添加了Exaile支持

在此不得不牢骚一下，Exaile设计的接口实在是太囧了，给出当前播放时间居然是用百分比来给出的，而且只精确到百分之一。这意味着在绝大多数歌曲中使用Exaile给出的时间换算后连1秒的精度都达不到，而OSD Lyrics需要的精度是0.1秒，不然卡拉OK效果会卡得厉害。

好在之前已经遇到了类似的问题，Amarok2和Rhythmbox给出时间的单位是秒（这里不得不说Amarok2，明明MPRIS协议规定精度是1毫秒的，结果这小子给出的毫秒时间后三位全是0-_-），于是用了系统时钟差来模拟毫秒数，但是多少是有些不准的，所以用这三个播放器可能有时会出现时间跳跃的现像，这已经是我能实现的极限了。

另外忍无可忍临时做了个图标。说实在的OSD Lyrics这么一个自由软件居然顶着专利软件WMP的图标，简直就是奇耻大辱。能力有限，图标肯定是不咋的，因此征集图标设计依然有效，有好的图标请发到我邮箱：tigersoldi[at]gmail.com

开学之后时间也少了，更新肯定不会太勤快，现在身上压着一大堆事情，完成设想中的功能不知道是要到猴年马月了。

另：salmorapple同学已经在着手开发0.3的一项重要功能了，嗯嗯

经过一个多月的开发，OSD Lyrics终于实现了多下载引擎支持，是时候发布0.2版了。

0.2版相较于0.1版有如下改动：

• 支持从千千音乐在线下载歌词
• 支持 Rhythmbox
• 支持全局快捷键
• OSD模式改进
  • 添加单行模式支持
  • 歌词过长时水平滚动
  • 鼠标移动到歌词上时歌词变为透明
  • 显示/隐藏歌词
  • bug修复
• 修复之前将LRC文件的offset处理错误的问题

由于之前歌词下载是simplyzhao做的，熟悉起来花了一些时间，走了一些弯路，现在终于把从千千下载歌词搞定了。现在多下载引擎的接口已经准备完毕，就差配置部分，等配置弄好就可以准备推出0.2了=v=。

今天到OSD Lyric在launchpad上设的翻译点看了看，发现除了自己弄的中文翻译外，多了俄文、法文和西班牙文翻译，其中俄文翻译更是完成了100％（虽然只有区区几条词条）。这让我再一次感到了launchpad协作模式的强大：你永远不知道什么时候会受到别人的帮助。

之前因为对有些软件的翻译不爽，也曾经上launchpad去给别的软件贡献过几条翻译。当时就觉得，launchpad的协同翻译是一个很好的体验（尽管网速实在是有点……）。玩过windows汉化的人应该知道，在windows下翻译软件的感觉并不好。首先，windows下的软件界面字符串有好几种保存方式：标准的Windows资源、Borland系的资源、代码内嵌（这个是最恶心的）……标准形式的还好，处理代码内嵌的字符串有时无异于hack。由此诞生了许多软件，处理不同情况下的字符串资源。然后通过人力＋词典的方式汉化后再导入回原软件。正是由于这种方式，使得无法自动导出待翻译的词条。其次，windows没有很好的界面本地化支持（.NET平台似乎改变了这一点），如果软件作者要支持语言包，需要自己来编写相关代码，这使得很多软件都没有多语言界面支持。一款软件被汉化后往往就失去了原来的语言，也无法与其他语言集成在一起。更重要的是，由于没有一个统一的表示翻译串的格式，无法像launchpad这样多人多软件协同翻译。第三，自己汉化了一款软件，要被纳入官方翻译也需要大量的沟通，甚至不被接受。因为有些软件压根就没打算推出多语言版本，而汉化一款软件往往是修改了软件本身的。

而且在Linux下，这些问题都不见了，或者说就没存在过。因为Linux下有一个很好的国际化/本地化工具：GNU Gettext。它将翻译抽象成了pot（模板）-po（翻译文件）-mo（软件使用的二进制文件）的体系。软件字符串资源的更新，可以自动更新到pot文件中，然后翻译人员可以用pot来更新他们的po文件，翻译也只需要翻译po文件就好了。如果软件升级了，用pot更新一下po，原来的翻译都还在，有改动的字符串也会标记上原来的字符串作为参考，极大地减少了重复工作量。最后从po文件生成mo文件，随软件打包发布即可。由于有了gettext的存在，Linux下的软件大多会利用它进行本地化，也就是说，从一开始就已经准备将软件给本地化了的。而翻译人员，只要有po文件就可以了，管你软件是怎么用这些字符串的呢。翻译好了，提交给开发者，开发者高兴了：嘿，又有人给我翻译了，打包，好，又多支持一种语言。而对于用户来说，更是方便了：不需要下载什么汉化版——人家软件包里把汉化日化俄化全带齐了；不需要选择语言——gettext会根据系统的语言设定自动选择对应语言的翻译包。Windows下的问题这里一个都没有。

Linux和Windows下的这些差异表面上看起来是机制的差异，其实是两者的理念的差异。在Linux世界（应该说，Unix世界），社区协作是司空见惯了的，Linux的发展更是离不开社区，因此Linux下的软件很多都有着协同开发的传统，大型项目尤其如此。吸引了全世界的人员，自然会面对本地化的问题，因此本地化一开始就是很多软件考虑的选项（当然，很久很久以前不是这样）。协同开发，自然是连翻译也算上的，在Linux下软件受到别人贡献翻译和文档是很正常的事情，任何人都可以为自己喜欢的软件作出贡献。而Windows下的大多是专有软件，因此开发者不会首先想到服务非自己母语的用户，也不会期待有人免费给自己做翻译，而且自己做国际化支持也是一件挺麻烦的事情。也就是说，其实这是社区开发vs专有开发的问题，是自由软件vs专有软件的问题。

GNU Gettext已经做得很好了，但是launchpad又更上了一步：它把翻译的工作也彻底协同化了。没有launchpad之前，可以这样来翻译一个软件：从源码包里取出pot和po文件，更新对应语言的po文件，翻译后用email等方式提交给开发者。这是一个人的翻译，可能不同的版本贡献翻译的人不同，但是在翻译好提交给开发者并被开发者之前，其他人是看不到最新版本的。而在launchpad上，翻译是在网络完成，翻译者知道最新的翻译是什么，还有哪些没翻译。这样你一条，我一条，协同工作就变得能了。开发者要出新版本了，把launchpad上的翻译导出成po文件就OK了。代码中的字符串有更新，不必等到发布源码包，翻译者也不需要用svn什么的更新pot文件，直接把最新的pot上传，开发和翻译就可以同步进行了。不只是这一点，launchpad可以记录不同翻译者对同一字符串的翻译作为比较，更酷的是，它还可以用在launchpad上别的软件的相同字符串来作为建议，这进一步促进了协同工作——你的翻译不止用在一个软件上，还帮助了其他软件的翻译，毕竟很多基本的功能字符串（文件、打开、保存……）是一样的。

launchpad的这种方式，使得一个软件可以由多个人共同翻译，一个人也可以翻译多个软件。它为软件翻译提供了一个很好的统一平台。给OSD Lyrics翻译的几位外国友人可能并不是OSD Lyrics的用户，但是这并不妨碍他们翻译OSD Lyrics。还是那句话：你永远不知道什么时候会受到别人的帮助。

之前我自己给OSD Lyrics弄了个PPA源，始终感觉不够正式。今天在PPA上注册了一个OSD Lyrics团队账号，并为它申请了一个PPA源，打算用它来作为OSD Lyrics的正式PPA源。

要使用PPA源，首先编辑apt的source.list文件：

sudo gedit /etc/apt/sources.list

 可以把gedit换成自己喜欢的编辑器。

将OSD Lyrics的PPA源粘贴到文件最后。目前OSD Lyrics支持 Ubuntu 9.04 (Jaunty) 和 8.10 (Intrepid)。

Ubuntu 9.04：

deb http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu jaunty main

Ubuntu 8.10：

deb http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu intrepid main
deb-src http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu intrepid main

然后添加密钥：

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4865CF4F

更新后就可以安装了：

sudo apt-get update
sudo apt-get install osdlyrics

 双休日弄了一下，现在 OSD Lyrics 也支持 Rhythmbox 了。

Rhythmbox 是 GNOME 的御用播放器，没理由不支持的吧？不过又是一个精度是秒的播放器，这年头给个豪秒精度的dbus实现死得去啊？（真的死得去，毕竟Rhythmbox是用signal来反馈时间的，如果0.001秒触发一次事件那就太恐怖了，但是Amarok2这种使用MPRIS的就没道理了，当然Exaile返回百分比更加离谱）

好吧，其实添加 Rhythmbox 支持的主要原因是因为我mm在用，话说因为她喜欢经典的窗口模式，所以添加窗口模式支持也是迟早的事（喂喂，这还叫OSD吗？）

由于算不上大改动就不提供下载了，用Ubuntu的可以从PPA源更新，其他的可以从SVN下载：

 不过现在应该没有什么人用这个吧:P 做得更好了再推广出去

为了给OSD Lyrics打包，学习了debian官方的维护人员教程，然后想起launchpad提供了一种叫PPA源的服务，提供软件仓库，应该也能对不同版本进行自动编译吧。

PPA的全称是Personal Package Archives（个人包档案），提供1G的空间作为个人apt软件仓库，并提供用于Ubuntu各发行版的编译功能。从编译到存储到发布提供了一条龙的在线服务，相当赞，不知道rpm系的有没有类似的工具呢？

经过几个月的紧张开发，终于达到了可以发布的程度了。所谓能发布，就是指能够满足我的基本要求，并带有基本的一个程序应有的功能。

现在的状态是：

播放器支持 Amarok 1.4/2.x、Audacious和Banshee。其实支持MPRIS协议的播放器理论上都可以很容易增加支持，因为已经把它给抽象出来了。

歌词下载使用搜狗的搜索结果，不过据说搜狗有改动，有了什么验证码，以后再看了。

之前说过希望能在毕业之前发布第一个版本，可惜未能实现，不过现在也没晚太多吧。只是后续功能遥遥无期就是了……

下载地址：code.google.com/p/osd-lyrics/downloads/list

另：希望有高手能设计个图标，感激不尽啊……