開源文件翻譯的質量保障實踐
五月份,我宣佈了 Kotlin 官方參考文件翻譯完畢的訊息,其中有提到這也是唯一一份完整且最新的官方參考文件翻譯。不僅如此,其中值得一提的還有翻譯質量。
Kotlin 中文站良好的翻譯質量跟很多不錯的翻譯實踐是分不開的。這些實踐對於其他文件翻譯專案也有很高的參考價值,特單獨拿出來分享。
直接 fork 外文源站
這個在 Kotlin 官方參考文件翻譯完畢已經介紹過:這樣做的顯著優勢是官方站有任何更新可以及時合併進來。雖然這可能會引入衝突解決環節,並可能會影響翻譯完整度,但這些與所帶來的優勢相比都是微不足道的。畢竟很難想象錯過勘誤的文件甚至內容陳舊的文件如何稱之為質量好。
行級對照翻譯
Kotlin 中文站翻譯參考文件時,我們要求翻譯後的中文與英文原文能夠行級對應,即每行都是一一對應的。如果英文的一段文字分作了多行,中文也要按照原文分作多行,如下圖所示:
這樣做有兩點優勢: 1. 源站更新後合併過來時,能夠減少衝突發生,並且在發生衝突時也便於解決。 2. 能夠逐行對照中英文,便於檢查是否有遺漏或者失誤的地方。
當然這樣一來,會引出一個問題。比如上圖的倒數第二段,英文加了兩個斷行,分別發生在 of
與 inside
之前。中文與之對應,分別斷在函式
與中的
之前,而這樣一來渲染出的網頁就會在斷詞處多出空格,如下圖紅圈標註的地方:
當然,如果現在開啟 https://www.kotlincn.net/docs/reference/classes.html,在文末並不會看到相應的空格,那是因為我們通過利用 HTML 註釋的方式解決了這一問題,見下圖:
小屏校對
我基於 Kotlin 中文站的參考文件製作了相應的 GitBook,之後發現用手機看 ePub 版電子書的時候更容易發現問題,因為手機螢幕尺寸較小,每屏的字數要比電腦屏少很多,更容易聚焦在區域性。如果細讀這頁,就會發現第二段程式碼有些問題:
也許你已經看出來了,註釋匯入所有名為“goo”擴充套件
讀起來不通順,因為擴充套件
前面少了個的
。這樣就發現了一處疏忽,加上之後就好了:
上圖再往下看,會發現程式碼中還有問題。沒錯,括號不對稱,fun usage
應該以大括號結尾,但是程式碼中卻是圓括號。通過對比我發現源站就有這一拼寫錯誤,修正後提 PR 給源站,然後再合併回來,就是現在的樣子了:
統一術語
相信統一術語的重要性已經深入人心,這裡只舉一些實際的例子:
- “方法”還是“函式”:受既有 Java 術語影響,早期的翻譯中很多本該譯為“函式”的地方也翻譯成了“方法”,因為 Java 中統一稱“方法”。 但 Kotlin 不一樣,它既有“方法”也有“函式”,甚至也可以像 C++ 那樣將方法稱為“成員函式”。 所以最好的翻譯方式就是“忠於原文”,即原文用“function”則翻譯為“函式”,原文用“method”則翻譯為“方法”。
- “範圍”不準確:在統一校對前,譯文中有不少“範圍”這一術語,其中有的原文是“range”也有的是“scope”。 對於“scope”更確切的譯法應該是“作用域”。 而對於“range”更確切的譯法應該是“區間”,尤其是“close range”自然應該譯作“閉區間”。
- “型變”:泛型相關的術語“variance”譯為“型變”、“covariant”譯為“協變的”、“contravariant”譯為“逆變的”。而“invariant”沒有譯為“不變的”, 為避免歧義,結合型變這一詞根,將其翻譯為“不型變的”。
- “註解”怎麼辦:通常註解的名詞形式“annotation”很好翻譯,即“註解”。而其動詞形式如果也翻譯為“註解”就比較麻煩了,尤其遇到
annotated with the annotation
這樣的詞句時。 因此,Kotlin 中文站通常將參考文件中的“annotate”翻譯成“標註”或者“用註解標註”。這樣剛剛提到的詞句就翻譯為“用該註解標註的”。 - “參見”與“參閱”:在統一校對前,“see ... for”有多種譯法,包括“檢視”、“參見”、“參閱”等。統一校對後,將“see ... for”統一譯為“關於……請參見”。 而將“read ... for”統一譯為“關於……請參閱”。
注重細節
其實上面介紹的幾條都包含了不少細節在裡面。Kotlin 中文站參考部分在翻譯過程中所注重的細節還有:
- “the”有時也要翻譯。尤其用於特指上文中提到的一項事物時,通常譯作“該”。
- 註釋也翻譯。參見上面的例圖。
- 中文與英文之間留空格。
- 文中以及程式碼註釋中出現的標點都替換為全形。
- 表示程式碼省略的
...
也替換為中文省略號……
。 - 英文中表示並列關係的逗號,翻譯後轉換為頓號。如
“The following escape sequences are supported:\t
,\b
,\n
,\r
,\'
,\"
,\\
and\$
.”
翻譯為
“ 支援這幾個轉義序列:\t
、\b
、\n
、\r
、\'
、\"
、\\
與\$
。”
群策群力
- 翻譯
一個人能力畢竟有限,Kotlin 中文站是由大家共同翻譯的,參見貢獻者名單。 - 校對
後期主要由我來統一校對,使用了行級比較、小屏校對等方法,還用到了一些指令碼與小工具作為輔助。 但是即便如此,還是會有在所難免的疏漏之處。 這時多人的力量再次凸顯:多人評審、讀者反饋與協作改進這些實踐中的多人蔘與讓 Kotlin 中文站的翻譯質量越來越好。
由衷感謝參與 Kotlin 中文站翻譯與改進的每個人。 Kotlin 中文站的翻譯工作還在進行中,教程部分還有很多章節需要翻譯,另外隨著官方參考文件的更新中文站也需及時更新,歡迎更多人蔘與進來。
本文也發在我的個人部落格上:https://hltj.me/translate/2017/06/22/oss-docs-translate-quality.html。
相關文章
- 軟體質量保障全流程實踐分享
- 監管機器翻譯質量?且看阿里如何搭建翻譯質量評估模型阿里模型
- 提高開發質量的 5 個必要實踐
- 谷歌揭祕自家翻譯系統:如何利用AI技術提高翻譯質量谷歌AI
- 專欄文章 質量保障系統的落地實踐 (三) CI 管理設計 - 整合設計
- 專欄文章 質量保障系統的落地實踐 (四) 效能管理設計 - 造數工廠
- 專欄文章 質量保障系統的落地實踐 (三) CI 管理設計 - 基礎設計
- 【質量視角】可觀測性背景下的質量保障思路
- 【翻譯】編寫程式碼註釋的最佳實踐
- 前端程式碼質量的思考與實踐前端
- 如何保障前端專案的程式碼質量前端
- 如何保障數倉資料質量?
- 淺談語音質量保障:如何測試 RTC 中的音訊質量?音訊
- 專欄文章 質量保障系統的落地實踐 (二) 專案管理設計 - 程式碼資訊設計專案管理
- 億級搜尋系統的基石,如何保障實時資料質量?
- 有贊資料質量保障體系
- RTC 音訊質量評價和保障音訊
- Milvus 2.0 質量保障系統詳解
- 記一次翻譯工具的開發-有了它,實現實時翻譯還遠嗎?
- NQI國家質量基礎設施改善企業質量保障能力
- 基於 Flink 的實時資料消費應用 / 功能質量保障方法
- 酷家樂大型專案質量保障反思
- 實用的Word文件翻譯方法分享,讓Word文件快速翻譯
- 蝴蝶書-task2: 文字推理、摘要、糾錯 transformers實現翻譯 OpenAI翻譯 PyDeepLX翻譯 DeepLpro翻譯ORMOpenAI
- 傅一平:資料質量管理的實踐和思考
- 前端可用性保障實踐前端
- PHP 7:真實世界的應用開發(中文翻譯)PHP
- 《Node.js 開發實戰》翻譯歷程Node.js
- 優質免費的 5 款翻譯 API 介面推薦API
- 宜人蜂巢專案質量管控體系實踐
- Jenkins+Sonar質量門禁【實踐篇-maven版】JenkinsMaven
- 漫談專案質量保障——協作流程優化優化
- [翻譯] 使用JavaScript實現自己的PromisesJavaScriptPromise
- 語音翻譯軟體怎麼用?怎麼實現語音的翻譯
- CODING DevOps 系列第四課:DevOps 中的質量內建實踐dev
- B站的資料質量管理——理論大綱與實踐
- 騰訊互動翻譯的坑爹翻譯
- [12月27 線上沙龍] 共探 DevOps 下的質量保障dev
- 技術團隊運用度量驅動開發提升質量:策略與實踐