2022 年,我成為了碁峰的外包翻譯,這也是本人對翻譯的初次體驗,這裡會分享關於這件事的契機、工作準備、心得等等,對未來有心從事專科翻譯的人可能有點幫助。

先介紹一下書籍吧,原文書是《Principles of Web API Design

Principles of Web API Design

來源:《Principles of Web API Design》

華文版的書名則是《Web API設計原則》。

Web API設計原則

來源:《Web API設計原則》

這本書理所當然的談的是 API。關於書目的選擇,出版社的窗口會根據專長給出幾本候選,在這個階段我們僅能憑書名、介紹、目錄、頁數等有限的資訊去決定,對譯者來說,選自己熟悉的主題是比較保險的,但人多半又想在翻譯之餘也能學到新知識,此時該往外跨出多少就是值得思考的。

舉例來說,Python 在機器學習領域很夯,但對一個終日和 CRUD 搏鬥的後端開發者來說,在相關基礎知識不夠健全的情況下,要跨界去翻機器學習書籍可能就太過困難,有無法完稿的可能性,因此還是要衡量自身的能力來決定。

回到本書的例子,本人對 API 的認識還算可以,之前也寫過幾篇與本書內容相關的文章:

除了這些自己還算了解的領域外,在這次的翻譯過程中也更完整的認識了 REST,特別是它「架構性約束」、「hypermedia」等的觀念,還有其他像是「OData」、「SSE(server-sent events)」等之前沒有深入接觸過的技術也都在翻譯的過程中豐富了我對他們的理解。

書籍的部份談到這邊,下面回到翻譯的主題。

如何成為翻譯

以碁峰來說,流程如下:

  1. 報名,姓名、聯絡方式、專長領域等等很基本的資料。
  2. 聯繫,如果對方覺得可以的話,會跟你聯繫,以本人為例,去年就有報名一次,但今年又報了一次才有聯繫。
  3. 選書,如上所述,從幾本候選的書目中挑一本有信心完成的。
  4. 試譯,對方會指定大約十頁內文+封面+封底+目錄給我們試譯,期限大約是一週,其中目錄看似字最少但其實是最難的,往往要真的去讀過該章節的內文才能準確的下出適當的標題,在翻譯目錄的同時也是讓我們自己搞清楚整本書脈絡的機會。
  5. 審閱,文字編輯會根據試譯稿的優劣來決定是否要交給我們翻譯,即便通過,他們也會對試譯稿內容提出意見,此時就要根據文編的意見反省自己的譯文,並做出調整。
  6. 簽約,合約上載明雙方權利義務,特別是截稿日、酬勞等都要確認,以碁峰來說,本身就是有知名度的出版社,合約也是中規中矩沒有特別偏袒某一方,與之相對的,Hahow 的合約就嚴重偏袒 Hahow 方,總之無論如何,簽署任何合約之前務必都要逐條確認內容。

經過以上流程,就可以開始翻譯了,但要成為列名於全國新書資訊網的譯者,那還得要交得了稿才行。

交稿後並沒有海闊天空,即使在交稿前已經自我校驗過,一定還是會有諸多的錯誤,這些錯誤可能是小到標點符號、錯字、贅字、缺字,大到錯譯、漏譯,不論大小,對讀者來說都是不可接受的缺陷,本人早年任職於絆腳石文創集團時,他們的每季文宣規定要校稿三次,即使如此,往往事後還是會發現錯誤。作為更專業的出版社,碁峰的校稿標準當然只會更高,他們有專業的文字編輯認真考核你的一字一句,包括標點符號以及構句的正確性,還有專業的外校前輩會挑出你所有誤譯、漏譯之處,作為一個新手翻譯,零零總總的缺陷大約有一千個吧,真是幸虧有專業的編輯和外校才讓本書的品質得以確保。

對一個專科譯者來說,要交稿需要三方面的能力:專業能力、英文能力、華文能力,而其中最重要的是華文能力,英文和專業反而是次之了,這部份留到後面再細談,先轉個話題談翻譯的執行與效率。

翻譯的軟硬體

要有效率的翻譯,在硬體方面,建議裝個雙螢幕,主螢幕擺編輯器,次螢幕擺原文 PDF,這樣可以省去大量切換畫面的瑣碎動作,雖然出版社有給我一本實體的原文書,但用到它的機會真的不多。

在軟體方面,曾經試過 Word、Notion、Visual Studio Code + Markdown,最後選的是 Google 文件,原因如下:

  • 最不卡頓,Word 本身就不是為書籍而設計的,頁數一多就卡頓,而且譯稿不需要樣式,沒有特別用 Word 的必要。
  • 即時存檔,全雲端化,不用擔心檔案遺失等雜七雜八的問題,還可以保有多個版本。
  • 可放圖表,雖然譯稿不用加樣式,但圖表還是要放的,Markdown 雖然也可以放圖表,但會打斷工作的沈浸感。

綜合考量上述問題之後,最後選擇了 Google 文件,中間也有去試過某個專業的 CAT(computer-assisted translation)應用 Termsoup,但它吃不了 PDF,沒兩下就放棄了,回到 Google 文件的懷抱。

通常那些 CAT 應用會整合 Google 翻譯之類的工具,反而 Google 文件僅有整合自家的字典,卻沒有整合自家的翻譯服務,總之又開一個 Google 翻譯頁面當成我的小助手。

除了 Google 之外,中間也試過各家的翻譯服務,Bing、有道、IBM 等,試了一輪下來,這些 AI 機翻都不夠到位,只有 Google 算是稍微好一點的,這也是為什麼譯者這個職業還存在的原因吧 :)。


上面談的是電腦的軟硬體,但從另一個角度來說,在翻譯的工作中,電腦軟硬體都是翻譯的硬體,唯有人才是翻譯的軟體,並且真正影響效率的還是人的層面。

以本人來說,一日最低的前進頁數是 0,最高是 10,平均是 6。

其中的 0,並非休假的意思,而是應該工作的日子卻毫無產出,這樣的日子比例是多少呢?大約是 1/10,也就是說大約每十天就有一天會零產出,原因不盡然是偷懶,有很多預料外的「假期」,例如掃墓、照顧家人、生病、打疫苗、家族聚會等等,這些都是無法逃避的事務,只能盡量及早安排、及早準備,取得工作和生活之間的平衡。

如果是兼職翻譯,在工作、翻譯、生活三頭燒之下,三者的平衡就更為重要了,假設一位兼職譯者,週一至週五每日可前進 1 頁,週六日每日可前進 6 頁,那一本 400 頁的書要 23 週才可翻完,這意味著他將連續 23 週完全沒有晚上和週末的休閒時光,這是將近半年的時間,如果是你,你或家人受得了嗎?如果出現意外行程該如何?如果正職工作又有加班那又該如何?

談完了翻譯的工具和效率,最後來談談「翻譯」這件事的本質。

翻譯乃大道 譯者獨憔悴

上面的標題來自余光中翻譯論集《翻譯乃大道 譯者獨憔悴》,這本書談他對翻譯的看法、翻譯的本質、翻譯的技巧、翻譯的取捨。

他是這麼說的:

翻譯也是一種創作,至少是一種「有限的創作」。同樣,創作也可以視為一種「不拘的翻譯」或「自我的翻譯」。在這種意義下,作家在創作時,可以說是將自己的經驗「翻譯」成文字。(讀者欣賞那篇作品,過程恰恰相反,是將文字「翻譯」回去,還原成經驗。)不過這種「翻譯」,和譯者所做的翻譯,頗不相同。譯者在翻譯時,也要將一種經驗變成文字,但那種經驗已經有人轉化成文字,而文字化了的經驗已經具有清晰的面貌和確定的涵義,不容譯者擅加變更。譯者的創造性所以有限,是因為一方面他要將那種精確的經驗「傳真」過來,另一方面,在可能的範圍內,還要保留那種經驗賴以表現的原文。這種心智活動,似乎比創作更繁複些。

要對翻譯的本質下一個詮釋,我想不可能比余光中老師說的更好的了。

翻譯的本質是「有限的創作」,回到本文最開頭說的,作為一個專科譯者,除了專業能力、英文能力,最重要的其實是自身的華文能力,華文能力的優劣表現在對譯文「傳真度」的高低,又同時要兼顧適當的本地化,這中間牽涉的是無數的取捨。

舉一個之前在另一篇〈如何理解 Jira 的 Story〉裡面的例子,story 標題在英文的固定語句是:

「As a XXX, I want YYY feature so that ZZZ.」

未經思索的翻譯會是這樣:

「身為一位 誰誰誰,我需要 某某某 功能才能 這般這般。」

但若仔細思考這段華文構句,其實是充滿贅字的,「身為一位…我需要」這部份大可刪去也完全不影響整句話的意思,而且更顯得簡潔,像這樣:

某某某如此如此 才能 這般這般。」

當然這只是最簡單的例子,實際上英文的子句、介係詞、代名詞等元素在翻譯成華文時都需要不斷的切分與重組,身為初階譯者的我,往往在構句時也會落入是A好還是B好的猶豫中,又或者是自我懷疑是否過度超譯甚至是創譯,或許答案得等到出版之後才能知道,希望不要被評為另一位「快思慢想洪教授」。

譯者資源

分享幾個在這期間看到的譯者資源: