自由軟體中文化工作指南

出自Ubuntu 正體中文 Wiki

跳轉到: 導航, 搜尋


前言

本文目的乃是希望為目前正體中文翻譯環境設立一個共同的翻譯準則。如有任何建議,您可以在 chinese-l10n 網上論壇提出,也竭誠歡迎您加入我們的行列。

對於翻譯者,建議您列印本文件,以便在翻譯時隨時查閱。

歡迎對本文內容進行討論,相關的歷史背景和聯繫方式請參閱文末。

工作流程

不同的翻譯項目有不同的工作流程,大致分為準備、協調、翻譯和提交。

準備

  • 我們的原則是品質優先,強烈不贊成翻譯自己不熟悉的軟體或文件
  • 詳細閱讀本文件和全部與工作相關和要翻譯內容相關的文件
  • 最好準備一本英語詞典或者使用線上詞典以方便查閱生字,例如:Yahoo!奇摩字典;至於術語、縮寫等請先查閱 Wikipedia 文章、以 Google 搜尋或是參考 Answers.com 上的內容等
  • 使用線上翻譯工具(如 Launchpad)者,在瞭解注意事項與翻譯相關格式後便可以開始進行翻譯
  • 不使用線上翻譯平台的,請依照各專案所指定的方法取出源始碼、取得 PO 或 POT 檔,然後安裝指定的工具並開始翻譯(如要翻譯 PO 檔,強烈建議您安裝 gettext 工具組)

協調

協調工作的主要目的是防止多個人在互不知情的情況下同時翻譯相同的內容,一方面導致了重複勞動,另一方面也造成了合併的困難。
通常情況下的協調工作,是透過向專案翻譯小組的郵遞論壇寄送電子郵件來說明你想要負責的工作項目。若要翻譯的軟體或文件不存在,則你將自動成為其負責人並可以開始進行翻譯。若已經有人在進行翻譯,則此後需要與之聯繫以商定分工,請在寄送認領郵件到郵遞論壇時抄送給原負責人一份,一周內無回覆則視為同意你的請求。開始翻譯前若需要相關的帳號應提出申請。
GNOME 由於使用了 Damned-Lies 網站,請直接使用網站功能即可;至於線上翻譯,如 LaunchpadTryneeds 等,暫時還沒有進行協調工作的有效方式。

翻譯

PO 檔翻譯流程

(1) 關於 GNU Gettext

GNU Gettext 是GNU 本地化和國際化函數庫,即 GNU Localization (l10n) & Internationalization (i18n) Library,是自由軟體國際化支援的常用工具。

(2) 開始翻譯

翻譯是我們中文化工作中的重點,在開始翻譯前請詳細閱讀本文以下章節中的各項要求,保證品質。 PO 文件的翻譯過程中不要對 msgid 行做任何修改,即使其中有明顯錯誤,否則合併翻譯到主程式的程式將會遇到問題。您在英文字元串上做的更改將會丟失,您的翻譯也不會被合併入內。在遇到來源文件有問題時最好的辦法是向軟體開發者提交Bug 報告。 本文中關於 PO 文件的各項命令都假定閱讀者已經安裝了 GNU/Linux 基本系統、gettext 工具集和 intltool 工具集,或者在其他平台上安裝了相應的程式。

(3) 檢查翻譯格式

PO 文件翻譯後請使用以下命令進行格式檢查:

msgfmt -- statistics - cv zh_TW . po

執行以上命令後會在當前目錄下產生一個名為 messages.mo 的檔案,該檔案便是編譯後供機讀之用。

(4) 複審翻譯

使用 PO 檔的,直接複審 PO 檔,並建議將 PO 檔編譯成 MO 檔,接著複製到相應程式的目錄下來進行實測,以確保翻譯無誤。
至於文件,請先構建文件並接著精讀結果文件。
如果發現問題,請回到「開始翻譯」步驟,並修正問題。

(5) 格式化翻譯

因為不同的翻譯工具可能使用了不同的格式,比如標準 gettext 格式、poedit 格式等。強烈建議所有翻譯者使用標準 gettext 格式,可以使用標準的 POT 檔與 PO 檔進行合併來達到此目的:

msgmerge -- no - wrap -U zh_TW . po example . pot

線上翻譯注意事項

(1) Launchpad

  • Launchpad 平台目前提供「線上翻譯」與「PO 檔翻譯」兩種方式進行翻譯。線上翻譯時請注意以下幾點並遵照本文的翻譯要求;PO 檔翻譯請參照 PO 檔翻譯流程。
  • 由於 Launchpad 沒有校閱的機制,只要是翻譯團隊的成員皆擁有所有翻譯的決定權,所以在翻譯時只要遇到不清楚原意的條目,請將 "Someone should review this translation" 打勾後再進行 "Save & Continue" 的提交動作。與其翻譯錯誤讓瞭解中文與英文的人都看不懂,更希望能保留英文起碼讓懂英文的人瞭解。
  • 除了沒有校閱機制之外,Launchpad 也不會上傳該平台上的翻譯成果給非使用 Launchpad 平台的上游翻譯專案,這是目前最為人詬病的缺點。因此,使用 Launchpad 進行翻譯時,請優先翻譯以 Launchpad 平台作為其翻譯來源的軟體套件專案。至於那些來自非 Launchpad 平台的上游翻譯,請想要翻譯的人務必與上游保持同步狀態。
  • Ubuntu 專案使用 Launchpad 平台作為其翻譯來源,Ubuntu 團隊自己開發的與經過他們修改的軟體套件,都可以直接進行翻譯而無須保持與上游同步。這些套件的清單可以由此頁面中的 "Ubuntu Specific GUI Packages" 一節查閱。

(2) Tryneeds

  • Tryneeds 使用管理員機制以控管翻譯品質,所有翻譯都需要經過管理員的審核才會提交到上游。因此使用 Tryneeds 進行翻譯時,只要遵照本文的翻譯要求即可。

(3) Transifex

  • Transifex 目前提供兩種方式進行翻譯:「線上翻譯」與「PO 檔提交」。線上即時翻譯功能還在開發中,時常在送出翻譯後卻無法通過系統驗證,目前尚不建議使用。PO 檔提交請遵照 PO 檔翻譯流程。

提交

非翻譯平台

不同項目提交翻譯的方式不完全相同,多數情況下可以通過翻譯小組的郵遞論壇進行提交,如果您有相關項目的翻譯管理帳號則請直接提交。如果沒有負責的小組也沒有相關的帳號,請把您的翻譯發送到對應項目的翻譯者郵遞論壇(一般名稱類似 xxx-translators、i18n、intl、l10n;若沒有翻譯者郵遞論壇則發送到文件郵遞論壇,一般名稱類似為 xxx-doc;若還是沒有則發送到開發者郵遞論壇,一般名稱為 xxx-dev、devel、developer),或者通過填寫一個 Bug 的方式進行提交。
注意:在請別人代為提交到 TP 項目時 Last-translator 不會是您,因為 TP 要求這項需要是提交者的名字和郵件地址,您的訊息將會出現在檔頭註解的版權列中。
提交後請根據情況再發送一封郵件來取消原來協調翻譯時的佔用聲明。

翻譯平台

各個翻譯平台的提交方式都不同,請遵照各平台規定。

基本要求

  1. 準確表述原文的意思
  2. 中文應該意思清晰且符合中文表達習慣
  3. 原文如果表達不清晰,中文應該意譯,並且應根據上下文和註解進行推斷並填補相應的訊息。例如 "print error" 不該直譯為「列印錯誤」,而是「列印發生錯誤」以免造成混淆
  4. 情況 3 不能太多
  5. 對同樣短語的翻譯,前後必須一致
  6. 使用「您」而不是「你」
  7. 不要使用機器翻譯的成果來提交,也就是說您可以使用 Google Translate 來幫助您理解內容,但是不能不經考慮就把其自動翻譯的結果放在翻譯裡

格式要求

文件編碼格式

目前的翻譯文件一般使用 UTF-8 編碼。所以請使用支援 UTF-8 編碼的編輯工具或者文字編輯器進行翻譯,同時需要注意文件頭的 "charset" 項設定正確。如果在編碼格式上遇到問題,請向翻譯組相關郵遞論壇發送郵件以尋求幫助。 可以使用 iconv 或者 msgconv 命令進行轉換,以下例子為轉換 gb2312 --> utf-8:

iconv -f 來源文件編碼 -t 目標文件編碼 來源文件>目標文件
iconv -f gb2312 -t utf-8 inputfile > outputfile

或者:

msgconv -t 目標文件編碼 來源文件 -o 目標文件
msgconv -t utf-8 inputfile -o outputfile

關於檔頭

下面是一個使用 msginit 工具由 POT 文件產生的 PO 文件的初始文件頭,使用了 msginit 的 --no-translator 選項:

# Chinese translations for PACKAGE package
# PACKAGE軟體包的正體中文翻譯.
# Copyright (C) 2009 Free Software Foundation, Inc.
# This file is distributed under the same license as the PACKAGE package.
# Automatically generated, 2009.
#
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: bug-coreutils@gnu.org\n"
"POT-Creation-Date: 2009-08-20 17:27+0200\n"
"PO-Revision-Date: 2009-08-20 17:27+0200\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"

編輯後的文件頭應為這樣,綠色為實際文件中需要修改的,紅色為註解:

# Chinese translations for coreutils package <--將PACKAGE改為要翻譯的軟體名,本例中為coreutils
# coreutils軟體包的正體中文翻譯. <--此處PACKAGE替換方法同上
# Copyright (C) 1998, 2002, 2004, 2005, 2009 Free Software Foundation, Inc.

# <--填入翻譯年份,若年份有多個,應當以逗號分割多個數字而不是使用某年至某年的方式
# This file is distributed under the same license as the coreutils package.

# <--此處PACKAGE替換方法同上

# Yip Chi Lap <clyip@cs.hku.hk>, 1998.
# Abel Cheung <maddog@linux.org.hk>, 2002.
# Anthony Fok <anthony@thizlinux.com>, 2002.
# Funda Wang <fundawang@linux.net.cn>, 2004, 2005. 
# Aron Xu <happyaron.xu@gmail.com>, 2009.
# <--此處填入您自己的訊息,格式參見上面,有的PO編輯器會自動更新此項,有多個年份的以逗號分隔列出

#

#, fuzzy <--使用msginit產生的PO文件中沒有這行,如果直接用POT文件進行翻譯請務必在繼續前刪除此行
msgid ""
msgstr ""
"Project-Id-Version: coreutils 7.5 \n" <--此處PACKAGE替換方法同上,VERSION應為所對應的軟體版本
"Report-Msgid-Bugs-To: bug-coreutils@gnu.org\n" <--此行一般不需修改,即使有的文件在產生後此項為空
"POT-Creation-Date: 2009-08-20 17:27+0200\n" <--此行一般不需修改,合併新的POT文件時會自動更新
"PO-Revision-Date: 2009-08-24 22:25+0800 \n"

<--填入翻譯完成的時間,po編輯器一般能自動更新此項, +0800代表東8時區

"Last-Translator: Aron Xu <happyaron.xu@gmail.com> \n" <-- 改成你的名字和電子郵件地址
"Language-Team: Chinese (traditional) < i18n-zh@googlegroups.com > \n"

<--以上這行改成你所在小組的地址 ,沒有小組就填寫可以聯繫到你的電子郵件地址
"MIME-Version: 1.0\n" <-- 不要進行更改
"Content-Type: text/plain; charset=UTF-8\n"

<--應確保上行的編碼和文件編碼均為UTF-8,若不是則需要將文件編碼轉換為UTF-8後再將此處更改為UTF-8
"Content-Transfer-Encoding: 8bit\n" <-- 不要進行更改
"Plural-Forms: nplurals=1; plural=0; \n" <--正體中文的翻譯這樣填就可以,有的文件可能無此行

修改完文件頭以後接著就是實質性的翻譯了,PO 文件的格式是一句 msgid 跟著一句 msgstr,以“#”開頭的行是註解。您需要做的是把 msgid 中的英文翻譯成中文寫到 msgstr 中。例如:

#: app/floating_sel.c:198
msgid ""
"Cannot create a new layer from the floating\n"
"selection because it belongs to a\n"
"layer mask or channel."
msgstr ""
"無法從浮動選區創建新\n"
"圖層,因為它屬於一個\n"
"圖層蒙板或通道。"

#: app/gimphelp.c:194
msgid "Could not find GIMP Help Browser"
msgstr "找不到GIMP幫助瀏覽器"

關於複數形式

由於某些語言的單複數變化極為複雜,為了應對這種局面,符合國際化標準,gettext 通過讀取 PO 文件頭部如下一行中的訊息來正確顯示不同單複數的譯文:

"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n" 

對於我們來說,正確的設定通常為:

Plural-Forms: nplurals=1; plural=0; 

含義是譯文的所有單複數形式只有一種,所有形式使用一種翻譯。

nplurals 表示譯文單複數變化形式的總數量,它是一個正整數。中文裡一般沒有單複數區分,也就是說沒有複數變化, 所以一般情況下nplurals=1;

plural 表示原文中表示“n個”的概念的時候應用複數形式,這裡是一個非負整數,可以是一個C 語言表達式的值,該值必須小於nplurals 且非負。對於中文而言,可以取到的值只有0,於是plural=0。

也有一些情況例如“他/她”以及“他們/她們”的時候中文也存在單複數形式的不同,通常推薦用語言層面上的方法處理,當然也不是沒有對應的Plural-Forms設定,這個時候一般為:

Plural-Forms: nplurals=2; plural=(n > 1); 

含義是單複數一共有兩種(一種單數和一種複數),在所指對像數量超過一個的時候使用複數。

又如一些語言中只有在所指對像數量為一的時候使用複數(英語的預設設定):

Plural-Forms: nplurals=2; plural=(n != 1); 

含義是單複數一共有兩種(一種單數一種複數),僅在數量為一個的時候使用單數(即數量不為一的時候使用複數)。

再舉一個正文中的例子,若原文如下:

#: src/msgcmp.c:338 src/po-lex.c:701
#, c-format
msgid "found %d fatal error"
msgid_plural "found %d fatal errors"
msgstr[0] ""
msgstr[1] ""

在文件頭處設定中文最常用的複數形式後,上段內容的譯文應以下面格式寫出:

#: src/msgcmp.c:338 src/po-lex.c:701
#, c-format
msgid "found %d fatal error"
msgid_plural "found %d fatal errors"
msgstr[0] "找到%d個嚴重錯誤"

也就是說多餘的 msgstr 要刪除。

特殊字元

(1) 標準 gettext 格式 PO 文件中的轉義字元和取消轉義 標準 gettext 格式中的轉義字元同 C 語言中的基本相同,常用的有以下幾個:

  • \n 換行
  • \t 水平製表符
  • \v 豎直製表符

您不需要將同樣數量的格式標記放在翻譯中,但是如果它們之一有在原文開始或者結束位置的時候,您必須在翻譯中使之包含在對應的開始或者結束之處。

如果要顯示非轉義字元,則需要使用\ 來表明取消轉義,如" (半形雙引號)在PO 文件中表示字元串的開始或者結束,如果要在內容中使用該符號,則需輸入\ ",還可以參考以下例子:

\"\\t\" 

在執行時顯示的結果是"t"

(2)XML中的角括號和“&”號

有一些模組中 XML 被頻繁地使用,GConf 是最明顯的。 XML 將“<”“>”和“&”視為保留字元,您不能將其直接添加到翻譯中。必須將其實體以下面的形式表示: &lt 代表<; &gt 代表>; &amp 代表&。

(3) TRUE 和FALSE “TRUE”和“FALSE”多出現於 gtk+ 和 Gconf,以及很多 Glade 所產生的文件中(這些文件以 .glade 為文件名結尾),不要翻譯它們。如果程式找不到它們,將會出現問題。

標點的使用

一般的原則是:除了小括號、省略號和破折號保留不變以外,都應該使用中文(全形)標點符號。英文標點符號後方常常跟隨有一個半形空格,請在翻譯成中文標點符號時將其去除。

  1. 英文中的, 在中文中可能是,或者、
  2. 英文中的. 在中文中應該是,或者。 ,視上下文而定,多數是。
  3. 英文中的 \"%s\" 在 GUI 程序中應該翻譯為 「%s」, 而不是 \"%s\" 或者 \「%s\」,而且後者是不符合換碼序列要求的。即在 GUI 程序中`something' 和 'something' 以及 \"something\" 都應該翻譯為 「某事」
  4. 英文中的\"%s\" 在CLI 程式中應保持為\"%s\",因為全形引號在文字界面下顯示不夠美觀,所以使用半形雙引號,即在CLI 程式中`something' 和' something' 以及\"something\"都應譯作\"某事\"
  5. 英文中的: 應該翻譯為:(全形)而不是:(半形), 而作為分隔符時(例如時間),: 保留為英文(半形)的, 因為這個時候不是標點符號
  6. 英文中的( ) 應該保持不變。由於全形小括號( )很難看,也佔地方,所以一律使用半形小括號( )
  7. 英文中的... 應該保持不變。由於翻譯的時候常常難以分清哪些條目是選單項,哪些條目是一般語句,而後者才能使用中文的省略號……,所以現在統一翻譯為...
  8. 英文中的-- 應該保持不變。由於全形破折號—— 相容性不好,有時顯示為兩個方格,所以不再使用。
  9. 遇到%q 標記的時候,代表此標記顯示的是一段引用內容,程式執行時將自動在其兩端加上雙引號,故不需另加引號。

關於空格

為了美觀,通常建議在中文與英文、中文與阿拉伯數字、英文與阿拉伯數字之間加入一個半形空格。例如:

msgid "Installing driver for %1"
msgstr "正在安裝%1的驅動程式"

msgid ""
"Parameter start_num specifies the character at which to start the search. "
"The first character is character number 1. If start_num is omitted, it is "
"assumed to be 1."
msgstr ""
"參數start_num指定開始搜索的字元位置。第一個字元序號為1。如果省略"
"start_num,預設它為1。" 

對於CLI 程式,因為文字界面字體顯示的原因,一般推薦漢字後接英文時不留空格,英文後接漢字時留一個空格,在顯示的時候不會因為英文前後都有空格而造成英文前面的空餘空間遠大於後面造成的不美觀,例如:

msgid "Set LC_ALL='C' to work around the problem."
msgstr "請設定LC_ALL='C'以避免出現問題。" 

對於小括號和全形雙引號,其兩側不加空格:

msgid "Original idea and author (KDE1)"
msgstr "原始創意和作者(KDE1)"

msgid ""
"The APM Management subsystem seems to be disabled.\n"
"Try executing \"apm -e 1\" (FreeBSD) and see if \n"
"that helps.\n"
msgstr ""
"APM管理子系統似乎被禁用了。\n"
"試試執行“apm -e 1”(FreeBSD)並看看\n"
"是否有用。\n"

包含XML/HTML 標籤的條目,如要在標籤中的內容兩側添加空格,請把空格置於標籤外側,否則空格可能顯示不出來。

這是&lt;b&gt;HTML&lt;/b&gt;的語法手冊

選單項中捷徑字元

捷徑字元一律使用大寫字母,用小括號括起來放到選單文字的後面(如果有標點符號則放在標點符號的前面)。在KDE 中,選單捷徑字元的前綴是“&”; 在GNOME 中,選單捷徑字元的前綴是“_”。但是如果翻譯保留了原文的英文單詞或阿拉伯數字,且該單詞或數字正好是快速鍵所在的單詞或數字時,應保留原文的快速鍵方式(如下面的第二、四個例子)。這裡舉幾個例子:

KDE選單:

msgid "C&lear"
msgstr "清除(&L)"

msgid "&Glimmer Editor"
msgstr "Glimmer編輯器(&G)" <--錯誤!
msgstr "&Glimmer編輯器" 

GNOME 選單:

msgid "_Setup..."
msgstr "設定(_S)..."

msgid "Get _CDDB Now"
msgstr "現在讀取CDDB(_C)" <--錯誤!
msgstr "現在讀取_CDDB"

注意:以下情況的翻譯有點特別。由於“複製”和“剪切”均為“編輯”選單的條目,只有這樣翻譯才能保證顯示正確!

msgid "/_Edit"
msgstr "/編輯(_E)"

msgid "/Edit/C_opy"
msgstr "/編輯(E)/複製(_O)"

msgid "/Edit/C_ut"
msgstr "/編輯(E)/剪下(_U)"

關於程式語言格式和msgctxt

翻譯過程中常會遇到“c-format”一類的標記,-format 標記代表該段字元串需要按照指定的程式語言格式輸出,最常見的就是按照 C 語言格式輸出。其他比較常見的還有 python-format、scheme-format、perl-format、php-format、qt- format 和 kde-format 等。 msgctxt 標記(可以理解為 message context)是給出字元串所處的不同環境,通常情況下同一個 msgid 只能在一個 PO 文件中出現一次,但是在有不同的 msgctxt 標記存在時,一個文件中可以出現多個相同的 msgid,因為它們各自的上下文不同,所以可能有不同的譯文。

翻譯中參數的位置

有時候原來的參數順序不符合中文的語法,一方面, 翻譯可以通過調整副詞、語序等手法來符合中文習慣,另外一方面,在必要的情況下,需要改變參數的位置,例如在KDE 中:

msgid "%1 articles match rule %2"
msgstr "符合規則%2的文章有%1個" 

如果是在GNOME 中則應該這樣寫:

msgid "%d articles match rule %d"
msgstr "符合規則%2$d的文章有%1$d個" 

即用1$、2$、3$ 等符號標明參數在原文裡出現的位置。同時,任何一個參數的順序進行了調整,則在這一句譯文中所有參數都必須註明原文位置,否則無法通過格式檢查。

注意註解

文件中有時會有給翻譯者的註解,以“#. 開頭”,多數情況下還會有“TRANSLATORS”字樣提示。通常是對所翻譯內容的解釋和提示,請在翻譯過程中留意。例如:

#. TRANSLATORS: ls output needs to be aligned for ease of reading,
#. so be wary of using variable width fields from the locale.
#. Note %b is handled specially by ls and aligned correctly.
#. Note also that specifying a width as in %5b is erroneous as strftime
#. will count bytes rather than characters in multibyte locales.
#: src/ls.c:708
msgid "%b %e %Y"
msgstr "%b %e %Y"

當然,有一些文件內主要是地名或國家名,開發者會省略“TRANSLATORS”直接給出提示,例如:

#. CN - China. (The official ISO 3166 short English name does
#. not include "The People's Republic of".)
#.
msgid "China"
msgstr "中國" 

關於換行

對於很長的譯文,就涉及到了換行問題。多數情況下沒有限制,因為不影響最終的顯示效果,只要閱讀起來方便就行。下面幾種格式都是正確的:

msgid ""
"Preview failed: neither the internal KDE PostScript viewer (KGhostView) nor "
"any other external PostScript viewer could be found."
msgstr ""
"預覽失敗:找不到KDE內建的PostScript查看器(KGhostView)或其它外部"
"的PostScript查看器。"

msgid ""
"Preview failed: neither the internal KDE PostScript viewer (KGhostView) nor "
"any other external PostScript viewer could be found."
msgstr "預覽失敗:找不到KDE內建的PostScript查看器(KGhostView)或其它外部"
"的PostScript查看器。"

msgid ""
"Preview failed: neither the internal KDE PostScript viewer (KGhostView) nor "
"any other external PostScript viewer could be found."
msgstr ""
"預覽失敗:找不到KDE內建的PostScript查"
"看器(KGhostView)或其它外部"
"的PostScript查看器。"

但是,如果msgid 前方有“#, c-format”標記,或者原文中有強迫換行標記“\n”,那就要手工調整譯文的換行,以便能最終正確地顯示在程式界面上。原則是譯文長度不大於原文長度,否則可能譯文顯示超出原有區域,或者譯文後面部分被截去,很難看。對於含有HTML 標記的長譯文還需要在瀏覽器中預覽顯示效果(如果您了解HTML 基本語法的話),酌情調整行寬。例如:

#, c-format
msgid ""
"Error opening file '%s':\n"
"%s"
msgstr ""
"打開文件“%s”出錯:\n"
"%s"

msgid ""
"Parse a theme dir and generate a \n"
"gkrellmrc_ksim file that KSim will understand \n"
"better and exit."
msgstr ""
"解析一個主題目錄產生KSim容易理解\n"
"的gkrellmrc_ksim文件,然後退出。"

多數CLI 程式都需要手工設定換行,這個時候希望翻譯者能夠對翻譯文件進行測試以確定每行到底應當放多少字元,尤其是翻譯命令參數的時候,如果不對長句進行強制換行處理或者一味依照文字編輯器所顯示的視覺上與英文原文長度相同,則很容易造成在程式實際執行中的格式非常難看。

關於對齊

對齊的問題通常出現在CLI 程式的命令參數上,英文原文一般會使用空格進行對齊,但是空格並不能使得最終執行的程式在使用中文的情況下將文字正確對齊,所以應當使用製表符(Tab) 代替。製表符的對齊也不總是能在文字編輯器上所見即所得,也就是說在文字編輯器上已經對齊的行可能在實際執行時前後相差一個製表符的距離。

關於模糊譯文

如果看到#, fuzzy 標記,則表示本段譯文是由工具軟體(通常是 msgmerge 命令)猜測翻譯得到的。有時比較準確,有時卻謬之千里。另一種情況是譯者或校對人員主動加上去的,因為他們對該條譯文沒有把握。因此請對其譯文進行修訂,然後去除模糊標記, 否則本段譯文將不能顯示在程式界面上。原則上,所有既往給出的譯文,在翻譯的時候都應該校對一遍。例如您拿到的文件中有如下行時:

#: groupdlg.cpp:209 groupdlg.cpp:216 groupdlg.cpp:229
#, fuzzy
msgid "Get Tagged Articles"
msgstr "取得文章" 

當您修正可能存在的錯誤後刪除整個“ #, fuzzy ”一行就可以了:

#: groupdlg.cpp:209 groupdlg.cpp:216 groupdlg.cpp:229
msgid "Get Tagged Articles"
msgstr "取得標記的文章"

可能還會遇到下面的情形:

#: groupdlg.cpp:623
#, fuzzy, c-format
msgid "Connecting to server %s"
msgstr "正在連接服務器"

在這裡,修正翻譯後在清除模糊標記時,“c-format”標籤必須保留:

#: groupdlg.cpp:623
#, c-format
msgid "Connecting to server %s"

關於已淘汰譯文

老版本的程式中總有一些訊息會在新版本中淘汰掉,這些譯文由msgmerge 程式自動設定為以#~ 開頭,並被置於整個po 文件的後方,直接刪除它們不會影響當前版本的翻譯內容,但是因為這些字元串還可能在以後的版本中重新出現,屆時msgmerge 還可以使用這些譯文來提供翻譯建議,所以如果它們沒有影響到您的工作建議不要刪除它們。例如:

#~ msgid "Error: no name"
#~ msgstr "錯誤:沒有姓名"

#~ msgid "Configure"
#~ msgstr "配置"
msgstr "正在連接服務器%s"

關於“translator-credits”字串

“translator-credits”是放置程式執行過程中查看鳴謝訊息時顯示的翻譯者條目,根據不同項目的小組可能有不同的填寫要求,最通常的填寫辦法是將名字和電子郵件地址列表如下:

msgid "translator-credits"
msgstr
"Telsa Gwynne <hobbit@aloss.ukuug.org.uk>\n"
"Dafydd Harries <daf@muse.19inch.net>"

注意在多個人名時最好每個人佔用一行,除最後一行外每一行的結尾都要使用\n 來進行換行。

關於時間的譯法

鑑於關於日期和時間的譯法十分複雜,現在將國家標準中有關規定簡要介紹一下,並給出推薦譯法。 國標GB/T 7408-94 《數據元和交換格式訊息交換日期和時間表示法》

1994-12-06 發布,1995-08-01 實施 國家技術監督局發布 本標準等效採用國際標準ISO 8601-1988《數據元和交換格式 訊息交換日期和時間表示法》

以下是最需要注意的幾個要點:
(1) 在日期格式中不能出現空格,即“2003 年”這樣的格式是不符合國標的。
(2) 表示日期時,必須按照年月日的順序;年份一般用四位數字,而月、日必須使用帶前導零的兩位數字;必須使用“-”作為分隔符,或完全不使用分隔符。即“2004-01-03”或“20040103”來表示2004年1月3日。
(3) 表示時間時,時、分、秒都必須使用兩位數字,中間用“:”(半形冒號)分隔,或完全不使用分隔符。小時計法採用24 小時制,不區分上下午。
(4) 日期和時間寫在一起的時候,應先寫日期再寫時間。在日期和時間都不使用分隔符的情況下,在中間添加字母“T”進行分隔,即“19850412T101530”。

時間的表示方法同date 命令的表示方法,現將常見的幾個對應其含義列表如下:

  1. %% 一個% 字元
  2. %A 星期幾(如“星期一”)
  3. %B 月份(如“八月”)
  4. %d 日期(00-31)
  5. %D 日期,格式等於%m/%d/%y(例如:08/25/09)
  6. %F 日期,格式等於%Y-%m-%d(例如:2009-08-25)
  7. %g ISO-8601 格式年份的最後兩位(例如:09)
  8. %G ISO-8601 格式年份(例如:2009)
  9. %H 小時(00-23)
  10. %i 小時(00-12)
  11. %m 月份(01-12)
  12. %M 分鐘(00-59)
  13. %n 換行
  14. %p 顯示“上午”或者“下午”兩個字
  15. %S 秒(00-60)
  16. %t 製表符(Tab)
  17. %T 時間,等於%H:%M:%S
  18. %x 日期(例如:12/31/99)
  19. %X 時間(例如:23:13:48)
  20. %y 年份的最後兩位(例如:09)
  21. %Y 年份(例如:2009)

相關工具的使用

gettext 工具集

gettext 工具集提供了一組使用PO 文件進行翻譯時的實用工具,現在對其中比較常用的幾個做簡短介紹。 若希望了解關於此工具的詳細訊息,請瀏覽GNU `gettext' utilities (1) msgfmt - 檢查格式並產生機讀的MO 文件 一般使用的格式為:

msgfmt --statistics -cv filename.po

這樣將會對翻譯格式進行檢查,如果有格式問題則會顯示錯誤原因並指明行號;如果檢查通過則顯示翻譯的進度情況並在執行目錄下產生一個名為message.mo 的文件,該文件便是程式執行時所要讀取的二進制翻譯文件。 在提交任何PO 文件前都請使用msgfmt 命令對格式進行檢查。

(2) msgmerge - 合併文件 一般使用的格式為:

msgmerge --no-wrap -o newfile.po fileA.po fileB.po 

這樣進行的結果是將文件A和文件B進行合併,若有不相同的地方以文件B為準,最後輸出在newfile.po中。

可以使用其更新選項來合併原來的PO文件和最新的POT文件:

msgmerge -U zh_TW.po example.pot 

這樣將會把原來的zh_TW.po另存為zh_TW.po~並更新zh_TW.po為新的內容,zh_TW.po~作為備份文件可以直接刪除。

(3) msgconv - 轉換文件編碼 一般使用的格式如下,作用為把zh_TW.po 從其他編碼轉換為UTF-8 編碼:

msgconv -t UTF-8 zh_TW.po

msgconv會自動更新文件頭出的charset設定,但是在開始翻譯前不妨再進行一下檢查以免出現問題。

(4) msginit -從POT文件建立PO文件 一般的使用格式為:

msginit -i example.pot -l zh_TW.UTF-8

這樣將會詢問翻譯者的電子郵件地址,然後產生一個名為zh_TW.po的UTF-8編碼文件。 如果執行程式的目錄下只有一個POT文件則-i選項可以省略;如果執行的locale為zh_TW.UTF-8則-l選項可以省略,也就是說這個命令最簡單的時候可以只輸入msginit 因為PO文件和POT文件的格式存在著一些微小的差異,如果您不是對它們十分了解則請使用此程式以避免可能出現的麻煩。

intltool 工具集

intltool 工具集實際上是一組腳本,用以實現一些常規的翻譯文件維護,其中部分命令除了支援PO 文件外還支援XML。一共五個命令,對於翻譯者來說比較常用的是intltool-update 和intltool-merge。這組工具多數需要在完整的原始碼樹中的po/ 子目錄下執行。要了解更多關於intltool 工具的訊息,請閱讀它的man 手冊。

(1) intltoo-update - 更新POT 文件並將PO 文件與之合併

通常使用它產生POT 文件時使用以下命令:

intltool-update -p

這樣將會在目錄中產生一個POT 文件。

要使用它更新原有的PO 文件,可以這樣執行:

intltool-update zh_TW

這樣將會自動產生新的POT文件並更新zh_TW.po,最後得到的文件是更新後的zh_TW.po ,也可以使用-o選項來定義輸出到指定文件而非更新原來的PO文件。

使用它來查看原始碼中的POTFILES 文件是否被正確維護,通常翻譯者不需要做這項工作:

intltool-update -m

如果輸出為空則代表一切正常,否則將有詳細提示。

(2) intltool-merge - 合併翻譯文件

一般使用方法為:

intltool-merge --utf8 po_directory input output 

其作用為將指定的po_directory 目錄中的所有PO 文件同input 文件合併,並將輸出寫入到output 文件,output 文件中包含了input 文件中的原始字串和其他PO 文件中的已翻譯字串。在進行合併前會把所有文件都自動轉換為UTF-8 編碼。

當input 為一個XML 文件時,輸出的output 文件也將是XML,PO 文件中翻譯的字串將作為“xml:lang”屬性插入到原XML 中一併寫入output 文件。

xml2po

xml2po 是gnome-doc-utils 中的一個工具,主要用途是在XML 和PO 文件之間進行轉換和合併。 要從XML 文件產生PO 文件:

xml2po -e -o book.pot book.xml

反過來要把已翻譯的zh_TW.po 合併回原來的XML 文件中:

/usr/bin/xml2po -e -p zh_TW.po -o book.zh_TW.xml book.xml

後記

本文是以 Aron Xu <happyaron.xu@gmail.com> 發布的「自由软件中文化工作指南(L10N)」為基礎翻譯、修正而成的正體中文版本。

-- Pellaeon Lin <nfsmwlin@gmail.com> - 2010-02-21

本文在Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported許可下發布。