由于之前歌词下载是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

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

今天终于搞定了osd-lyrics对复合窗口管理器的支持，终于可以使用其RGBA半透明功能来平滑歌词的边缘了

可惜在不支持复合的窗口管理器（metacity等）上还是很难看的锯齿边缘。这是外部限制，没办法了

上图一张，哈哈

之前我说我和两个同学在做一个Linux下做一个OSD歌词显示的软件，明天终于有了第一个能用的版本。所谓能用，就是说可以与播放器交互，根据播放的时间与歌曲来显示歌词极其进度。

当然，现在还非常简陋，画出来的歌词还不好看，无法设置，歌词也只能从指定目录以指定格式读取，播放器只支持Banshee，无法自动下载歌词，还有N多的Bug……

Anyway，至少使用了自己的作品，心里还是很有成就感的

废话少说，我说过有可用代码后会放出项目地址的：

http://code.google.com/p/osd-lyrics/

附上一张截图：

现在的一些限制：

• 仅支持Banshee
• 歌词必须手动放在~/.lyrics目录里，以“歌手名-歌名.lrc”的形式命名，例如“王菲-红豆.lrc”
• 歌词必须是UTF8编码

下一步的计划：

• 美化文字渲染
• 增加支持的播放器（首先考虑AmarOK1.4，因为simplyzhao在用，哈哈）
• 自动下载歌词
• 消除太部分的Bug

之后的计划：

• 增加一个系统托盘图标
• 完善歌词管理功能

之后的之后……

争取在毕业前能做出0.1版，嗯嗯