《譯難忘》:接受委託的郁達夫,到底有沒有翻譯林語堂《京華煙雲》?

《譯難忘》:接受委託的郁達夫,到底有沒有翻譯林語堂《京華煙雲》?
郁達夫跟王映霞的合照|Photo Credit: Unknown@Wikimedia Commons Public Domain

我們想讓你知道的是

雖然郁達夫是林語堂指定的譯者,但郁飛的譯本卻有很嚴重的翻譯腔。其他三個譯本都是先說地點「北京東城馬大人胡同西口」,再談物事,正規中文寫法;只有郁飛的「一批騾車來到北京東城馬大人胡同西口」以騾車為主語,顯然受到英文影響。

文:賴慈芸

郁達夫殘稿疑案
汎思的《瞬息京華》(一九四六)

林語堂最著名的小說Moment in Peking(一九三九),其實是一本英文小說,於中日戰爭期間在美國出版。一出版即成暢銷書,不但被《時代雜誌》選為一九三九年最佳小說,甚至林語堂也因此在一九四○年被提名諾貝爾文學獎,可惜當年因歐戰關係暫停頒獎,與諾貝爾獎擦身而過。林語堂本想翻譯《紅樓夢》,後來覺得美國讀者不易接受,因此改寫小說。他從紐約寫給郁達夫的信中說:

今日西文宣傳,外國記者撰述至多,以書而論,不下十餘種,而其足使讀者驚魂動魄,影響深入者絕鮮。蓋欲使讀者如歷其境,如見其人,超事理,發情感,非借道小說不可。況公開宣傳,即失宣傳效用,明者所易察。弟客居海外,豈真有閒情談說才子佳人故事,以消磨歲月耶?

可見寫作時就以打動西方讀者,爭取同情為要務。這部作品人物模仿《紅樓夢》,也是林語堂自己承認的,說是「木蘭似湘雲,莫愁似寶釵,紅玉似黛玉......迪人似薛蟠,暗香似香菱,阿非則遠勝寶玉」云云。又在批評鄭陀、應元杰合譯本《京華煙雲》時說:「我不自譯此書則已,自譯此書,必先把《紅樓夢》一書精讀三遍,揣摩其白話文法,然後著手。」可見林語堂心目中理想的譯本,應該很像《紅樓夢》。可惜他忙於以英文著述,沒有時間自譯,委託給郁達夫翻譯,預付稿費,還建議書名可用《瞬息京華》。

郁達夫在《星洲日報半月刊》上兩次提過這本書,一九三九年八月還不知道作者建議的書名時,稱為《北京一剎那》;一九三九年九月接到林語堂委託翻譯的信,已知作者建議書名為《瞬息京華》,但他在一九四○年五月仍把書稱為《北京的一瞬間》,可能是他屬意的書名。只是最後傳世的書名,都不是兩個人取的,而是鄭陀、應元杰取的《京華煙雲》。

郁達夫接受了委託,到底有沒有翻譯呢?一九四○年五月,他自承:「我正為個人的私事,弄得頭昏腦脹,心境惡劣到了極點,所以雖則也開始動了手,但終於為環境所壓迫,進行不能順利......我也很感到對林氏的歉意。」郁達夫與王映霞當時正在鬧離婚,因此心緒不佳可以理解。六月間,則稱:「譯事早已動手,大約七月號起,可以源源在《宇宙風》上發表。」但《宇宙風》已從上海遷去香港,郁達夫的翻譯始終沒有在《宇宙風》上連載。一九四一年,郁達夫在新加坡主編《華僑週報》,郁飛(郁達夫與王映霞的長子,當時十一、二歲)建議爸爸在《華僑週報》上連載譯文,一方面履行前約,一方面也可以提高週報的聲望。連載了一段時間,太平洋戰爭爆發,日軍占領新加坡,《華僑週報》因抗日色彩鮮明,收藏皆被毀。這些字數不詳的譯文,至今始終沒有人找到。等到一九四五年戰爭剛結束,郁達夫就死於日軍之手,再也沒有完成譯稿的可能。

郁飛始終惦記這件事情,終於在一九九一年推出他翻譯的《瞬息京華》。林語堂雖然為郁達夫親自詳注小說中人名典故,但郁飛似乎也沒有占到便宜,因為郁達夫的注解本和譯稿都失傳了。研究郁達夫的陳子善教授曾在二○一五年走訪陽明山林語堂紀念館,寫了一篇文章〈語堂故居仍在,達夫手稿安在?〉,文中說林語堂的女兒林太乙親口告訴過他,確實把刊有郁達夫譯文的《華僑週報》捐給台北市立圖書館了,後來移交林語堂紀念館,但館方卻說沒有此文件,讓陳子善無限惆悵。(比較不合情理的是,如果林太乙手上有郁達夫譯文,為何不寄給郁飛?)沒想到林語堂故居在二○一五年十月卻公開一份刊登在《華僑評論月刊》上的《瞬息京華》,日期從一九四六年七月到一九四七年二月,連載到原作的第二章,署名「汎思」譯。雖然刊名不是林太乙和郁飛說的《華僑週報》,署名也不是「郁達夫」,開始刊登的時候郁達夫也已經遇害,但林語堂故居官網直接宣布這就是郁達夫的譯稿。

《華僑評論月刊》上連載的《瞬息京華》
Photo Credit: 聯經出版提供
《華僑評論月刊》上連載的《瞬息京華》

後來一些關心此事的學者開始質疑這份殘稿是郁達夫所譯,理由包括:這個譯本用了章回的套語,如「話說」、「且說」之類的,與郁達夫的習慣不合;還有《華僑評論月刊》是國民黨的報紙,素來與郁達夫沒有往來;再來就是我也提過的時間問題:郁達夫一九四五年遇害,這份譯稿卻是從一九四六年開始連載。所以林語堂故居的官網也不再聲稱這是郁達夫的譯稿,只說是《華僑評論月刊》所刊載之《瞬息京華》。

無論這位「泛思」是否為郁達夫,我覺得這個譯本還蠻符合林語堂的想像,也比現有的幾個譯本好。林語堂自己在〈談鄭譯瞬息京華〉長文中,自己示範譯過一小段。以下是鄭陀譯本和林語堂自譯本的對照:

鄭陀:

「媽媽,」珊姐勸著道,「什麼事都是上面注定的;沒有人可以確定他們的前途是禍是福。你還是莫要這樣傷心,致妨礙身體。要趕的路程有長長一段呢,許多人的生命都還依靠著你……」

林語堂:

「媽,」珊姐勸道,「凡事都由天定,是吉是凶,誰也保不定。請媽快別這樣,保重些好,前途要趕的路還遠著呢,這一家大小都靠你一人……」

林語堂還說:「文言虛飾萎弱之病,白話作家有過之無不及。欲救此弊,必使文復歸雅馴......鄙白話之白,易之以文言可,代之以洋語不可。」可見林語堂若要翻譯,走的也必然是歸化路線,更何況這本小說本來就是寫晚清到民初的中國,歸化更是合理。以下比較幾個譯本的開頭:

一、最早譯出的是鄭陀、應元杰譯的《京華煙雲》(一九四○),也是台灣頗為流行的譯本。遠景版沒有署名譯者,只寫「林語堂著」,讓不少讀者誤以為這本是林語堂用中文寫的作品:

一九○○年七月二十那天,一個大清早。北京東城馬大人胡衕西口,橫列著一群騾車兒,一條線的直接到沿著大佛寺紅牆根南北向的那條小路頭。那班趕騾的伕子是起身早慣了的,天剛破曉,三三兩兩地都已等候在那裡了。他們一夥兒一個個是饒舌的傢伙,那一天有了那麼許多淘夥兒候攏在一起,清晨的空氣裡免不掉激騰起煩瑣的喧擾聲來了。

羅大已經是個五十來歲的老年人,便是這一家僱了大批騾車兒,準備趕路的公館裡的總管家,正吸著旱煙管看那些騾伕們一壁還在喂牲口,嘴裡卻不住的開玩笑,你嘲我的我嘲你的,從牲口取笑到牲口的祖宗。

二、譯者生平不詳的汎思《瞬息京華》(一九四六)殘稿:

話說光緒二十六年七月二十日那天,北京東城馬大人胡同西口停住一隊騾車,有的排過街外沿著大佛寺粉紅圍牆一條南北夾道。這日黎明,各騾夫俱已來到,聚首相談,吵吵鬧鬧總是不免,故此滿街人聲嘈雜。

原來這些車輛專為出遠門打發來的。那僱戶老管家名喚羅大,年方五十歲上下,一邊抽著旱煙袋,一邊看著餵草,那些騾夫只顧彼此說說笑笑,鬧個不休。把你我的騾子連帶騾子的祖宗嘲弄既盡,仍要自相頑謔一回才罷。

加了「話說」,西元改為「光緒」,語法也比前一個譯本符合中文習慣。鄭應譯本很囉唆,第一段就出現「大清早」、「破曉」、「清晨」三個意義重複的語詞,汎思譯本則只用了一次「黎明」。

第二段的第一句尤其可以看出翻譯功力高下。原文以「羅大在抽煙」作為主要句子,其他資訊都包在層層子句,不易拆解。鄭應譯本這個句子很拙劣,「羅大已經是個......便是......正吸著......」翻譯腔很嚴重。何況以羅大開頭和第一段銜接不上,有點突兀。汎思輕巧的一句「原來這些車輛專為出遠門打發來的」,承上啟下,看來全不費力,其實大師手筆就在此處,非常精采。

三、文化大學教授張振玉的《京華煙雲》(一九七八)。張振玉(一九一六-一九九八)是老北京,畢業於北京輔仁大學,曾師事名譯家李霽野、張榖若、英千里等,對話自然流暢,遠勝鄭應合譯本。他的譯本第二版還有回目,第一回「後花園主埋珠寶/北京城人避兵災」,開頭是:

光緒二十六年七月二十日早晨,北京東城馬大人胡同西口兒,橫停著好些騾子車,其中有幾輛一直停到順著大佛寺紅牆南北向的那條胡同。趕騾子車的都起身早,天剛破曉就來了。大清早晨就在那兒喊喊叫叫的。其實這些趕大車的一向如此。

羅大是五十來歲的老年人,是這一家的管家,僱了這些騾子車,是準備走遠道兒的。他現在正抽著旱煙袋,看那些騾夫們餵牲口,一邊吵吵鬧鬧地開玩笑,從牲口取笑到牲口的祖宗。再沒話可說了,就取笑到他們自己頭上來。

雖然可以看出努力歸化,如也用「光緒」取代西元,但還是有點囉唆,如「早晨」、「破曉」、「大清早晨」的重複;另外第二段的第一句,還是以「羅大」開頭,也犯了銜接不順的問題。

四、郁達夫的兒子郁飛所譯的《瞬息京華》(一九九一):

光緒二十六年七月二十日清早,一批騾車來到北京東城馬大人胡同西口,有幾頭騾子和幾輛大車一直排到順大佛寺紅牆的那條南北向的小道上。趕車的起身早,天剛亮就來了。他們七嘴八舌,大清早就免不了人聲嘈雜的。

五十上下的老人羅大是僱了這些騾車即將出遠門的這家子的總管,正抽著旱煙管注視趕車的餵牲口;而趕車的則彼此說說笑笑,吵吵鬧鬧,從牲口鬥到牲口的祖上,最後互相逗樂。

雖然郁達夫是林語堂指定的譯者,但郁飛的譯本卻有很嚴重的翻譯腔。其他三個譯本都是先說地點「北京東城馬大人胡同西口」,再談物事,正規中文寫法;只有郁飛的「一批騾車來到北京東城馬大人胡同西口」以騾車為主語,顯然受到英文影響。但車是停著的,並不是現在來的,所以他的寫法不好。羅大那個句子也非常冗長而歐化。目前市面上最常見的是張振玉譯本,郁飛譯本市場反應並不佳。有些批評家為郁飛抱不平,說郁飛的譯本最為忠實。但無論忠實與否,郁譯本的歐化句子實在太多,如「全都屬於被愛好此道的道學家視為哪怕不是傷風敗俗之至也是很低賤的社會階層」、「這使得他屬於最早吸取正在開始改變中國社會的新思想的一代人」、「經歷了這些及時抓住的愉快的瞬間她對人生是看得透徹得多了」,實在不是出色的譯本。

相關書摘 ▶《譯難忘》:堪稱「西洋聊齋」的《天方夜譚》,何時開始有中譯本?

書籍介紹

本文摘錄自《譯難忘:遇見美好的老譯本》,聯經出版
*透過以上連結購書,《關鍵評論網》由此所得將全數捐贈聯合勸募

作者:賴慈芸

金鼎獎得主・翻譯偵探賴慈芸嚴選五四百年回顧17部美好的老譯本
不同文體與風格的譯本,解放你對翻譯的想像!
從林紓、梁啟超、伍光建、徐志摩等名家的翻譯作品中,看見一部中文變化簡史。

你對翻譯的想像是什麼?
忠實呈現還是二次創作?

一般讀者對翻譯的想像,往往先要求忠實原文,其次要求通順可讀,卻很少提到翻譯本身的藝術性。畫家林風眠曾說:「如果畫鳥只像鳥,那又何必畫呢?」跟波赫士談翻譯有異曲同工之妙:「如果翻譯只求和原文一模一樣,那又何必譯呢?」

然而五四運動倡導中文改革,當時的進步青年對於波赫士推崇的這類歸化路線譯文往往抱持負面態度。他們崇尚異化譯文,對忠實的要求勝過對文采的要求。這是多麼可惜的事!中文的音樂、節奏、簡約之美,就往往被「忠實」給犧牲了。

林紓在五四運動前夕,曾預言廢文言的後果,就是連白話都寫不好:「非讀破萬卷,不能為古文,亦並不能為白話。」2019年就是五四百年,林紓的預言,其實也已成事實:今天白話的冗贅、翻譯腔、邏輯不清諸病,不正是不讀文言的弊病嗎?

其實清末民初用文言翻譯西方文學,留下了不少精品。而1920年代也堪稱白話翻譯的黃金時期,正因為1920年代的譯者大都受過嚴格的古文教育,包括胡適在內,證實了林紓「白話從古文出」的看法。只是這些翻譯,以往有政治不正確的問題:他們往往被劃為反動、守舊、不思進步的陣營,在「忠實原文」的大旗下顯得不合時宜,因此在翻譯史上也不怎麼受到重視。

賴慈芸特別選了一些現在比較少見或比較少人談論的版本,展現翻譯的各種風貌。也讓大家看看,拿掉「忠實」這個緊箍咒以後,翻譯可以多麽有趣!

getImage-4
Photo Credit: 聯經出版

責任編輯:潘柏翰
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡