對圖靈譯製過程的建議
年底了,看到幾篇建議文章,也勾起了我的一些想法。算不上建議,也就是些碎碎念;覺得對呢就參考參考,覺得不對呢,就當做班門弄斧,圖個樂。怎麼說,這也是我在圖靈社群的處女文啊。
Markdown 混戰
Markdown 讓人詬病的主要原因是,方言太多,沒有標準。可惜,圖靈讓這一現象加劇一步——發明了自己的一套句法。每次開始翻譯圖靈的書時,我都會發一推,抱怨又要換一門 Markdown 方言了。換來換去感覺自己腦子都亂了。
舉個簡單的例子:腳註。腳註雖然不是標準的 Markdown 句法,但是很久以前 PHP MarkdownExtra 就擴充套件了這個句法,隨後各種實現也都採用了:
這裡有個腳註。[^fn-id]其他文字。
[^fn-id]: 腳註在此。
但是圖靈寫作平臺的句法是:
這裡有個腳註。{![腳註在此]}其他文字。
另外還有 Admonition,各種花括號和感嘆號,反映慢一點一時真寫不出來。何不像 Leanpub 那樣,直接擴充套件塊級引用的句法,使用T>
、N>
和W>
,語義明確,還好解析。
還有一點是對齊方式的句法,這明顯違背了內容與表現分離原則。
另外,我對採用 Markdown 持保留意見。畢竟,Markdown 所涉及的語義太少,不適合寫書。我翻譯《Ruby on Rails 教程》第2版是用的是 Markdown,為了實現各種結構,比如旁註,我自己對 kramdown 做了擴充套件。但是翻譯第3版時,我越發覺得 Markdown 不適合用來寫書。經過大量搜尋之後,我鎖定了 Asciidoc。Asciidoc 也是一種純文字句法,其目的只有一個——寫書。這也是 O'Reilly 大力支援的專案。去年,O'Reilly 推出了線上電子書製作服務 Atlas,其背後使用的就是 Asciidoc(當然,也支援簡單的 Markdown)。
《Rails 教程》第3版所有的譯稿都是使用 Asciidoc 寫的,全部使用標準的 Asciidoc 句法。經過這次使用,我更加堅信:Markdown is for the Web, Asciidoc is for books.
當然,Asciidoc 的句法比 Markdown 複雜,要花點時間才能掌握。這可能是有些人不願意使用它的主要原因。可是,一旦掌握,好處立顯。
所以呢,希望圖靈能考慮一下 Asciidoc。與此同時,可以保留對 Markdown 的支援。簡單的排版交給 Markdown,複雜的就交給 Asciidoc。
後製
鄙人不才,為圖靈翻譯了幾本書,對後製過程有點不滿意,這裡嘮叨嘮叨。注意,我對後製的具體過程不清楚,這裡講到的流程方面的內容基本屬於臆測,不正之處請見諒。
我印象中,好像是我翻譯的第二本書,拿到樣書後傻眼了:這不是我翻譯的啊,我沒用這麼多“它”和“進行”。因為我覺得這兩個詞太翻譯腔,翻譯時能不用就不用,迫不得已偶爾一用,但是絕不會滿篇都是。所以看到樣書後,我是傻眼的。當然,錯在我。我沒有及時跟進編輯過程。
後來我學乖了,編輯(editor)編輯(edit)完之後,我會和自己提交的譯稿對比一下,看哪裡有錯誤沒發現,哪裡翻譯的不恰當被編輯改正了,防止以後再犯。但是這一次我又傻眼了(比較誇張),一位編輯說,你在後臺看到的不是定稿。當時我想,後臺不是定稿,那這個後臺有什麼用?這裡就體現了我對後製過程的不瞭解。我想(推測),後製過程可能還涉及 Word 這一環吧。
啊,Word!我在翻譯過程中也會使用 Word,但是絕對不會直接在 Word 中翻譯或者編輯,而是使用程式(如 pandoc)把 Markdown 轉換成 Word。目的只有一個,統計每日翻譯量。在我看來,Word 是“中間產物”,通過原始譯稿(Markdown)隨時可以生成。
在版本控制系統中,Word 的缺點一覽無遺——不便做版本控制。“版本控制”正是我寫這一條的關鍵。因為 Word 不便做版本控制,也就無法對比版本之間的差異。而且,Word 對現代圖書(電子書)的快速迭代沒有一點好處。
真正的現代化流程應該是,使用純文字自動生成電子書。需要修改的話,改的是純文字檔案,而不是電子書。電子書雖然是提供給讀者的產品,但不是最終產物,而是中間產物。
在我的心目中,圖靈在中的出版公司裡算是積極擁抱新技術的,那麼何不更進一步,學習國外的先進流程(例如 Atlas)。我自己也實現了類似的工具鏈,所以圖靈在這方面一定能做的更好。(少年,你懂出版業嗎?!)
ePub 電子書
最後一點,算是建議,順便提個問題。
建議:電子書提供 ePub 版本。
問題:為什麼不提供 ePub 版本呢?
很多讀者問我,你翻譯的書為什麼沒有 ePub 格式呢?遇到這樣的問題,我只能臆測,因為出版社有自己的考量。但是考量什麼,我真不知道。PDF 和 mobi 格式都提供了,為什麼只差 ePub 格式呢?還請知情人士透露一下(方便的話)。
相關文章
- [譯] 製作 Vue 3 的過程Vue
- 【計算理論】圖靈機 ( 多個帶子的圖靈機 | 計算能力對比 | 證明過程 | 一個帶子圖靈機 )圖靈
- Python Matplotlib繪製條形圖的全過程Python
- 圖解大頂堆的構建、排序過程圖解排序
- 過來人對大資料學習的建議大資料
- 爬蟲程式實現過程中的一些建議爬蟲
- 編譯過程編譯
- View 的繪製過程View
- 痛苦的過程,編譯glomap編譯
- Android View的繪製過程AndroidView
- 軟體專案過程診斷與改進建議案例
- ROS 八叉樹地圖構建 - 使用 octomap_server 建圖過程總結!ROS地圖Server
- 對Spark硬體配置的建議Spark
- 圖靈技術圖書譯者須知圖靈
- JavaScript的預編譯過程分析JavaScript編譯
- 【譯文】構建大型 Redux 應用的五個建議Redux
- [譯] 程式碼評審的 8 點建議
- 編譯連結過程編譯
- C++ 編譯過程C++編譯
- 編譯過程簡介編譯
- 給軟體公司的靈魂四問五條建議
- svn透過https協議訪問的搭建過程HTTP協議
- 對初學ERP人員的建議
- Python繪製六種視覺化圖表詳解(建議收藏)Python視覺化
- redis建立主從複製的過程Redis
- ios底層 編譯過程iOS編譯
- vit的線性對映過程
- 你絕對不能錯過的流程圖製作軟體!真心好用!流程圖
- 為什麼我建議通過翻譯英文資料學習知識
- 針對SQL Server的最佳化建議SQLServer
- Redis複製過程詳解Redis
- [譯] 構建世界上最快的會議網站網站
- 《反圖靈測試》今日正式發售,在不斷重啟的過程中探求世界的真相圖靈
- FLASK藍本使用初體驗,個人對整個構建過程的理解Flask
- 執行時的頁面構建過程
- docker作業系統的攢建過程Docker作業系統
- 對社群提交建議以及bug提交
- GCC編譯和連結過程GC編譯
- 預編譯過程(AO+GO)編譯Go