職涯回顧：軟體本地化公司篇

話說 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 的每個工作經歷，都在約十年後寫一篇心得的話。那麼如果數年後這個網站依然健在，應該就會有下一篇的職涯回顧問世。