# 50.1\. 寄語翻譯家 PostgreSQL 程序(服務器和客戶端)可以用你喜愛的語言提示消息，只要那些消息被翻譯過。 創建和維護翻譯過的消息集需要那些熟悉自己的語言并且希望為 PostgreSQL 做一些事情的人。 實際上要干這件事你完全不必是個程序員。本章講的就是如何幫助 PostgreSQL 做這件事。 ## 50.1.1\. 要求 本章是有關軟件工具的，不會評判你的語言能力。理論上，你只需要一個文本編輯器。 但這種情況只存在于你不想看看自己翻譯的消息的情況下，這種情況很難發生吧。 在你配置你的源程序的時候，記住要使用`--enable-nls`選項。 這樣也會檢查 libintl 庫和 `msgfmt` 程序，它們是所有最終用戶都需要的東西。 要試驗你的工作，遵照安裝指導中相應的部分就可以了。 如果你想開始一個新的翻譯工作或者想做消息表合并工作(下面描述)，那么你就還分別需要有 GNU 兼容的 `xgettext` 和 `msgmerge` 。 稍后將試著整理它，這樣，如果你使用的是一個打包的源碼發布，那么你就不再需 要 `xgettext`(從 Git 里下源碼還是需要的)。現在推薦 GNU Gettext 0.10.36 或者更高版本。 你的本地 gettext 實現應該和它自身的文檔在一起發布。 其中有一些可能和下面的內容重復，但如果要知道額外的細節，你應該看看它們。 ## 50.1.2\. 概念 消息原文(英語)和它們的(可能)翻譯過的等價物都放在_消息表_ 里，每個程序一個(不過相關的程序可以共享一個消息表)以及每種目標語言一個。 消息表有兩種文件格式：第一種是"PO"(可移植對象)文件，它是純文本文件， 帶一些翻譯者編輯的特殊語法。第二種是"MO"(機器對象)文件， 它是從相應的 PO 文件生成的二進制文件，在國際化了的程序運行的時候使用。 翻譯者并不處理 MO 文件；實際上幾乎沒人處理它。 消息表的文件擴展名分別是 `.po` 或 `.mo` 就一點也不奇怪了。主文件名要么是它對應的程序名，要么是該文件適用的語言， 視情況而定。這種做法有點讓人混淆。比如 `psql.po` (psql 的 PO 文件)或者 `fr.mo` (法語的 MO 文件)。 PO 文件的文件格式如下所示： ``` # comment msgid "original string" msgstr "translated string" msgid "more original" msgstr "another translated" "string can be broken up like this" ... ``` msgid 是從程序源代碼中抽取的(其實不必是從源碼，但這是最常用的方法)。 msgstr 行初始為空，由翻譯者填充有用的字符串。 該字符串可以包含 C 風格的逃逸字符并且可以像演示的那樣跨行繼續。 下一行必須從該行的開頭開始。 #字符引入一個注釋。如果 # 后面緊跟著空白，那么這是翻譯者維護的注釋。 文件里也可能有自動注釋，它們是在 # 后面緊跟著非空白字符。 這些是由各種在 PO 文件上操作的工具生成的，主要目的是幫助翻譯者。 ``` #. automatic comment #: filename.c:1023 #, flags, flags ``` #.風格的注釋是從使用消息的源文件中抽取的。 程序員可能已經插入了一些消息給翻譯者，比如那些預期的格式等。 #: 注釋表示該消息在源程序中使用的準確位置。 翻譯者不需要查看程序源文件，不過如果他覺得翻譯得不對勁，那么他也可以查看。 #, 注釋包含從某種程度上描述消息的標志。 目前有兩個標志：如果該消息因為程序源文件的修改變得過時了，那么設置 `fuzzy`(模糊)標志。 翻譯者然后就可以核實這些，然后可能刪除這個fuzzy標志。請注意fuzzy消息是最終用戶不可見的。 另外一個標志 `c-format`, 表示該消息是一個 `printf` 風格的格式模版。 這就意味著翻譯也應該是一個格式化字符串，帶有相同數目和相同類型的占位符。 有用于核實這些的工具，它們生成 c 風格標志的鍵。 ## 50.1.3\. 創建和維護消息表 好，那怎么創建一"空白"的消息表呢? 首先，進入包含你想翻譯消息的程序所在的目錄。 如果那里有一個文件叫 `nls.mk` ，那么這個程序就已經準備好翻譯了。 如果目錄里已經有一些 `.po` 文件了，那么就是有人已經做了一些翻譯工作了。 這些文件是用 `_language_`.po 命名的， 這里的 `_language_` 是[ISO 639-1 規定的兩字母語言代碼(小寫)](http://www.loc.gov/standards/iso639-2/php/English_list.php) ，比如 `fr.po` 指的是法語。 如果每種語言需要多過一種的翻譯，那么這些文件也可以叫做 `_language_`_`_region_`.po 這里的`_region_` 是 [ISO 3166-1 規定的兩字母國家代碼(大寫)](http://www.iso.org/iso/country_names_and_code_elements)， 比如 `pt_BR.po` 指的是巴西葡萄牙語。如果你找到了你想要的語言文件，那么你就可以在那個文件上干活。 如果你需要開始一個新的翻譯工作，那么首先運行下面的命令 ``` gmake init-po ``` 這樣將創建一個文件`_progname_`.pot。 (用`.pot`和"生產中"使用的 PO 文件區分開。 `T`代表"template"。) 把這個文件拷貝成`_language_`.po 然后編輯它。要讓程序知道有新語言可以用，還要編輯文件 `nls.mk` 以增加該語言(或者語言和國家)代碼到類似下面這樣的行： ``` AVAIL_LANGUAGES := de fr ``` （當然可能還有其它國家。） 隨著下層的程序或者庫的改變，程序員可能修改或者增加消息。 這個時候，你不必從頭再來。只需要運行下面的命令 ``` gmake update-po ``` 它將創建一個新的空消息表文件(你開始時用的 pot 文件)并且會把它和現有的 PO 文件合并起來。 如果合并算法不能確定某條具體的消息是否合并正確，那么它就會像上面解釋那樣把它定義為"fuzzy"(模糊)。 新的PO文件會保存為帶 `.po.new` 擴展的文件。 ## 50.1.4\. 編輯 PO 文件 PO 文件可以用普通的文本編輯器編輯。 翻譯者應該只修改那些在 msgstr 指示符后面的雙引號中間的內容，也可以增加評注和修改模糊(fuzzy)標志。 Emacs 有一個用于 PO 的模式，我覺得相當好用。 不需要把 PO 文件完全填滿。如果有些字符串沒有翻譯(或者是一個空白的翻譯)，那么軟件會自動使用原始的字符串。 也就是說提交一個未完成的翻譯包括在源碼樹中并不是一個問題；那樣可以留下讓其他人繼續你的工作的空間。 不過，鼓勵你在完成一次合并之后首先消除模糊的條目。 要知道模糊的條目是不會被安裝的；它們只起到表示可能是正確翻譯的引用的作用。 下面是一些編輯翻譯消息的時候要記住的事情： * 確保如果原始消息是以換行結尾的話，翻譯后的消息也如此。類似的情況適用于 tab 等。 * 如果最初的字符串是 `printf` 格式的字符串，那么翻譯串也必須如此。 翻譯串還要有同樣的格式聲明詞，并且順序相同。 有時候語言的自然規則會讓這么做幾乎不可能或者及其難看。這時候你可以用下面的格式： ``` msgstr "Die Datei %2$s hat %1$u Zeichen." ``` 這樣，第一個占位符實際上使用列表里的第二個參數。 `_digits_`$ 應該跟在 % 后面并且在其它格式操作符之前。 這個特性實際上存在于 `printf` 函數族中。 你可能從來沒有聽說過它，因為除了消息國際化以外它沒有什么用處。 * 如果原始的字符串包含語言錯誤，那么請報告它(或者在程序源文件中直接修補它)，然后按照正常翻譯。 正確的字符串可能在程序源文件更新的時候被合并進來。 如果最初的字符串與事實不符，那么請報告它(或者自己修補它)但是不要翻譯它。 相反，你可以在 PO 文件中用注解給該字符串做個標記。 * 維護風格和原始字符串的語氣。特別是那些不成句子的消息(`cannot open file %s`) 可能不應該以大寫字符開頭(如果你的語言區分大小寫的話)或者用句號結束(如果你的語言里有符號標志)。 閱讀節[Section 49.3](#calibre_link-1472)可能會有所幫助。 * 如果你不知道一條消息是什么意思，或者它很含糊，那么在開發者郵遞列表上詢問。 因為可能說英語的最終用戶也可能不明白它或者覺得它不好理解，所以最好改善這條消息。