關於翻譯的統一畫風問題

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

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

基本規則

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

語法通則

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

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

其他暫時沒有，遇到再說~?

本文由 落格博客 原創撰寫：落格博客 » 關於翻譯的統一畫風問題

轉載請保留出處和原文鏈接：https://www.logcg.com/archives/1186.html