“某數(shù)據(jù)科學(xué)平臺博客中文翻譯二”是我最近做完的一個內(nèi)容漢化項(xiàng)目。做技術(shù)內(nèi)容這幾年我始終有“知識只對自己夠用不算本事”的想法所以當(dāng)這個翻譯項(xiàng)目進(jìn)入第二期時我花了兩個多月把二十多篇英文數(shù)據(jù)科學(xué)文章逐篇翻譯、審校、重跑代碼最終整理成一套可以直接閱讀和復(fù)用的中文內(nèi)容。這個項(xiàng)目適合兩類人一類是英文閱讀有障礙、又想系統(tǒng)學(xué)習(xí)數(shù)據(jù)分析與機(jī)器學(xué)習(xí)的讀者另一類是打算做技術(shù)文檔漢化、知識庫遷移或內(nèi)容本地化的譯者和內(nèi)容運(yùn)營。文章主題覆蓋數(shù)據(jù)處理、建模、可視化和數(shù)據(jù)工程這些常見方向整套過程不光是逐句翻譯還包括術(shù)語統(tǒng)一、示例重建、代碼驗(yàn)證和排版規(guī)范。這篇文章把第二期項(xiàng)目是怎么組織起來的、選了哪些文章、定過哪些規(guī)則、踩過哪些坑原原本本寫出來給打算走類似路線的朋友做個參考。1. 項(xiàng)目緣起為什么第二期要做“翻譯”而不是“創(chuàng)造”1.1 第一期留下的三個關(guān)鍵復(fù)盤第一期翻譯完成后我回頭翻了一遍所有譯文發(fā)現(xiàn)有三件事如果當(dāng)時重新做一定會換一種思路。第一是術(shù)語不一致。同一批文章里“feature”有的譯成“特征”有的譯成“變量”甚至有篇文章直接寫“特點(diǎn)”“scaling”一會兒是“縮放”一會兒是“歸一化”。讀者連續(xù)讀幾篇譯文時很容易產(chǎn)生“這幾篇文章是不是同一批人寫的”的疑惑。第二是翻譯腔。不少句子是照著英文逐詞替換過來的倒裝結(jié)構(gòu)和被動語態(tài)全保留下來讀起來非常累。比如“模型被評估使用多種指標(biāo)”中文讀者看到這種句子要先在腦子里重新組織一遍語序正常的說法應(yīng)該是“我們用多種指標(biāo)評估模型”。第三是代碼和圖片沒有嚴(yán)格復(fù)核。很多譯文只翻譯了正文圖例和坐標(biāo)軸文字還是英文代碼換個環(huán)境就直接報錯。這三點(diǎn)直接成為第二期設(shè)計的出發(fā)點(diǎn)先建術(shù)語表再定風(fēng)格規(guī)范最后加一道完整的技術(shù)復(fù)核環(huán)節(jié)。1.2 第二期選了什么文章服務(wù)什么讀者第二期的選文范圍不是把平臺上的文章全部拿過來。我重點(diǎn)挑了三類內(nèi)容。第一類是能直接落地的操作型文章比如數(shù)據(jù)清洗、基礎(chǔ)可視化、常見查詢寫法讀者看完能馬上在項(xiàng)目里使用。第二類是概念型文章涉及機(jī)器學(xué)習(xí)流程、模型評估、特征工程這些偏底層邏輯的內(nèi)容這類內(nèi)容最容易“看完就忘”但恰恰最需要準(zhǔn)確翻譯因?yàn)樾g(shù)語一旦混亂后面學(xué)什么都歪。第三類是專題深入型比如時間序列處理、模型可解釋性、性能調(diào)優(yōu)服務(wù)的是已經(jīng)做實(shí)際項(xiàng)目的讀者。為了控制難度梯度我把入選文章分成三檔。入門實(shí)操類8篇建模進(jìn)階類9篇專項(xiàng)深入類7篇總計24篇。排除掉兩類內(nèi)容一類是促銷性質(zhì)過強(qiáng)的軟文這類文章技術(shù)含量低翻譯過來也沒多少價值另一類是過度依賴特定商業(yè)產(chǎn)品版本的文章等翻譯完產(chǎn)品已經(jīng)升級內(nèi)容就失效了。這個篩選原則我建議所有做技術(shù)翻譯的人都拿小本子記一下不是所有文章都值得翻譯選文的判斷標(biāo)準(zhǔn)應(yīng)該是內(nèi)容質(zhì)量加穩(wěn)定性。1.3 第二期相比第一期的四大改進(jìn)第一期暴露出來的問題在第二期做了系統(tǒng)性調(diào)整具體落在四個方面。第一術(shù)語表前置。第一期的術(shù)語表是翻譯到一半才補(bǔ)的第二期直接從第一批源文本里抽出高頻詞提前定好譯法后面所有文章共用一張表。第二每一篇文章增加“技術(shù)復(fù)核記錄表”記錄代碼運(yùn)行環(huán)境、依賴版本、運(yùn)行結(jié)果任何一篇文章出了問題都能按記錄追查不用全文重新檢查。第三圖片和圖表盡可能重新繪制用中文標(biāo)簽替代英文原文而不是繼續(xù)沿用帶英文標(biāo)注的舊圖。第四在譯文里保留原文的版本說明凡是涉及庫版本差異、函數(shù)改名的地方都用“譯者注”顯式標(biāo)出。這四個改動并不復(fù)雜但實(shí)際操作時非常有效。尤其是術(shù)語表前置這一條看起來只是調(diào)整了工作順序?qū)嶋H上讓整個團(tuán)隊(duì)少吵了無數(shù)次架。以前翻譯到一半發(fā)現(xiàn)術(shù)語沖突只能返工現(xiàn)在所有成員從第一天起就在同一個語言框架下工作譯者之間的風(fēng)格差異被壓到最小。2. 技術(shù)翻譯的術(shù)語規(guī)范與風(fēng)格基準(zhǔn)2.1 術(shù)語表怎么建30個高頻詞的譯法建術(shù)語表這件事看起來簡單做起來容易走過場。我的做法是先從第一期的所有譯文中抽取了160個候選詞再結(jié)合出現(xiàn)頻率、爭論次數(shù)、讀者反饋篩出30多個高頻術(shù)語。每個詞不只要定一個“推薦譯法”還要寫清楚適用語境和備注。下面是當(dāng)時定下來的一部分可以直接當(dāng)成初始模板用英文術(shù)語推薦譯法使用場景與備注feature特征指模型輸入維度時使用不譯成“特點(diǎn)”label標(biāo)簽監(jiān)督學(xué)習(xí)的目標(biāo)變量避免譯成“標(biāo)記”overfitting過擬合中文社區(qū)通用說法無需保留英文hyperparameter超參數(shù)與“參數(shù)”區(qū)分參數(shù)是模型內(nèi)部學(xué)到的pipeline管道首次出現(xiàn)時括號注明英文pipelineDataFrameDataFrame接口名保留英文可說明為“表格數(shù)據(jù)”bias偏置神經(jīng)網(wǎng)絡(luò)中的參數(shù)統(tǒng)計里譯“偏差”regularization正則化中文社區(qū)通用說法不譯“規(guī)則化”tuning調(diào)參不譯“調(diào)優(yōu)”調(diào)優(yōu)容易產(chǎn)生歧義baseline基線指基準(zhǔn)模型或?qū)φ辗椒╠eployment部署指模型上線避免“部署上線”重復(fù)術(shù)語表的價值不只是給翻譯人員看后面的技術(shù)復(fù)核、排版校對甚至讀者反饋都能基于同一個標(biāo)準(zhǔn)對話。沒有這張表每個人對“feature”的理解都可能不同質(zhì)量就完全靠個人發(fā)揮。2.2 英文保留還是中文全譯我有這樣一套取舍邏輯技術(shù)翻譯里最常被問的問題就是這個英文詞要不要翻譯翻譯成中文后讀起來怪怪的不翻譯又顯得不夠本地化。我的取舍邏輯分三類。第一類代碼符號和接口名全部保留英文。類名、函數(shù)名、包名該是什么還是什么因?yàn)榇a跑不跑得通取決于這些符號本身強(qiáng)行翻譯反而會害了讀者。第二類通用學(xué)術(shù)術(shù)語盡量中文化比如“過擬合”“正則化”“梯度下降”這些在中文技術(shù)社區(qū)里已經(jīng)形成固定譯法不需要猶豫。第三類介于兩者之間的半保留處理第一次出現(xiàn)時先給出中文譯法后面括號注明英文原文比如“管道pipeline”之后再次出現(xiàn)就直接用中文。這套邏輯背后有一個核心判斷技術(shù)文章的讀者通常需要對照英文文檔查資料。如果把所有英文術(shù)語都換成中文讀者看到某個函數(shù)名時根本不知道它對應(yīng)英文原文是什么查文檔就沒法下手反過來如果全文大量保留英文譯文和原文的差別就只剩下語法外殼那翻譯的意義就少了一大半。所以第二期定了一個總原則概念中文化、標(biāo)識符英文原樣。這個原則在后來的實(shí)際翻譯中幾乎沒有遇到需要推翻的情況。2.3 排印和語氣怎樣去掉翻譯腔去翻譯腔是技術(shù)翻譯里最考驗(yàn)語感的一步。我的做法是把“直譯”和“意譯”的邊界畫得很清楚。以原文里常見的一句話為例“The model doesn’t handle missing values well”直譯是“該模型不能很好地處理缺失值”聽上去不算錯但始終有一點(diǎn)硬。改成“這個模型處理缺失值的效果并不理想”就自然很多而且意思更準(zhǔn)確。技術(shù)文章要的不是字對字而是把作者的判斷完整傳達(dá)給中文讀者。排版層面同樣有規(guī)則標(biāo)題層級保持和原文一致但標(biāo)題字?jǐn)?shù)可以調(diào)整因?yàn)橹形臉?biāo)題在同等長度下承載的信息量比英文密度高。原文里的提示性語句統(tǒng)一成“提示”區(qū)塊英文里的“Note that”不再直譯成“請注意”而是直接用“ 提示”的樣式。全文使用中文標(biāo)點(diǎn)代碼塊內(nèi)保持英文標(biāo)點(diǎn)英文單詞和中文之間統(tǒng)一加一個空格保證視覺效果不擠成一片。這些小規(guī)則看著瑣碎但讀者閱讀舒適度大部分是它們決定的。2.4 代碼、圖表、公式的處理策略代碼部分一直是技術(shù)翻譯的難點(diǎn)因?yàn)榉g代碼和翻譯文章是兩個維度的事。第二期的處理策略是代碼注釋盡量中文化但變量名、列名、函數(shù)名一律不動。原因是代碼要直接在讀者環(huán)境中運(yùn)行變量名一旦翻譯整個示例腳本就斷了。注釋中文化后要重新檢查縮進(jìn)和對齊不能因?yàn)橹形娜亲址騺y了格式。對于依賴特定版本的函數(shù)譯文里會寫明“該函數(shù)在某某版本后遷移至新的模塊”并給出一段對應(yīng)寫法。圖表和公式的處理則更依靠判斷。原文章里很多圖表是用英文繪圖庫生成的如果我們直接搬運(yùn)讀者看到中文正文配英文圖體驗(yàn)很差。所以第二期里凡是數(shù)據(jù)可復(fù)現(xiàn)的圖我們都用中文標(biāo)簽重新繪制只保留原圖的配色和含義少數(shù)無法復(fù)現(xiàn)的圖則在圖注里完整解釋圖內(nèi)文字含義。數(shù)學(xué)公式保持原有的寫法不在公式內(nèi)部做無意義翻譯但在公式下方增加一句中文解釋說明這個公式在做什么。這套方案兼顧了準(zhǔn)確性、美觀性和一致性。3. 翻譯全流程實(shí)操從選文到發(fā)布3.1 源文本清洗與格式摸底正式動筆之前先花三天做源文本清洗和格式摸底。第二期從平臺導(dǎo)出的文章格式非常不規(guī)整有標(biāo)準(zhǔn)Markdown有帶HTML標(biāo)簽的混合格式還有從筆記本環(huán)境導(dǎo)出后殘留的大量元數(shù)據(jù)。清洗階段我用腳本做了三件事把所有HTML代碼標(biāo)簽轉(zhuǎn)成統(tǒng)一的Markdown反引號格式清理文章底部預(yù)埋的訂閱組件和無關(guān)鏈接把原始圖片路徑統(tǒng)一重寫成本地相對路徑。格式摸底則是逐篇記錄每篇文章包含哪些組件是否有代碼塊、是否有圖、是否有數(shù)學(xué)公式、代碼里是否涉及特定版本提示。這張檢查表看起來簡單但能省掉后期很多麻煩。因?yàn)樵诔醴A段就知道哪些部分需要特殊對待不會出現(xiàn)翻譯到一半才發(fā)現(xiàn)某個代碼塊缺了一半、圖片鏈接失效的問題。檢查表還會標(biāo)注文章原文發(fā)布時使用的軟件版本留給技術(shù)復(fù)核階段做參考。3.2 初翻與疑難標(biāo)記先定結(jié)構(gòu)再填肉初翻階段我的流程是先翻譯標(biāo)題、小標(biāo)題、圖注和代碼注釋把整篇文章的結(jié)構(gòu)骨架先立起來。這一步有兩個好處一是能盡早發(fā)現(xiàn)原文結(jié)構(gòu)上的問題比如章節(jié)編號跳號、標(biāo)題層級混亂二是給正文翻譯提供上下文錨點(diǎn)翻譯具體段落到時不至于偏離整體邏輯。之后才進(jìn)入正文翻譯盡量保持段落一一對應(yīng)方便后續(xù)復(fù)核。遇到拿不準(zhǔn)的詞、文化梗、殘缺語句我不會停下來死磕而是用統(tǒng)一的標(biāo)記寫清楚比如“{TBD:術(shù)語一致性待討論}”“{譯注:此處為雙關(guān)待處理}”。初翻階段流暢度比完美度更重要。把這些疑難點(diǎn)集中留到最后統(tǒng)一討論效率比邊譯邊糾結(jié)高得多。標(biāo)題也不逐字對譯允許在保證主旨不變的前提下做長度調(diào)整。比如原文標(biāo)題要表達(dá)的是“調(diào)參的實(shí)用指南”中文標(biāo)題直接寫成“超參數(shù)調(diào)參實(shí)戰(zhàn)指南”更短更直接也不脫離原意。3.3 技術(shù)復(fù)核代碼必須跑得通技術(shù)復(fù)核是第二期新增的關(guān)鍵環(huán)節(jié)也是我認(rèn)為最不能省略的環(huán)節(jié)。復(fù)核人員把所有代碼塊從文章里提取出來按文章順序組裝成一個可以順序執(zhí)行的腳本然后在干凈的測試環(huán)境里逐段運(yùn)行記錄下每一步的輸出和報錯信息。遇到代碼報錯先判斷是環(huán)境問題還是原文問題。如果原文代碼使用了某個庫的舊接口而當(dāng)前環(huán)境只支持新接口復(fù)核表中會寫明兩種版本的寫法并在譯文里加譯者注。如果原文的繪圖參數(shù)寫錯導(dǎo)致圖出不來我們會修正參數(shù)后重新出圖同時保留一條勘誤說明。技術(shù)復(fù)核的副產(chǎn)品特別有價值很多文章在翻譯階段看得半懂跑完一遍代碼才知道作者到底在說什么。這也是為什么我一直強(qiáng)調(diào)技術(shù)翻譯和文學(xué)翻譯不一樣沒有技術(shù)支撐的譯者做出來的譯文只能給人一種“字面懂了”的感覺一旦遇到具體操作就會露餡。3.4 潤色、一致性檢查與發(fā)布清單技術(shù)復(fù)核完成后進(jìn)入潤色和一致性檢查。潤色階段我給團(tuán)隊(duì)的建議是譯文完成之后放一放隔幾個小時甚至隔天再拿回來重讀專門找那些讀起來拗口、需要來回看兩遍的句子。一致性檢查則分三個層面同一篇文章里同一個術(shù)語必須完全統(tǒng)一同一套系列文章里相同概念要用同一個譯法代碼注釋里的術(shù)語和正文的術(shù)語也要對應(yīng)上不能讓正文叫“偏置”代碼注釋里卻出現(xiàn)另一個詞。發(fā)布前檢查清單是流程的最后一道防線。清單包含這些項(xiàng)目所有疑難標(biāo)記是否已經(jīng)清理代碼塊里的中文標(biāo)點(diǎn)是否被誤用圖片是否正確引用代碼能否從頭到尾完整運(yùn)行文章末尾是否補(bǔ)上了譯者和復(fù)核記錄。只要清單里有一項(xiàng)沒過就不允許發(fā)布。這套流程走下來第二期的返工率比第一期低了不少絕大多數(shù)問題都攔在發(fā)布之前。4. 實(shí)操中的高頻坑位與排查實(shí)錄4.1 一詞多義同一個詞在不同語境可能完全相反技術(shù)術(shù)語的一詞多義是翻譯過程中最隱蔽的雷區(qū)。拿“bias”來說在神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)里它指“偏置”也就是每一層的偏移參數(shù)但在“bias-variance tradeoff”這個經(jīng)典語境里它又應(yīng)該譯成“偏差”和“方差”對立。同一個詞一句話之差就是兩個含義如果術(shù)語表里只寫一個譯法一定會踩坑。我建了一張容易混淆的詞表給每個詞都注明上下文判斷依據(jù)?！皏ariance”在統(tǒng)計和機(jī)器學(xué)習(xí)語境里是“方差”但在普通英文里還有“變化”的意思“schema”在數(shù)據(jù)庫場景譯“模式”在認(rèn)知模型場景譯“結(jié)構(gòu)”“server”既有“服務(wù)器”的名詞含義也有“服務(wù)端”的架構(gòu)含義。處理原則是不要試圖給一個詞定死唯一譯法而是定一個默認(rèn)譯法加一組上下文例外規(guī)則。技術(shù)翻譯追求的是準(zhǔn)確不是機(jī)械一致。4.2 上下文暗語作者默認(rèn)你懂的那些事英文技術(shù)博客的作者經(jīng)常默認(rèn)讀者有完整的閱讀背景。比如作者會寫“正如我們在上一篇文章中看到的”如果上一篇文章沒有被翻譯中文讀者看到這里就會卡住。第二期的處理方式是在這種位置加一句譯者注“原文此處指作者前一篇關(guān)于某某主題的文章讀者可參考譯者補(bǔ)充的簡要說明?！比绻奶岬侥硞€數(shù)據(jù)集或某個方法但不解釋來歷我們也不偷懶必須補(bǔ)一段背景說明避免讀者為了一個前提去翻完整篇英文原文。上下文暗語還包括版本變化。原文作者寫文章時用的庫還是舊接口但讀者論文里的范例已經(jīng)是新接口。我們在譯文里遇到這類情況會保留原文寫法的同時補(bǔ)上新寫法和版本提示。翻譯不是復(fù)讀機(jī)它的價值在于幫讀者消除信息差而不是把英文里默認(rèn)“你懂”的東西原樣搬過來。4.3 文化梗與口語直譯會翻車英文技術(shù)博客里經(jīng)常出現(xiàn)文化梗和口語表達(dá)直譯過來翻車率極高。比如作者把深入探索一個話題比作“掉進(jìn)兔子洞”中文讀者對愛麗絲夢游仙境的熟悉度有限直接保留“兔子洞”會很突兀。第二期的處理原則是能打通意象就意譯不能意會就直譯加注完全不重要的就刪去。上面這個例子我改成“這條路一走就收不住”意思到位中文讀者秒懂。還有一種常見情況是諧音梗。有些英文技術(shù)作者喜歡拿術(shù)語開幽默玩笑比如把“哈希表”和一種早餐食物做文字游戲。翻譯時我先保證技術(shù)含義不丟再盡量把文字游戲的味道用注釋補(bǔ)出來“哈希土豆餅原文為諧音梗指的是某早餐食物”。如果注釋太長寧可舍棄這個梗也不能讓讀者為了看懂笑話去做額外英文閱讀。技術(shù)文章的主角永遠(yuǎn)是技術(shù)不是風(fēng)格秀。4.4 格式層面的坑標(biāo)點(diǎn)、鏈接、代碼縮進(jìn)格式問題是最容易在翻譯收尾階段冒出來的問題不大但特別消磨耐心。最常見的坑有三個。第一是中英文混排時空格的規(guī)則不一致同一個頁面里有的地方“中文 English”之間加了空格有的地方?jīng)]加視覺上很亂。第二是標(biāo)點(diǎn)混亂中文句號、逗號、冒號和英文半角符號混在一段里尤其容易在代碼注釋和正文之間交叉出現(xiàn)。第三是Markdown鏈接失效很多原文鏈接指向的是當(dāng)時的課程頁面或資料頁面幾個月后可能已經(jīng)變成死鏈。針對鏈接問題我在第二期里不是簡單保留原文鏈接而是一律先點(diǎn)一遍能用的才保留失效的替換成最新可用地址替換不了的刪除并在譯注里說明。代碼塊里的縮進(jìn)問題則是通過技術(shù)復(fù)核發(fā)現(xiàn)的某些代碼注釋中文化后多出來的全角字符影響了注釋對齊看起來沒有代碼感。處理方式是把注釋統(tǒng)一放在代碼上方而不是夾在代碼中間減少縮進(jìn)沖突。5. 第二期數(shù)據(jù)復(fù)盤與質(zhì)量記錄5.1 翻譯規(guī)模與投入時間第二期最終完成24篇文章中文正文字?jǐn)?shù)約18萬字平均每篇7500字左右。如果算上圖注、譯注、代碼注釋和重新繪制的圖表說明實(shí)際產(chǎn)出比這個數(shù)字更高。團(tuán)隊(duì)配置很簡單翻譯2人技術(shù)復(fù)核1人排版校對1人總共4人協(xié)作。工期接近兩個半月其中初翻用了2周技術(shù)復(fù)核用了3周潤色和排版用了2周剩下的時間全部花在術(shù)語討論、疑難協(xié)商、重新繪圖和收尾修正上。這個時間比預(yù)期要長主要原因是我低估了技術(shù)復(fù)核的耗時。每篇文都要把代碼實(shí)際跑一遍遇到環(huán)境問題還要換版本重新驗(yàn)證。但回頭看這部分時間花得值因?yàn)樗亲g文質(zhì)量最直接的保障。如果只翻譯不跑代碼24篇文章里至少有五六篇會出現(xiàn)讀者照著代碼操作卻報錯的情況。5.2 審校揪出的典型問題分布整個審校過程里我們按問題類型做了一次簡單統(tǒng)計結(jié)果很有參考價值問題類型占比處理方式術(shù)語不一致42%重開術(shù)語表修訂全局統(tǒng)一替換直譯不自然28%回爐重寫句子不以字面對應(yīng)為標(biāo)準(zhǔn)代碼運(yùn)行問題15%統(tǒng)一修訂示例并標(biāo)注版本差異鏈接與格式問題10%腳本清理加人工復(fù)核內(nèi)容事實(shí)或數(shù)據(jù)錯誤5%修正原文問題并加譯注說明術(shù)語不一致占比最高這一點(diǎn)并不意外。哪怕已經(jīng)有了術(shù)語表翻譯人員在實(shí)際行文中還是會因?yàn)檎Z境而偏移尤其是一些拿捏不準(zhǔn)的抽象詞。審校環(huán)節(jié)的價值就在這里它不是走流程而是用第二雙眼睛把每個人偏移的地方拉回來。5.3 讀者反饋里的高頻訴求項(xiàng)目發(fā)布后我們收到一批讀者反饋其中有幾條反復(fù)出現(xiàn)。第一條是“術(shù)語表很好用但放在文末不容易發(fā)現(xiàn)”后來我們把術(shù)語表的位置從文末挪到了每篇譯文的導(dǎo)讀部分并把完整版術(shù)語表整理成獨(dú)立頁面。第二條是“希望提供可下載的代碼文件”于是我們把每篇文章的代碼合并成一份可運(yùn)行的實(shí)驗(yàn)文檔并且附上測試環(huán)境說明。第三條是“個別示例數(shù)據(jù)下載地址失效”我們專門做了一個數(shù)據(jù)資源備份把散落各處的示例數(shù)據(jù)集中存放。第四條是“有些譯注讀起來太繁瑣”這句話提醒我們控制譯注頻率只在真正影響理解的位置補(bǔ)充解釋。這些反饋直接進(jìn)入了第三期的改進(jìn)計劃。6. 第三期如果開做我會這樣改流程6.1 把術(shù)語表升級成為協(xié)作數(shù)據(jù)庫第二期的術(shù)語表是一份文檔能解決問題但不夠靈活。如果第三期啟動我會把它升級成協(xié)作式術(shù)語庫。每條術(shù)語記錄除了英文原文和中文譯法還要增加適用語境、示例句、使用狀態(tài)、修改歷史。多個人對同一條術(shù)語有不同意見時可以在庫里提交翻譯版本并附理由由負(fù)責(zé)統(tǒng)一口徑的人做最終裁決。為什么一定要加示例句因?yàn)槊撾x語境的術(shù)語討論永遠(yuǎn)吵不出結(jié)果有了示例句每條譯法都能放到真實(shí)句子里驗(yàn)證。再進(jìn)一步我還想加一個自動檢查腳本掃描所有待發(fā)布文本如果發(fā)現(xiàn)某個術(shù)語在庫里已經(jīng)有固定譯法但譯稿里用的是另一種寫法就自動報警。這個機(jī)制能減少大量人工核對的重復(fù)勞動把人的精力節(jié)省出來解決真正的語言和技術(shù)問題。6.2 給代碼塊增加可運(yùn)行性測試第二期的技術(shù)復(fù)核是半人工的第三期我想把它變成一套更系統(tǒng)的“代碼可運(yùn)行性測試”流程。具體設(shè)想是從每一篇文章的Markdown源文件中提取所有代碼塊按文章順序組裝成可執(zhí)行腳本放到隔離環(huán)境里自動運(yùn)行運(yùn)行失敗的代碼塊會報告具體位置和異常信息再由人工判斷問題是出在環(huán)境差異還是原文錯誤。在此基礎(chǔ)上發(fā)布每一篇譯文時固定記錄運(yùn)行依賴的版本信息這樣即使將來庫升級也能快速定位到底是哪一版代碼需要更新。這個流程本質(zhì)上是把技術(shù)復(fù)核從“事后抽檢”變成“發(fā)布門禁”。它不增加翻譯本身的負(fù)擔(dān)但會讓整個項(xiàng)目的可靠性提升一個量級。第二期用人工跑代碼已經(jīng)發(fā)現(xiàn)了不少問題第三期用腳本做第一輪篩選效率會明顯高出許多。6.3 為每篇譯文補(bǔ)充導(dǎo)讀和延伸材料第三期我還想給每篇譯文加一個標(biāo)準(zhǔn)導(dǎo)讀塊內(nèi)容包括適合誰讀、讀之前需要什么基礎(chǔ)、讀完能解決什么問題、建議閱讀時長、配套資源有哪些。這個導(dǎo)讀不是為了好看是為了讓讀者在打開文章的第一分鐘就能判斷這篇內(nèi)容值不值得讀。當(dāng)前很多技術(shù)博客文章點(diǎn)進(jìn)去才發(fā)現(xiàn)難度不匹配導(dǎo)讀可以大幅降低這種試錯成本。同時我想建立一個“譯文相互引用”地圖把同一主題下的多篇文章互相串聯(lián)起來。比如一篇講特征工程的文章文末列出相關(guān)的數(shù)據(jù)清洗文章和模型評估文章讀者不用四處找按圖索驥就能把知識體系補(bǔ)全。還可以做一個回譯抽檢隨機(jī)抽10%的譯文章節(jié)回譯成英文再和原文對比檢查是否出現(xiàn)了信息丟失。這個做法成本不高卻是檢驗(yàn)翻譯質(zhì)量的試金石。我在實(shí)際做這個項(xiàng)目時最深的感受是翻譯本身只是第一步真正拉開差距的是術(shù)語管理、技術(shù)復(fù)核、格式規(guī)范和反饋閉環(huán)。如果只盯著“翻了多少字”很容易把項(xiàng)目做完卻做不出別人愿意長期使用的譯文。第二期積累下來的這套流程對我來說已經(jīng)不是一次翻譯項(xiàng)目的總結(jié)而是以后做任何內(nèi)容本地化工作都能直接用上的基礎(chǔ)框架。如果你也準(zhǔn)備做同類項(xiàng)目我建議不要一上來就追求篇數(shù)先把術(shù)語表、復(fù)核環(huán)節(jié)和發(fā)布檢查清單這三個基礎(chǔ)搭穩(wěn)后面的路會順很多。