職涯回顧:軟體本地化公司篇
話說 DR 當年從第一份正職離職後,就覺得應該要寫一篇職業心得,但同時也認為這篇文章恐怕不適合太快寫成。或許要在自己有一些年歲後,才能夠有更健全的觀點,來回頭描述這些經歷,於是便決定留待約十年後再生產出此心得。因此讀者請留意,本文所描述之內容,皆為十年前之個人經驗,不見得反映出後續或者當前的產業情形。
雖然口語上 DR 時常將其稱之為翻譯公司,不過若是採更加詳細的描述,則 DR 出社會的第一份正職,是在一間專做軟體及文件本地化(localization)的公司。換言之就是客戶所提供的待翻譯內容,多半是例如應用程式的介面字串檔、或者說明文件的原始可編輯檔案。我們再交給多國譯者,翻譯成不同的語言後,再返回給客戶。另一方面,若純粹從譯者的角度來看,我們則可以被理解為是一間翻譯仲介(translation agency)公司,也就是為譯者派發翻譯工作。
公司的員工數不多,也幾乎沒有什麼層級,專案經理(project manager,PM)佔了最主要的人口組成,而 DR 應徵的職稱則是專案助理。專案助理的日常工作,就是接受各個 PM 所指派的任務,沒有明確的分野,主要就是看 PM 認為手上有哪些工作是需要分擔的。所以接收到的工作任務,可能會包含整理或預先處理待翻譯的檔案、輸出報表、對翻譯進行某種程度的檢查,以及與譯者往來收發件,諸如此類。
多種不同的翻譯輔助工具(computer-assisted translation,CAT),是日常工作中最常會接觸到的行業應用程式,印象中包含例如 Trados Studio、memoQ、Wordfast 等等這些軟體。使用 CAT 工具的主要意義,是能夠將各種不同類型的來源檔案,統一轉換成一種利於進行翻譯的雙語(bilingual)中介格式;而使用者同樣也是利用 CAT 工具所提供的編輯介面來進行具體的翻譯任務。然後在完成翻譯後,導回到原始檔案,便能夠生產出經過翻譯的版本。最起初各個 CAT 工具往往有自己專有的雙語檔,不過後來是逐漸統一採用 XLIFF 規範。
此外 CAT 工具也存在翻譯記憶庫(translation memory,TM)的功能,能夠導入過去既存的翻譯。這在翻譯報價上至關重要,客戶都會希望能夠核算出,軟體或文件改版後,確切需要重新翻譯的數量。所以可以理解到,儘管公司內的人員通常來說並不需要負責翻譯,但 CAT 工具依然是常態性會使用到的軟體,用於產生報表、計算成本,並提供給譯者可用於進行翻譯的檔案格式……等等這些工作。至於之所以需要操作不只一款 CAT 工具,則是因為有些客戶會自己提供待翻譯的雙語檔,是由特定的 CAT 工具生產出來的。那麼在一些保障相容性的需求上,可能就會需要使用跟客戶一樣的 CAT 工具,來進行某些作業。
當多國譯者交回各自不同語言的翻譯後,我們會再用其它工具載入內含原文及翻譯的雙語檔,進行基本的 QA(quality assurance)檢查。檢查的項目倘若列舉幾個較為顯著的例子,則首先是詞彙表(glossary、terminology)的對照。比方說假設在某一客戶專案裡,已知「File Manager」的繁體中文翻譯,是統一稱為「檔案管理員」。那麼工具就會去找出原文中含有「File Manager」、但繁中翻譯卻未見「檔案管理員」的段落,並標示在 QA 報告中。
其它的檢查項目,還例如有數字、通用縮寫以及變數標記的一致性檢查,比方說倘若原文有「42」這組阿拉伯數字,若是翻譯沒有的話,便會列於報告中。至於通用縮寫檢查,則是例如 USB 等詞彙,按理講在翻譯中也會保留原文,所以同樣會檢查是否依然存在。以及由於許多字串還會插入某些變數標記,以便在應用程式實際執行時替換為可變動的內容,所以同樣地會檢查標記在翻譯中的完整性。此外,也會檢查在不同段落裡,是否存在相同的原文、但翻譯卻不一致的情形。而這些報告在經過匯集後,通常會再返回給譯者,由譯者確認是否需要對翻譯進行修改。
儘管描述起來好像是蠻單純的,然而事實上 DR 一開始接觸到這項工作任務時,其具體的工作流程非常令人詫異,且充斥著許多不便。公司所使用的 QA 工具,是不知道起初從哪邊弄來的未授權軟體,所以都是採放在 VM 裡的方式來流通,也因此在實際的使用上多有不便。另一方面,這個 QA 工具所生產的報告,判斷規則實際上也有許多問題。使用者必須要人工剔除大量無用的報告條目,而無法藉由修改軟體功能來減少無用報告的產生。
由於實在太過低效而令人難耐,這使得 DR 重新設計了一套替代的 QA 工具。顯而易見的優勢,就是沒有授權問題,以及原始碼是自行維護的。所以容易部署,且功能可以按照實務的需求做修改。不僅如此,這個自製的 QA 工具,能夠支援的雙語檔格式也更多,因而消除了需要先對雙語檔做轉換才能進行 QA 的情形。實現更多種類的雙語檔支援,事實上開發成本並不算高。因為許多 CAT 工具即便是採用自有的雙語檔,也多半是某種 XML,分析及解讀其中的內容並不算麻煩。後期更是因為 XLIFF 已成普遍標準,擴展支援上更顯容易。
另一件同樣讓人對於其工作效率感到詫異的任務是寄信。在前面的描述裡,應該已經可以猜測到,每天發信給多國譯者,算是公司平日業務的日常。因各個案子的語言數而異,每一次發送的數量可能會有從數個到十來個不等的收件者。而發送的內容則不外乎是待翻譯的檔案、翻譯後的 QA 報告,或者某些客戶會提供產品在不同語系下的擷圖,供譯者做目視確認及審校,以及其它各種的事項。
由於在信件裡一次填很多個收件者,並非實務上可接受的作法。所以 DR 被交代的工作流程,是準備一份收件者清單,跟一份郵件內文。然後就在郵件客戶端軟體裡,建立新訊息,貼上收件者,貼上主旨,貼上內文,放附件,發送,再接著下一位,依序重複做相同的事……直到把整份清單發送完畢。
這便是為什麼本站曾有一個期間,出現數篇與實現批次寄信功能有關的技術文章。最起初的實作是適用於 Outlook Express 及 Microsoft Outlook,後來則因為 DR 自己改用 Mozilla Thunderbird,所以又再實作了 Thunderbird 下的解決方案。這些程式實作能夠讓使用者無須使用額外的寄信系統,在既有的郵件客戶端軟體內,就能夠以更高的效率來發送多封信件,同時也能夠避免因過程繁複而滋生人為錯誤的風險。
藉由技術手段解決工作上幾個效率低下的問題後,自己能夠支配的時間真的變蠻多的。通常每天上班的日常,就是先打開信箱收一堆譯者的回覆,進行相應的後續作業後,倘若沒有其它案子或需求進來,剩下的就是自己的時間。可以繼續寫些程式來處理瑣碎的問題或需求,或者是研究及試驗一些更具變革性的計畫或構想。
雖然這是 DR 的第一份正職,而且職務本身就公司的認知,對於開發能力其實沒有強烈要求。但反而是 DR 職涯至今,在程式開發上所投注的勞力最多、也是需求項目最為多樣的一個期間。之後的幾份工作,雖然都還是會自己寫些程式來用,但也都未曾再達到同等的強度及廣度。並且也是在這個期間大量使用 Python 語言來編寫程式,形成了後續工作上的一個慣例。儘管當時所編寫的程式碼,現在若回頭來看其設計水準,其實有許多是慘不忍睹、讓人不敢直視的。不過至少在當時確實是可用,而且能夠解決當下的問題。
工作中另一個技術性的面向,是公司內沒有 MIS 或類似意義的資訊專責人員。儘管若有個人設備問題,一般來說人員都能夠自力解決。然而公司內部並沒有任何人,對於公共設備,例如網路設施、硬體防火牆、ESXi 及 Linux 伺服器主機等的運作細節,有較充分的認識與掌握。這使得 DR 在進入這間公司後,幾乎是無可避免地,因著各種問題的需要處理,變得也有點像是在做 MIS。
於是 DR 重新釐清了過去未有妥善記錄的網路架構及各類設施,確認了維護管理及應對方式。並且將既有的伺服器資源活化利用,新增內部 Wiki、VPN、Git 儲存庫等額外服務,也為檔案伺服器建置額外的異機備份及磁碟陣列等等。不過總歸來說,這是 DR 在網管這項領域中非常初級的工作經驗。現在年紀長了,累積的知識與經驗也更多。倘若回頭來看過去的情形,會覺得應該還有很多可以做得更好的地方,即便這確實不是 DR 在這間公司的本業。
或許沒有專職 IT 人員的部份因素,是公司的日常業務,對於內部設施的可靠性需求真的不太高。其中最為重要的郵件服務,在 DR 入職前便已改用購買企業信箱的方式處理,從而捨棄了原本架設在內部的郵件伺服器。甚至也可以說,其實人員待在辦公室工作的必要性也不大。任何地方只要手上有電腦、有網路,可以收發信,幾乎沒有什麼任務是無法完成的。人若不在公司內,可能最多是影響了某些作業的便利性,但並沒有到不可行的程度。
所以一方面可以理解到,在這間公司裡,在家或在外處理公務是一個可行的選項;而另一方面,也由於公司的客戶有很大比例不是台灣本地企業,這使得公司對於休假的應對有一點非同尋常。倘若逢彈性連假要補班的,則連假照休,但不補班。但若休假期間手上有案子需要及時跟進,相關的負責人員還是要設法實現出來。除此之外,也可以感受到業務的負載週期,跟本地節期的關聯性較低。反而是聖誕節期、或者是對岸的十一連假,比較能夠感受到業務量的落差。
接著來談談翻譯品質的議題,因為這應該是 DR 在這段工作經歷中感觸最深的部份。前面曾提到過,對於各種不同語言的翻譯,我們會採取基本的工程方法,試著檢查出是否存在不應發生的低級錯誤。但無論如何,這都是一道相當粗淺的檢查程序,無法根本地取代由真正熟悉該語言的人,透過實際地閱讀來判斷其正確性。
一個顯著的案例,是有某個中國品牌的客戶,因為是看得懂中文的,就發覺到我們提交的繁中翻譯有一些嚴重的品質問題。於是公司的應對措施,是此後這個客戶的案子,繁中的部份除了基本的 QA 檢查外,還多加入了一道內部審校(proofreading)程序。而這項任務就落在 DR 的身上,也就是翻譯交出去之前都要先整個看過。並且也為此需求再擴充了自製程式的功能,讓雙語檔的內容能夠統一輸出成整齊的 Excel 表格,以便進行逐條檢查及反饋。
於是在人工審校的過程中,確實會發現到一些翻譯錯誤,就需要反饋給譯者進行修正。甚至在幾次問題反饋後,就會意識到某些譯者恐怕是不適任的,出錯率太高或者錯譯太嚴重,也就會因此汰除掉,不再派案子給他。那麼這就會產生一個疑問,如果繁中要這樣做才能保障正確性,那其它語言呢?
其它語言沒有這個程序,無能為力。雖然公司標榜能夠一次生產出十幾種不同語言的翻譯,但我們其實只對於中文有真正踏實的檢查能力。所以除非出了什麼明顯的包,被人家發現,否則我們徹頭徹尾都不會知道,我們所提交出去的多國翻譯,其翻譯水準究竟到什麼程度。雖然在一些較為少數的案例裡,我們確實也會設法跟國外譯者溝通翻譯問題。然後在不熟悉該語言的情況下,透過例如將翻譯丟進 Google 圖片搜尋、或者使用機器翻譯的結果做比對,來向譯者陳述我們對於該語言翻譯正確性的疑慮。不過總歸來說,在 DR 當時的工作經歷裡,我們曾明確地因為品質做淘汰的應該是只有中文譯者,其它語言的譯者不太發生這樣的事,因為我們沒有足夠的能力去做出判斷。
那麼在公司內沒有任何人是語言萬事通的情況下,或許一種更加保障多國翻譯品質的解決方案,是每個語言的翻譯都要經過兩名譯者(一個翻譯、一個審校)。雖然不會說這在品質上就一定是萬無一失,但起碼是體現出更加嚴謹的過程。然而在公司給客戶的報價裡,翻譯跟審校是分開來的兩種費用,倘若客戶明確地想要有這個程序就要加錢,我們不會為了加強製程的良率就讓自己多承擔開銷。
這個產業的競爭似乎主要是取決於價格與時效,但顯然並不是說客戶就因此認為翻譯的正確性不重要。就好比是一間餐廳可以標榜它價格便宜、出餐又快。但顧客正常來說,不會因此就容許它的食品安全可以有打折扣的餘地──食物再怎麼便宜,吃下去也不能出事吧?但不幸的是,我們的生產方式確實沒有充分表現出對於「食安」的重視。
然而估計也是有不只一種因素構成了這樣的情形,有許多客戶,在整個產品的開發過程裡,願意分配給翻譯的時間及經費,在比例上似乎顯得相對緊縮。這使得客戶更傾向於壓低價格與交期,找尋願意如此配合的翻譯公司,而這樣的翻譯公司自然也是按相似的條件來找尋譯者。一層層剝下來,能力更好的譯者或許就不太願意接,而人選受限也就有可能影響了最終翻譯的品質。
而且這樣的層層剝削,能夠到什麼程度,很有可能是客戶沒有認真思考過的。在這個產業裡,客戶有可能經過一番評估,看上了一間有著亮麗宣傳的 A 公司,於是把案子交給了 A。卻渾然不知 A 實際上把案子轉給了相對來說默默無名的 B 公司,而且是由 B 負責所有生產任務;A 就是左手進右手出,沒有在其中有任何監督或協助。於是這樣的層次越多,客戶經費裡真正支付給譯者的翻譯費就越少,因為每個層級都需要分一杯羹。
甚至有可能因此給譯者的工作時間也更少,上面說三天,中間說兩天,於是最下層真正執行翻譯的人只得到一天。這個翻譯生產鏈裡各個層級之間的互動,從企業內部的本地化部門開始,到中間不知道轉了幾手的翻譯公司,以及在與譯者聯繫時,都很容易會把 urgent(急件)掛在嘴邊,為的是讓自己的層級盡可能獲得更多緩衝期。不過 DR 自己則是盡量避免這樣的作法,會比較務實地與譯者設定交期。
名不副實的宣傳,不僅是那些會把客戶案子轉交到我們手上的同行;其實我們自己在跟客戶互動談生意時,也經常表現出好像自己是一間蠻大的公司,許多語言都有專責的國外翻譯團隊或人員,但實際上我們就只是有一批經常往來的自由譯者而已(或者有些其實也是國外其它翻譯公司的聯絡窗口)。
我們有許多客戶都是非常知名的企業及品牌,估計他們其實不缺經費來改善產品翻譯的生產方式。DR 有時候會心想,如果他們認真知悉當案子交出去後,整個生產鏈實際的運作情形。也許他們會轉而評估是否應提昇內部能量,建立一個能夠直接與譯者互動的生產流程,而不再透過這些所謂的翻譯公司來從事生產。
不過在與客戶互動的過程裡,其實也會意識到即便是相當大型的科技企業,可能也會對如何妥善地進行產品本地化,缺乏足夠的知識及通盤考量。因而產生許多應該在更早期階段就要消弭的問題,到了最後要進行多國翻譯時才浮現出來。並且屆時若要解決問題,往往也會變得更加麻煩。舉例來說,我們有一個客戶,他們有大量的行動應用程式其實最原生的語言是簡體中文。然後在翻譯成英文後,再進一步翻譯成多國語言。然而由於這些應用程式的 UI 多半是根據中文長度來設計的,所以一旦翻譯成其它文字長度更長的語言後,版型及顯示就容易出現問題。
類似的案例還包含了有某個客戶,在起初開發應用程式時,沒有考量到中東語言由右至左(RTL)的呈現方式。也是在翻譯之後,才發現應用程式在呈現這些語言時存在著許多問題。至於避免這類情形的最佳實踐,則是可以考慮在開發過程中,直接先用機器翻譯產出各語言的測試版本,來進行初步的驗證與調校。其它的最佳實踐案例,則還有例如在製作文件時,應避免將說明文字嵌在圖片內。而是利用諸如數字來標示,再用其它的版面對標示處進行文字說明,以簡化不同語言版本的製作工程。
我們公司的老闆,事實上也是有一點想法,覺得如果公司能夠有技術能力,更加涉入在客戶產品的整個本地化工程裡,那麼應該有利於在同業競爭中脫穎而出。而 DR 在準備離職時,也確實有建議公司應該要開工程師的職缺,來維持或者進一步提昇公司的技術能量。離職前還有研究一些尚未具體實現的初步構想,例如導入某種線上管理系統,來取代過去以信件收發為主的專案管理方式;以及依循某種開放架構的文件生產模式,以便以更低的軟體成本生產出多語言及多格式的文件版本。
這份工作雖然不是預期會長久做下去的工作,但依然是有學習到很多事情的工作機會。如今每當 DR 在企業網站上、應用程式裡、電玩遊戲、或者是在說明文件內,看到令人翻白眼的翻譯時,只要回想起這生產鏈背後可能的模樣,頓時就不覺得意外了……此外也不僅是關於技術及產業的認識,英文能力也是因此有被拉拔到一個新的水平。而不是像以前只是靠著玩遊戲跟修電腦,多少累積一點英文程度,果然還是在職場環境裡學得比較快速。
或許還有一個應附帶一提的,是 DR 當年在 104 找工作的過程裡,覺得要求有相關工作經驗的職缺比例,似乎有點不切實際地高。如果社會上一堆職缺都期望要有經驗,那麼新鮮人要怎麼樣才能獲得第一份工作經驗呢?雖然 DR 很幸運地得到了未要求經驗的工作機會,然而總覺得這種前置條件,有風險會因此排擠掉那些雖尚無經驗、但實際上經鍛鍊後對公司有益的真正人才;且另一方面,或許也有可能會助長那些號稱有多年經驗、但實際上恐怕只是一年經驗重複了多年、專業上不知長進的冗員,繼續在業界中流動佔缺。
最後,倘若 DR 的每個工作經歷,都在約十年後寫一篇心得的話。那麼如果數年後這個網站依然健在,應該就會有下一篇的職涯回顧問世。