關於翻譯的統一畫風問題

首先這個翻譯並不是開源翻譯,根據將來的捐贈收入,大家會得到補償(可能不多

其次作為貢獻者你自己翻譯的爽是前提。


 

基本規則

  • 首先你會得到這個博客的一個作者帳號,用這個號在這個博客發布你的翻譯,正在翻譯的章節請使用“保存草稿”功能持續更新。——你保存草稿我能夠看到,這樣我就知道你佔了哪個坑,翻譯了多少。
  • 添加代碼使用編輯器第一行最右邊的 <> 按鈕,默認語言就是 Swift,很方便。
  • 原文當中的所有代碼都要按照原縮進格式放到代碼塊裡,代碼內容不翻譯,代碼註釋暫不翻譯。
  • 英文原句的句號位置不要改變,即保持原句格式。由於翻譯需要,逗號就隨意了。
  • 原文中的格式不要改變,即引用還是要引用,斜體還要斜體,括號要括號。
  • 原文中的灰色字體,即行內代碼塊不翻譯,但要保證全部都會出現在正確的位置,同時使用代碼塊中的行內選項來添加同樣的行內代碼塊。
  • 原文中的灰色標題對應翻譯中的二級標題;每一章的章節名稱請寫到文章名稱裡不要寫在正文哈。
  • 黑色標題則是對應翻譯中的三級標題。
  • 發布文章的時候記得選擇 Swift 分類下的自翻分類哈。
  • 另外翻譯不懂的可以參考開源翻譯版本,但我個人推薦盡量從原文翻譯,有不懂的留言給我~
  • 上一行的要求之所以會存在,是因為我們要避免出現類似抄襲的問題。
  • 原文中的鏈接不要添加,在鏈接內容上加下劃線,整體看起來像是這樣: 這裡有個鏈接(此處應有鏈接) 等第二次精翻的時候我統一給加,加括號裡的字是為了到時候方便檢索。
  • 遵循傳統定義,我們對“參數”使用更嚴謹的形參和實參的區分: 其中 參數 譯為形式參數; 論據 為實際參數;

語法通則

雖然我最終都會校譯和校對,但還是希望大家能夠按照一定的標準來進行翻譯,目前能想到的有如下幾點:

  • 構造器:根據原文命名,用初始化器更貼切一些,名詞形式則對應 初始化
  • 可選類型:可選的問題這樣規定,optional 為​​ 可選 ; 而 複數形式則為 可選項,作為形容詞的時候我們譯為“可選項 a”這樣,具體情境大家隨機應變
  • 可選項的解包、解封:我們使用 展開 來描述
  • 嵌套類型: 我們講 內嵌類型,對應方法什麼的也是 nested 為內嵌。
  • 權限控制:Access 我們講 訪問, 訪問控制。文中所有的 Access 都是訪問而不是權限。
  • 屬性:特性
  • 關於 採集 ,兩個都是集合,我們普遍認為前者是集合,為了區分,後者稱為合集。
  • self-contained 譯為 獨立
  • delegate 代理——我們翻譯為“委託”這個更容易理解且好組織詞彙。
  • Store Properties 譯為存儲屬性,符合工科傳統習慣。
  • adopted 譯為採納,conform則為遵循;
  • type Annotation 譯為 類型標註

其他暫時沒有,遇到再說~😀

一個回复“關於翻譯的統一畫風問題”

發表評論

您的電子郵件地址不會被公開. 必填字段標 *