Transifex與GTK文檔翻譯

參與GTK+開發的一段小經歷（2013.10）

最近忽然對GTK+產生了濃厚的興趣，打算研究一下。學習一個新東西，最好的方法就是先閱讀一下它的文檔。應該說GTK的文檔雖然比不了MSDN，但也頗為詳盡。主要的問題在于文檔都是英文的，閱讀起來比較吃力。

考慮到GTK已經有15年的歷史，所以試著在網上搜了一下參考手冊的中文版，結果找到了這個網址：http://code.google.com/p/gtk-doc-cn/

這是一個叫yetist的人發起的翻譯項目。

http://forum.linuxfans.org/viewthread.php?tid=164933

https://wiki.ubuntu.org.cn/viewtopic.php?f=163&t=232005&start=15

這兩個網頁講述了他發起這個項目的經歷。

至于GTK官方的語言翻譯地址，查了半天也沒找到，所以也就沒有辦法貢獻自己的力量了。

在學習兼翻譯的過程中，發現了一個我搞不懂的地方，于是給GTK官網上的Bugzilla發了一個bug，結果很快就收到了回復，一段有趣而愉快的經歷。看來以后可以多參加一些開源社區的活動，積攢自己的人品，^_^。

Transifex（2015.6）

上面提到的yetist同學發起的翻譯項目，使用Transifex作為翻譯協作工具。其網址為：

https://www.transifex.com/projects/p/gobject-reference-manual/

yetist同學還同時主導了一系列的GTK文檔翻譯項目。有興趣的同學，可以根據自己的情況，選擇性的進行翻譯。

2013年的時候，我曾經翻譯了一部分GObject文檔，并提交給yetist。但他近來已不活躍，未能及時處理我的提交請求。直到最近我才被接納為GObject項目的翻譯人員。于是就有了下面的對transifex的初體驗。

另外說一下，我翻譯的部分主要參考了TualatriX的成果，他的網址是：

http://imtx.me/

他也是ubuntu-tweak的作者。我經常用這個軟件清理磁盤。

GTK文檔翻譯流程

由于Google Code即將關閉，翻譯項目的網址搬遷到：

https://github.com/yetist/gtk-doc-cn

或者也可以在我的github下找到這個項目的fork：

https://github.com/antkillerfarm/gtk-doc-cn

歡迎大家向yetist或者我的github提交翻譯成果。

從項目的log可以看出，yetist同學不僅自己翻譯了很多內容，而且還編寫了整個翻譯自動處理的框架。

該框架的大概流程如下：

1.下載代碼，并使用gtk-doc工具，抽取代碼中的注釋，生成幫助文檔的po文件。

2.將po文件發布到Transifex平臺，由網上的翻譯志愿者，翻譯po文件。

3.將翻譯好的po文件，合并到代碼中，并生成最終的html格式的文檔。其中合并和生成，都可以使用框架提供的命令來完成。

前兩步yetist同學已經做好了，我們需要做的主要是第3步。

框架的基本用法見項目的說明文檔，這里僅列舉文檔中未提到的細節：

1.環境準備

以Ubuntu為例，可用以下命令安裝依賴軟件包：

sudo apt-get install python python-pip fam gtk-doc-tools gnome-doc-utils

框架需要初始化：

make init

2.Transifex客戶端

Transifex客戶端用于同步Transifex平臺的翻譯更新，其使用方法和git頗為類似。它的官方地址如下：

http://docs.transifex.com/client/

以下僅列出必要的操作，完整的操作參見官網。

1）安裝

pip install transifex-client

2）初始化

tx init

3）配置

tx set --auto-remote <url>

4）下載

tx pull -a

3.合并po文件

1）修改項目目錄下的AUTHORS文件，添加你要翻譯的po文件。

2）將翻譯后的po文件，放到po或者xmlpo文件夾中，并改為上一步時你起的名字。

3）合并。

make merge

4）生成最終文檔。

make docs

這里不知是否存在bug，有的時候這個命令需要運行兩次，第1次失敗，第2次就可以看到最終的文檔了。

GLib的Socket操作

示例如下：

https://github.com/antkillerfarm/antkillerfarm_crazy/tree/master/helloworld/glib/network

需要注意的是，此例中Server端采用的是阻塞式操作，因此會將main loop阻塞住。如果main loop需要處理其他事件的話，這里可使用GThreadedSocketService啟動單獨的線程，處理之。

Linux鏡像文件

vmlinux

這是源代碼直接生成的鏡像文件。以x86平臺為例：

arch\x86\kernel\vmlinux.lds.S–這是鏈接腳本的源代碼，經過C語言的宏預處理之后會生成vmlinux.lds，使用這個腳本，鏈接即可得到vmlinux，其過程與普通應用程序并無太大區別，也就是個elf文件罷了。

image

vmlinux使用objcopy處理之后，生成的不包含符號表的鏡像文件。這是linux默認生成的結果。

zImage

zImage = 使用gzip壓縮后的image + GZip自解壓代碼。使用make zImage或者make bzImage創建。兩者的區別是zImage只適用于大小在640KB以內的內核鏡像。

uImage

uImage = uImage header + zImage。使用uboot提供的mkimage工具創建。

以上的這些鏡像文件的關系可參見：

http://www.cnblogs.com/armlinux/archive/2011/11/06/2396786.html

http://www.linuxidc.com/Linux/2011-02/32096.htm

Flash鏡像

一般來說，一個完整的linux系統，不僅包括內核，還包括bootloader和若干分區。這些鏡像文件散布，不利于批量生產的進行。這時就需要將之打包，并生成一個可直接用于生產燒寫的Flash鏡像。

可使用mtd-utils庫中的ubinize工具生成Flash鏡像。

mtd-utils的官網是：

http://www.linux-mtd.infradead.org/

安裝方法：

sudo apt-get install mtd-utils

mtd-utils還可用于燒寫分區。例如如下命令：

mtd write xyz.uimage linux

其中xyz.uimage是鏡像文件名，linux是分區名稱。

參考：

http://blog.csdn.net/andy205214/article/details/7390287

從代碼來查看板子的MTD分區方案，主要是搜索mtd_partition類型的使用定義。比如mini2440板子的分區方案可在mini2440_default_nand_part數組中查到。

外設接口雜談

USB_IN和USB_OUT

粗看這個也覺得奇怪，USB總線是雙向傳輸的，怎么還有IN和OUT的區別。后來才知道這是相對于USB HUB而言的。靠近根節點的那邊是IN，靠近設備的那邊是OUT。這里之所以用“靠近”這個詞，是因為USB是樹狀結構的，USB HUB相當于是這個樹中，層與層之間的連接器。

USB HUB的典型實例是用的比較廣的1路轉2路或者1路轉4路的USB擴展器。

UART

UART的硬件形態分為TTL、RS232和RS485等，其中最常用的是RS232，也就是有的PC主板上提供的那種9針的接口。

從原理來講，RS485和USB類似都采用了雙絞線和差分編碼。

各種外設接口物理層對比

這里不打算羅列各種外設接口的規格參數，也不打算給出一個表格對比各個方面。我的目的是在對比各種外設接口的過程中，總結設計外設接口所需要注意的地方。

1.數據線

外設接口的目的是傳輸數據，因此數據線是必不可少的。由于一根數據線無法同時處于兩種狀態，因此，必須有兩根獨立的數據線，才能實現真正的全雙工。否則，至多是半雙工。

2.時鐘線

時鐘用于劃分數據位，起到標尺的作用，否則通信雙方是無法理解一段高電平表示的是多少個“1”。（這里假設高電平表示“1”）

時鐘有三種形式：

1.約定式。通信雙方約定一個時鐘頻率進行通信。最典型的是UART接口。這種方式的好處是無需時鐘線。但由于兩側時鐘是異步時鐘，時間長了之后就會出現同步錯誤，因此這種方式只適合慢速接口。一個改進的方法是通過在數據中加入停止位，來糾正累積的時鐘同步誤差。

2.時鐘線。這種方式通常設計為主從式，即主設備提供時鐘信號，而從設備利用該信號同步自己的時鐘。比較典型的是I2C、I2S、SPI。

3.時鐘線和數據線混合式。典型如USB所采用的差分編碼，雖然是兩根數據線D+和D-，但從信息量來說，相當于其他接口的數據線+時鐘線。也可以換句話來說，由于時鐘和數據是信息中相互獨立的分量，因此，無論采用何種編碼方式，都不能以少于2根線的方式提供完整的數據線+時鐘線的功能。

正因為如此，USB 2.0雖然有兩根數據線，但它實際上只是個半雙工接口。而USB 3.0在USB 2.0的基礎上，又添加了兩根數據線，才成為了真正的全雙工設備。

3.數據有效

分為電平式和邊沿式兩種。前者如I2C，只允許數據在時鐘信號為低電平時改變，后者如SPI，規定數據在時鐘信號的邊沿有效。

I2C

I2C的讀寫時序一般如上圖所示。從中可以看出I2C的數據由從機地址、讀寫標志位、寄存器地址和普通數據位組成。其中后面的三部分在其他的外設接口中也能見到，意義大致相同，這里就不贅述了。這里重點談談從機地址。

I2C相比于UART和SPI，其優點在于一個接口可以外接多個設備（多個從設備的情況較多）。從機地址就是用于區分這些設備的。以7位從機地址為例，高4位一般由設備廠家分配設定，低3位由用戶設定。因此一個I2C總線上可以掛接多個同類設備，只要用戶設定好它們的地址就可以了。與SPI的片選不同，I2C的用戶設定位采用連接上下拉電阻的方式設定，而不用連接到主設備上。

在Linux內核中，使用I2C_BOARD_INFO宏設置從機地址。

SMBus

SMBus(System Management Bus,系統管理總線)是1995年由Intel提出的，應用于移動PC和桌面PC系統中的低速率通訊總線。由于它大部分基于I2C總線規范，因此在Linux內核中，被歸類為I2C總線。

中文編碼格式問題

常用的中文編碼格式，主要包括大陸的GB系列和臺灣的BIG5系列。

GB系列按照發布時間的順序，又包括GB2312、GBK和GB18030三種格式。越晚的編碼格式，其包含的字符數越多，但同時又兼容之前的編碼格式。

除此之外，能表示中文的還有Unicode系列。比如，Java內部使用的UTF16BE，以及網絡上用的比較多的UTF8。

需要指出的是，由于各種編碼格式的字節數不盡相同，單獨對文章中的某些字段進行轉碼，常會由于字節對齊的問題，而產生異常的結果。最好是在一種編碼下生成整個文檔之后，統一轉換成另一種格式。

總結

以上是生活随笔為你收集整理的Transifex与GTK文档翻译, Linux镜像文件, 外设接口杂谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。